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
Remove unnecessary Basic Auth in Openshift requests. #4698
Comments
Current behavior if you specify a username and password:
So it looks like neither was designed to reuse in the case of setting a username and password. My understanding at this point is that for base kubernetes if username and password are supplied, then only basic auth should be used - that would match the behavior of kubectl. For openshift basic auth is not supported, so the default logic in HeaderInterceptor is definitely wrong. To confirm your expectation is that if the config already contains a token it should be used, then if it needs to be refreshed the username and password provided will be used? |
Correct, I think the username and password is required for OAuth authentication flux against Openshift, but I'm not an expert on that, when I try to overwrite the HeaderInterceptor to not send the basic header, I get a 401 from openshift when OpenShiftOAuthInterceptor gets the token for the first time. |
@ismadirolas see if #4702 makes sense for you. In particular - do you expect to use both the config username/password and the token/tokeprovider? My guess is that those should be separate mechanisms. |
openshift logic now functions more like the kube logic and will persist in the kubeconfig, update the current config, and use the config refresh logic to check for updated tokens.
openshift logic now functions more like the kube logic and will persist in the kubeconfig, update the current config, and use the config refresh logic to check for updated tokens.
openshift logic now functions more like the kube logic and will persist in the kubeconfig, update the current config, and use the config refresh logic to check for updated tokens.
Yes and saved / shared for future use. |
openshift logic now functions more like the kube logic and will persist in the kubeconfig, update the current config, and use the config refresh logic to check for updated tokens.
openshift logic now functions more like the kube logic and will persist in the kubeconfig, update the current config, and use the config refresh logic to check for updated tokens.
Is your enhancement related to a problem? Please describe
Related with #4673
When execute a request with Openshift client, the token requested after a failure (403) is stored in an AtomicReference for future requests in OpenShiftOAuthInterceptor.
But in the
before
method in the interceptor, there is a condition:that will never be true because the HttpClientUtils.HeaderInterceptor add a Basic Authorization header if your client has username and password configured; that it is necessary for the authentication requests performed by the OpenShiftOAuthInterceptor.
So, the result is the token stored is never reused, and every request to openshift performs the authentication.
Describe the solution you'd like
A way to avoid the Basic header for Openshift.
If I try to walkaround like this:
then, the first Authentication request to Openshift fails with 401 (the one to
.well-known/oauth-authorization-server
endpoint). Curiously, the second one, to the url returned by the previous request, it adds manually the Basic header.A possible solution could be avoid Basic header filter for openshift, and add it manually for the first request too.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: