Bug 1893999 - can't login ocp cluster with oc 4.7 client without the username
Summary: can't login ocp cluster with oc 4.7 client without the username
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 4.7
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.8.0
Assignee: Maciej Szulik
QA Contact: zhou ying
URL:
Whiteboard: non-multi-arch
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-03 09:46 UTC by zhou ying
Modified: 2022-04-18 13:26 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-27 22:34:10 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift oc issues 817 0 None open cannot log into ocp cluster with oc 4.7 client without the username (oc login vs oc login --username) 2021-05-03 08:57:31 UTC
Github openshift oc pull 834 0 None open Bug 1893999: guide user to provide username with basic auth error/only password IDP and no username provided 2021-05-24 22:37:11 UTC
Red Hat Knowledge Base (Solution) 6008921 0 None None None 2021-04-30 15:02:42 UTC
Red Hat Product Errata RHSA-2021:2438 0 None None None 2021-07-27 22:34:30 UTC

Description zhou ying 2020-11-03 09:46:51 UTC
Description of problem:
When use oc 4.7 to login the ocp4.6 cluster , with hit error: 
I1103 16:06:00.599236   23413 request.go:1097] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"configmaps \"motd\" is forbidden: User \"system:anonymous\" cannot get resource \"configmaps\" in API group \"\" in the namespace \"openshift\"","reason":"Forbidden","details":{"name":"motd","kind":"configmaps"},"code":403}
You must obtain an API token by visiting https://oauth-openshift.apps.yinzhou1103.qe.devcluster.openshift.com/oauth/token/request


Version-Release number of selected component (if applicable):
Client Version: 4.7.0-0.nightly-2020-11-03-040426

How reproducible:
Always

Steps to Reproduce:
1. Use the oc4.7 to login ocp4.6 cluster

