Description of problem: While trying to "oc login" with a 4.7.1 oc client to a 4.6.z cluster, it requests to get a token from the web console even for identity providers which usually allow providing user and pasword via oc (reproduced with kubeadmin and LDAP). Version-Release number of selected component (if applicable): Client: 4.7.1 Server: 4.6.20 and some older ones How reproducible: Always Steps to Reproduce: 1. oc login with the version combination above 2. 3. Actual results: Request to get token from web page Expected results: Prompt for user and password so I provide them via oc Additional info: Kubernetes guarantees client/server compatibility for 1 version difference, so 4.7.1 client should behave with a 4.6.20 server correctly as a 4.6.20 does. I'll be attaching detailed "oc login --loglevel=9" outputs in private attachments.
This was intentional change, you can still fallback to the other behavior by explicitly specifying --username flag which will trigger the usual login. The reasoning behind is to force users of using basic-auth credentials which are considered less secure towards web-based flows.
Hi, However this leads to a number of problems: - First of all, any security improvement goes away if this is workaroundable with --username - Given the point above, this just makes "oc login" usability worse with no real improvement. At the end of the day, we will have the users just following the workaround and having a worse experience using the product for nothing. - Last but not least, with the current change implemented, "oc login" would stop working without the workaround if the console is down, even if oauth works. That doesn't look like an acceptable behavior. If you still think this change is still worth it regardless of all these points, I'd be thankful if you could at least provide a full explanation on how this improves security.
Let's step back and ask why do you think passing username and password is secure?
Hi, I understand it was secure enough to have been shipped in every OCP version until OCP 4.7, apart from the obvious things like the use of HTTPS, etc. I also understand that using the other oauth flow is intended to add additional security and it is that benefit what I am asking clarification about.
The idea was that basic authentication (iow. passing username/password directly with kubeadmin user) is enabled initially in the cluster only to help during initial setup. As one of the post-installation steps [1] we advise users to remove kubeadmin (which is using basic authentication provider). To ensure and encourage users to switch away from kubeadmin user we've decided not to promote this mechanism by hiding it behind explicit requirement to pass the flag. Again, what is the exact user request that this is preventing them from working with? [1] https://docs.openshift.com/container-platform/4.7/post_installation_configuration/preparing-for-users.html#understanding-kubeadmin_post-install-preparing-for-users
Basically, the perceived impact comes from 2 points: - The reduced usability due to either requiring the browser or using an extra flag with user/password identity providers (like LDAP or htpasswd). - That usability reduction may become worse in a scenario where the console is down, but oauth isn't, so basic-auth oc login should still work. Not sure if there is some room of this to be reconsidered, but thanks for your insights anyway.
Yeah, if LDAP is their only provider this is definitely a bug and should be fixed, re-opening.
Any update on this? I don't like to install 4.7 without this fixed. Moving this fix to 4.8 is a no go.
*** Bug 1955344 has been marked as a duplicate of this bug. ***
I need to consult with our auth team how to best approach this topic, since on the client side we don't have the information if LDAP is configured as a authentication source.
There's https://issues.redhat.com/browse/RFE-1588 which could potentially improve this situation having the ability so specify the IdP directly would make it obvious what to do and how to react.
Hey, any updates hereon #comment 30?
Since this is an intentional change, I'm closing this as WONTFIX and feel free to re-open it if you think otherwise.