-
-
Notifications
You must be signed in to change notification settings - Fork 758
Fix st2 cli client auth in st2auth proxy mode #6049
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
1b059e9
to
6c02f17
Compare
I would also add there is a 3rd issue with proxy auth mode which has a workaround unrelated to this PR. I do not feel it is something that needs to be added to code but perhaps should be documented somewhere for others that use
This was borrowed from a forum post I found here. I'm not sure if this is something we would want to consider bundling with st2web but I feel it may warrant documentation (st2docs ?) for others that may be trying to use proxy auth mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to merge, but just added comment as not sure we need to keep having six.PY3 checks any more.
return | ||
|
||
remote_user = split[0] | ||
if six.PY3 and isinstance(remote_user, six.binary_type): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to have checks on whether its python3 any more?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not but i was just keeping consistent with what is used in other handlers, for example:
st2/st2auth/st2auth/handlers.py
Lines 212 to 216 in 32a243a
if six.PY3 and isinstance(username, six.binary_type): | |
username = username.decode("utf-8") | |
if six.PY3 and isinstance(password, six.binary_type): | |
password = password.decode("utf-8") |
decode("utf-8")
is needed even without the conditional in my testing.
@floatingstatic would you mind sharing your helm chart which has proxy auth enabled? I added the following to the st2 config section in
However, I get the following pod error while installing the chart: Seeing a full working helm chart with proxy auth mode would be very helpful to the community :) |
@hamsterdolphin I cannot share my chart as its a fork of upstream with a bunch of things I have changed for my own use case, however the only real change you need to enable proxy auth would be here:
It seems like you did that already so I suspect what you are hitting is actually the fact that you need a few patches on the upstream containers you are probably pulling in for version 3.8.0. Internal to my org we pull in upstream images for 3.8.0 then build a custom image with some patches on top of the The Patches are basically just what you see in those two PRs Then we build and push the image to an internal registry and point to those images in our helm chart values instead of the default upstream container images. The |
Adding on to work in #6041 that fixed proxy auth mode for users connecting via st2web, it appears that the
st2
client (st2client
container in the HA helm chart) connects directly tost2auth
instead of connecting through nginx. As a result it is unable to authenticate withst2auth
is in proxy mode as headers required for this to work are not present. We see401 Client Error: Unauthorized
in this scenario. Thest2
client does however use basic auth and we can extract the username from that in this scenario to resolve the issue.This change modifies the proxy auth handler to use the username from the
Authorization
header only in the case where proxy auth mode is enabled and whenremote_user
is not passed to the proxy auth handler function.