Actual results:
1. The output show:
[root@dhcp-140-138 home]# oc login https://api.yinzhou1103.qe.devcluster.openshift.com:6443
You must obtain an API token by visiting https://oauth-openshift.apps.yinzhou1103.qe.devcluster.openshift.com/oauth/token/request
[root@dhcp-140-138 home]# oc login https://api.yinzhou1103.qe.devcluster.openshift.com:6443 -v 9
I1103 16:05:56.730232   23413 loader.go:375] Config loaded from file:  /root/.kube/config
I1103 16:05:56.730614   23413 round_trippers.go:423] curl -k -v -XHEAD  'https://api.yinzhou1103.qe.devcluster.openshift.com:6443/'
I1103 16:05:57.245628   23413 round_trippers.go:443] HEAD https://api.yinzhou1103.qe.devcluster.openshift.com:6443/  in 514 milliseconds
I1103 16:05:57.245657   23413 round_trippers.go:449] Response Headers:
I1103 16:05:57.245719   23413 round_trippers.go:423] curl -k -v -XHEAD  'https://api.yinzhou1103.qe.devcluster.openshift.com:6443/'
I1103 16:05:57.964887   23413 round_trippers.go:443] HEAD https://api.yinzhou1103.qe.devcluster.openshift.com:6443/ 403 Forbidden in 719 milliseconds
I1103 16:05:57.964917   23413 round_trippers.go:449] Response Headers:
I1103 16:05:57.964930   23413 round_trippers.go:452]     Content-Type: application/json
I1103 16:05:57.964943   23413 round_trippers.go:452]     X-Content-Type-Options: nosniff
I1103 16:05:57.964953   23413 round_trippers.go:452]     X-Kubernetes-Pf-Flowschema-Uid: 25a7090f-ac12-4ff1-a020-ea768b23401c
I1103 16:05:57.964962   23413 round_trippers.go:452]     X-Kubernetes-Pf-Prioritylevel-Uid: 4555086d-c7f5-4d0d-8db6-c3c418f9d54c
I1103 16:05:57.964970   23413 round_trippers.go:452]     Content-Length: 186
I1103 16:05:57.964982   23413 round_trippers.go:452]     Date: Tue, 03 Nov 2020 08:05:57 GMT
I1103 16:05:57.964994   23413 round_trippers.go:452]     Audit-Id: 5af6b794-437f-465e-adca-bb81a3a0eaac
I1103 16:05:57.965004   23413 round_trippers.go:452]     Cache-Control: no-cache, private
I1103 16:05:57.965021   23413 request_token.go:89] GSSAPI Enabled
I1103 16:05:57.965100   23413 round_trippers.go:423] curl -k -v -XGET  -H "X-Csrf-Token: 1" 'https://api.yinzhou1103.qe.devcluster.openshift.com:6443/.well-known/oauth-authorization-server'
I1103 16:05:58.203380   23413 round_trippers.go:443] GET https://api.yinzhou1103.qe.devcluster.openshift.com:6443/.well-known/oauth-authorization-server 200 OK in 238 milliseconds
I1103 16:05:58.203406   23413 round_trippers.go:449] Response Headers:
I1103 16:05:58.203423   23413 round_trippers.go:452]     X-Kubernetes-Pf-Flowschema-Uid: 25a7090f-ac12-4ff1-a020-ea768b23401c
I1103 16:05:58.203436   23413 round_trippers.go:452]     X-Kubernetes-Pf-Prioritylevel-Uid: 4555086d-c7f5-4d0d-8db6-c3c418f9d54c
I1103 16:05:58.203447   23413 round_trippers.go:452]     Content-Length: 657
I1103 16:05:58.203458   23413 round_trippers.go:452]     Date: Tue, 03 Nov 2020 08:05:58 GMT
I1103 16:05:58.203468   23413 round_trippers.go:452]     Audit-Id: fe8ca789-0c9e-4055-aada-1c852cd20a5d
I1103 16:05:58.203479   23413 round_trippers.go:452]     Cache-Control: no-cache, private
I1103 16:05:58.203490   23413 round_trippers.go:452]     Content-Type: application/json
I1103 16:05:58.928216   23413 request_token.go:470] falling back to kubeconfig CA due to possible x509 error: x509: certificate signed by unknown authority
I1103 16:05:58.928306   23413 round_trippers.go:423] curl -k -v -XGET  -H "X-Csrf-Token: 1" 'https://oauth-openshift.apps.yinzhou1103.qe.devcluster.openshift.com/oauth/authorize?client_id=openshift-challenging-client&code_challenge=luJBL74TUTkQd2EKmHMhhFcOeTTQynL9__sZEhRv3F4&code_challenge_method=S256&redirect_uri=https%3A%2F%2Foauth-openshift.apps.yinzhou1103.qe.devcluster.openshift.com%2Foauth%2Ftoken%2Fimplicit&response_type=code'
I1103 16:06:00.359554   23413 round_trippers.go:443] GET https://oauth-openshift.apps.yinzhou1103.qe.devcluster.openshift.com/oauth/authorize?client_id=openshift-challenging-client&code_challenge=luJBL74TUTkQd2EKmHMhhFcOeTTQynL9__sZEhRv3F4&code_challenge_method=S256&redirect_uri=https%3A%2F%2Foauth-openshift.apps.yinzhou1103.qe.devcluster.openshift.com%2Foauth%2Ftoken%2Fimplicit&response_type=code 401 Unauthorized in 1431 milliseconds
I1103 16:06:00.359592   23413 round_trippers.go:449] Response Headers:
I1103 16:06:00.359605   23413 round_trippers.go:452]     X-Frame-Options: DENY
I1103 16:06:00.359615   23413 round_trippers.go:452]     X-Xss-Protection: 1; mode=block
I1103 16:06:00.359630   23413 round_trippers.go:452]     Expires: 0
I1103 16:06:00.359642   23413 round_trippers.go:452]     Referrer-Policy: strict-origin-when-cross-origin
I1103 16:06:00.359655   23413 round_trippers.go:452]     Www-Authenticate: Basic realm="openshift"
I1103 16:06:00.359666   23413 round_trippers.go:452]     X-Content-Type-Options: nosniff
I1103 16:06:00.359677   23413 round_trippers.go:452]     Content-Length: 0
I1103 16:06:00.359687   23413 round_trippers.go:452]     Cache-Control: no-cache, no-store, max-age=0, must-revalidate
I1103 16:06:00.359698   23413 round_trippers.go:452]     Pragma: no-cache
I1103 16:06:00.359708   23413 round_trippers.go:452]     X-Dns-Prefetch-Control: off
I1103 16:06:00.359717   23413 round_trippers.go:452]     Date: Tue, 03 Nov 2020 08:05:59 GMT
I1103 16:06:00.359776   23413 multi.go:78] handler[0] error: did not receive username - print token url instead of basic prompt
I1103 16:06:00.359810   23413 request_token.go:240] did not receive username - print token url instead of basic prompt
I1103 16:06:00.360538   23413 round_trippers.go:423] curl -k -v -XGET  -H "User-Agent: oc/openshift (linux/amd64) kubernetes/8150994" -H "Accept: application/json, */*" 'https://api.yinzhou1103.qe.devcluster.openshift.com:6443/api/v1/namespaces/openshift/configmaps/motd'
I1103 16:06:00.599092   23413 round_trippers.go:443] GET https://api.yinzhou1103.qe.devcluster.openshift.com:6443/api/v1/namespaces/openshift/configmaps/motd 403 Forbidden in 238 milliseconds
I1103 16:06:00.599118   23413 round_trippers.go:449] Response Headers:
I1103 16:06:00.599132   23413 round_trippers.go:452]     X-Content-Type-Options: nosniff
I1103 16:06:00.599144   23413 round_trippers.go:452]     X-Kubernetes-Pf-Flowschema-Uid: 25a7090f-ac12-4ff1-a020-ea768b23401c
I1103 16:06:00.599157   23413 round_trippers.go:452]     X-Kubernetes-Pf-Prioritylevel-Uid: 4555086d-c7f5-4d0d-8db6-c3c418f9d54c
I1103 16:06:00.599166   23413 round_trippers.go:452]     Content-Length: 303
I1103 16:06:00.599175   23413 round_trippers.go:452]     Date: Tue, 03 Nov 2020 08:06:00 GMT
I1103 16:06:00.599184   23413 round_trippers.go:452]     Audit-Id: fa69b07e-c073-447d-80bc-e0bed8cbc644
I1103 16:06:00.599196   23413 round_trippers.go:452]     Cache-Control: no-cache, private
I1103 16:06:00.599207   23413 round_trippers.go:452]     Content-Type: application/json
I1103 16:06:00.599236   23413 request.go:1097] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"configmaps \"motd\" is forbidden: User \"system:anonymous\" cannot get resource \"configmaps\" in API group \"\" in the namespace \"openshift\"","reason":"Forbidden","details":{"name":"motd","kind":"configmaps"},"code":403}
You must obtain an API token by visiting https://oauth-openshift.apps.yinzhou1103.qe.devcluster.openshift.com/oauth/token/request

Expected results:
1. Login succeed. 


Additional info:
export KUBECONFIG and run oc login -u <user> -p <passwd> works well.

Comment 2 Sally 2020-11-12 17:54:01 UTC
Adding UpcomingSprint, actively working on this.

Comment 3 Sally 2020-12-05 00:05:26 UTC
this got away from me with other bugs taking priority, adding upcoming sprint

Comment 4 Michal Fojtik 2021-01-04 00:58:21 UTC
This bug hasn't had any activity in the last 30 days. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're marking this bug as "LifecycleStale" and decreasing the severity/priority. If you have further information on the current state of the bug, please update it, otherwise this bug can be closed in about 7 days. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. Additionally, you can add LifecycleFrozen into Keywords if you think this bug should never be marked as stale. Please consult with bug assignee before you do that.

Comment 5 zhou ying 2021-01-04 02:01:33 UTC
The issue can be reproduce with cluster 4.7:
[root@dhcp-140-138 ~]# oc login https://api.yinzhou0104.qe.devcluster.openshift.com:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y

You must obtain an API token by visiting https://oauth-openshift.apps.yinzhou0104.qe.devcluster.openshift.com/oauth/token/request
[root@dhcp-140-138 ~]# oc version 
Client Version: 4.7.0-202012220147.p0-8fbc95f

Comment 6 Sally 2021-01-04 21:09:52 UTC
I finally have looked into this bug and it appears all is working as intended. Please re-open if I'm missing something. Please see this change, https://github.com/openshift/oc/pull/553.

* If a user provides `oc login -u anything`, user will get the basic auth prompt. 
* If there is only password IDP available, and no username was provided, show the tokenURL message instead of a basic auth prompt.

Also, I am not able to reproduce the issue from the comment above, with logging into api.ci.openshift.org and an oc 4.7 client.
I see the prompt to get the token like so, 

$ oc login https://api.ci.openshift.org 
Login failed (401 Unauthorized)
Verify you have provided correct credentials.
You must obtain an API token by visiting https://api.ci.openshift.org/oauth/token/request

and then this works as expected after obtaining the login cmd:
$ oc login --token=REDACTED --server=https://api.ci.openshift.org

Comment 7 Chet Hosey 2021-04-26 13:42:00 UTC
This doesn't work `as expected` if the user's expectations are that the same process that worked for them in 4.1 -> 4.6 will work in 4.7.

Previously a user could do `oc login --server=<url>` initially and enter credentials. Once the initial login expired they could simply `oc login` and be prompted for credentials.

At best this is now broken, with an indirect and inconvenient workaround. Compare:

1) Load the web UI
2) Enter credentials to log in
3) Click your name in the upper right
4) Click "Copy Login Command"
5) Enter credentials to log in *again*
6) Click "display token"
7) Highlight the command
8) Copy the command to the clipboard
9) Return to the console
10) Paste the login token

With:

1) Type "oc login"
2) Enter credentials to log in

Users should also be uncomfortable with doing this process on a shared screen, as participants may be able to take a screen capture and reuse the token.

Comment 8 Andreas Karis 2021-04-30 15:00:07 UTC
I'm reopening this.
~~~
[root@openshift-jumpserver-0 ~]# oc login
You must obtain an API token by visiting https://oauth-openshift.apps.ipi-cluster.example.com/oauth/token/request
[root@openshift-jumpserver-0 ~]# oc version
Client Version: 4.7.5
Server Version: 4.7.5
Kubernetes Version: v1.20.0+bafe72f
~~~

Just to reiterate, the workaround is to provide a username on the CLI with --username:
~~~
[root@openshift-jumpserver-0 ~]# oc login --username=myself
Authentication required for https://api.ipi-cluster.example.com:6443 (openshift)
Username: myself
Password: 
~~~

I agree though with the assessment from the previous comment. At best, it is not nice to change a user facing component, at worst, it is really frustrating. And our users should not have to google or guess to figure this out.

If we really must change the `oc` CLI behavior (and likely there is a good reason for this change) and if we cannot default back to the old, well-known behavior, we should at least provide a Note/Warning to users for the next few versions such as:
~~~
[root@openshift-jumpserver-0 ~]# oc login
You must obtain an API token by visiting https://oauth-openshift.apps.ipi-cluster.example.com/oauth/token/request
INFO: The behavior of `oc login` changed.
INFO: If you wish to login via username and password prompt, provide the --username <username> parameter
~~~

Thanks,

Andreas

Comment 9 Andreas Karis 2021-04-30 15:05:23 UTC
Also see
https://github.com/code-ready/crc/issues/2032

Comment 10 david.gabrysch 2021-05-12 08:41:00 UTC
We have the same behaviour now on 4.6.20 which is not nice since our colleagues are asking why this happened, there should be at least something easily visible in the changelogs or so. 

Is this behaviour intended, and if yes, how can we override this? This is an additional step for everybody (I guess it can be done via a snippet or so?)

The docs here (please note, 4.6): https://docs.openshift.com/container-platform/4.6/cli_reference/openshift_cli/getting-started-cli.html say that one needs to use "oc login" without the "-u" option, the 4.7 docs are upgraded. 

If this was intended it is a rather breaking change from a user perspective which came in with a minor upgrade.

Comment 11 Sally 2021-05-24 22:36:35 UTC
The docs have been updated for 4.7. I don't see this change in 4.6, however.
4.7:  https://github.com/openshift/oc/blob/release-4.7/pkg/helpers/tokencmd/basicauth.go#L17-#L28

I've opened this to guide users to provide username for password prompt when the BasicAuthNoUsername error is thrown. 
https://github.com/openshift/oc/pull/834

Comment 12 Chet Hosey 2021-05-25 00:12:22 UTC
As far as I can tell this doesn’t restore the original functionality, or explain why it’s necessary to break existing behavior.

Comment 13 Maciej Szulik 2021-06-08 14:56:12 UTC
Also related https://bugzilla.redhat.com/show_bug.cgi?id=1939403

Comment 15 zhou ying 2021-06-11 01:49:44 UTC
The default prompt is : 

[root@localhost ~]# oc login https://api.yinzhou.qe.gcp.devcluster.openshift.com:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y

You must obtain an API token by visiting https://oauth-openshift.apps.yinzhou.qe.gcp.devcluster.openshift.com/oauth/token/request

Only with `-v 2` could see the guide infomation :

[root@localhost ~]# oc login https://api.yinzhou.qe.gcp.devcluster.openshift.com:6443 -v 2
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y

I0611 09:25:01.288043 1901866 request_token.go:240] did not receive username. Pass 'oc login --username <username>' for the password prompt
You must obtain an API token by visiting https://oauth-openshift.apps.yinzhou.qe.gcp.devcluster.openshift.com/oauth/token/request


Could we prompt the guide infomation default ?

Comment 16 Chet Hosey 2021-06-11 02:07:21 UTC
There's still no explanation as to why the existing behavior needs to change.

What is the aim of forcing people to give the username as a parameter instead of interactively prompting for it?

Whatever this is meant to convey to the user (or to the cluster admin?), it isn't doing the job.

Is there a reason why it's preferred to force users to specify the flag instead of entering it at a prompt?

Comment 17 Maciej Szulik 2021-06-11 07:11:16 UTC
(In reply to Chet Hosey from comment #16)
> Is there a reason why it's preferred to force users to specify the flag
> instead of entering it at a prompt?

See https://bugzilla.redhat.com/show_bug.cgi?id=1939403 for details behind that decision


(In reply to zhou ying from comment #15)
> Could we prompt the guide infomation default ?

I'll see what's possible.

Comment 18 Chet Hosey 2021-06-11 07:26:10 UTC
(In reply to Maciej Szulik from comment #17)
> (In reply to Chet Hosey from comment #16)
> > Is there a reason why it's preferred to force users to specify the flag
> > instead of entering it at a prompt?
> 
> See https://bugzilla.redhat.com/show_bug.cgi?id=1939403 for details behind
> that decision

The only justification I saw is that it’s meant to encourage administrators to disable the default user account.

It’s not clear how breaking the login process for existing users is the best way to convey that message.

And, having disabled the kubeadmin user immediately after installation long ago, the prompt isn’t restored.

Can you help me to understand how making users specify their ID as an argument instead of prompting interactively for it achieves the stated goal of getting admins to disable the default account? Might there instead be a warning on the administration console, encouraging the administrator to disable the account at their earliest opportunity?

Or if the goal is to get people to avoid using the interactive login, might a warning before the interactive prompt suffice?

Comment 19 Chet Hosey 2021-06-11 07:32:01 UTC
Ideally there would be an explanation as to why entering my Active Directory credentials in the browser is more secure than providing them via the CLI.

If that’s really the case, might that be treated as a bug in itself rather than using inconvenience to discourage CLI login?

And if it’s not the case, I’m afraid I just don’t understand the goal of this change.

Comment 21 Maciej Szulik 2021-06-21 10:41:56 UTC
We're hoping to to change the flow in one of next releases such that this entire flow will be significantly simpler, apologies for the inconvenience in the mean time.

Comment 22 zhou ying 2021-06-22 00:40:33 UTC
Since https://bugzilla.redhat.com/show_bug.cgi?id=1893999#c15 has confirmed the PR for this issue , will move to verified .

Comment 24 errata-xmlrpc 2021-07-27 22:34:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:2438

Comment 25 Chet Hosey 2021-07-27 22:57:13 UTC
(In reply to Maciej Szulik from comment #21)
> We're hoping to to change the flow in one of next releases such that this
> entire flow will be significantly simpler, apologies for the inconvenience
> in the mean time.

How could it be simpler than the original functionality?

Why not just warn when the user enters "kubeadmin" as a username?

What is the actual benefit of making this process harder for users? And might there be a better way of getting the same results that doesn't make the process harder for everyone?

Comment 26 brian 2021-09-28 13:40:35 UTC
Are there plans to backport this to 4.7.x?

Comment 27 Maciej Szulik 2021-10-04 15:48:24 UTC
(In reply to brian from comment #26)
> Are there plans to backport this to 4.7.x?

Nope, since this will required server-side changes implemented before we do that on the oc side.


Note You need to log in before you can comment on or make changes to this bug.