Description of problem: this warning in the release notes has no instructions on how to make user-managed oauthaccesstokens compatible: OAuth tokens without a SHA-256 prefix can no longer be used Prior to OpenShift Container Platform 4.6, OAuth access and authorize tokens used secret information for the object names. Starting with OpenShift Container Platform 4.6, OAuth access token and authorize token object names are stored as non-sensitive object names, with a SHA-256 prefix. OAuth tokens that do not contain a SHA-256 prefix can no longer be used or created in OpenShift Container Platform 4.8. Version-Release number of selected component (if applicable): 4.7 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: no procedure to become compliant Expected results: procedure outlining steps by which the following link [1] can be utilised for compliance on the oauth tokens requirement above Additional info: [1] https://github.com/openshift/oauth-server/blob/a51e18174ac32f0e44dfa8946e812d25ff38a101/pkg/server/crypto/sha256.go#L20 [2] https://github.com/openshift/enhancements/blob/master/enhancements/authentication/oauth-resource-storage.md
@milti a relogin should be sufficient. Are you creating those tokens in some automated way?
the issue is that, judging from the number of extant tokens [700+] in the cluster for the oauth-client, a relogin isnt doing the job. this is a user-managed oauthaccesstoken client that manages a workload in the cluster. what does the cu have to do to make the client produce tokens compliant to the new rule on names? OTOH, oauthaccesstokens created by core cluster components ARE compliant w the new rule on the *sha~* prefix.
hello, is there any update on this issue? though the issue isnt critical now, the cu is concerned abt the warning and would like to eliminate it byt getting their user-managed oauthaccesstoken in compliance w the *sha~* prefix naming.
sprint review: due to other high priority work this wasn't been worked on.
mleonard - I'm not entirely sure I follow the use case. From my understanding: - The customer uses OpenShift 4.7 and uses a custom OAuth Client. It would be helpful to check how that client looks like. - The Custom OAuth Client is used by a 3rd party IdP. So effectively, when someone logs in, a new token is being created. - Each user can view his own tokens by calling `oc get useroauthaccesstokens` If my understanding is correct, I believe the customer should delete all non-sha-256 compatible tokens using this procedure: https://access.redhat.com/documentation/en-us/openshift_container_platform/4.7/html/authentication_and_authorization/managing-oauth-access-tokens#oauth-delete-tokens_managing-oauth-access-tokens. This will cause all the users to be logged out and new sha-256-compatible tokens should be created upon the new login. Please let me know if this works for your client.
The new token naming convention has been described in https://github.com/openshift/enhancements/blob/master/enhancements/authentication/oauth-resource-storage.md#proposal: > "sha256~" for new tokens. The name of the token objects is the sha256 hash of the actual token (not decoded, but plain base64) encoded as base64. The bearer token will also carry the prefix, but have the token in plain text. also this part: > Note: the tilde is a valid character in oauth tokens used as bearer tokens (according to RFC6750), and it works as character in URL paths. Colon, which we used in an earlier iteration of this enhancement is not valid for the former. The Golang code that we use to construct such a name might be found here: https://github.com/openshift/oauth-server/blob/a51e18174ac32f0e44dfa8946e812d25ff38a101/pkg/server/crypto/sha256.go#L20: ``` func SHA256Token(token string) string { h := sha256.Sum256([]byte(token)) return SHA256Prefix + base64.RawURLEncoding.EncodeToString(h[0:]) } ``` The sha256 is mentioned in two places in our public documentation: - https://docs.openshift.com/container-platform/4.8/release_notes/ocp-4-8-release-notes.html#ocp-4-8-oauth-tokens - https://docs.openshift.com/container-platform/4.8/authentication/managing-oauth-access-tokens.html#oauth-view-details-toke[…]ing-oauth-access-tokens
We will add additional REST api docs.
This bug is actively worked on.
Testing with 4.10.0-0.nightly-2021-10-07-212540, the statement 'The name of a token must be prefixed ...' added in code is not shown in the DESCRIPTION filed. Please help to double check. $ oc explain oauthaccesstoken KIND: OAuthAccessToken VERSION: oauth.openshift.io/v1 DESCRIPTION: OAuthAccessToken describes an OAuth access token FIELDS: apiVersion <string> APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources authorizeToken <string> AuthorizeToken contains the token that authorized this token ...
bump this in cluster-config-operator to finalize it.
reviewed-in-sprint: not enough capacity to work on this bugzilla.
correction: this needs to be bumped in oauth-apiserver
I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint.
oc explain oauthaccesstoken KIND: OAuthAccessToken VERSION: oauth.openshift.io/v1 DESCRIPTION: OAuthAccessToken describes an OAuth access token. The name of a token must be prefixed with a `sha256~` string, must not contain "/" or "%!"(MISSING) characters and must be at least 32 characters long. The name of the token is constructed from the actual token by sha256-hashing it and using URL-safe unpadded base64-encoding (as described in RFC4648) on the hashed result. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). The description has been updated with "OAuthAccessToken describes an OAuth access token. The name of a token must be prefixed with a `sha256~` string, must not contain "/" or "%!"(MISSING) characters and must be at least 32 characters long." in clusterversion 4.10.0-0.ci.test-2021-11-26-084725-ci-ln-qitlg1k-latest, hence, Verified
oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.10.0-0.nightly-2022-01-24-070025 True False 7h23m Cluster version is 4.10.0-0.nightly-2022-01-24-070025 oc explain oauthaccesstoken KIND: OAuthAccessToken VERSION: oauth.openshift.io/v1 DESCRIPTION: OAuthAccessToken describes an OAuth access token. The name of a token must be prefixed with a `sha256~` string, must not contain "/" or "%!"(MISSING) characters and must be at least 32 characters long. The name of the token is constructed from the actual token by sha256-hashing it and using URL-safe unpadded base64-encoding (as described in RFC4648) on the hashed result. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Which contains "%!"(MISSING) Still facing the issue mentioned in Comment 22, reassigning
This change hasn't been pulled so far. @
Maciej Szulik will know when this gets merged.
It works correctly in 4.10.3: $ oc version Client Version: 4.10.3 Server Version: 4.10.3 Kubernetes Version: v1.23.3+e419edf $ oc explain oauthaccesstoken KIND: OAuthAccessToken VERSION: oauth.openshift.io/v1 DESCRIPTION: OAuthAccessToken describes an OAuth access token. The name of a token must be prefixed with a `sha256~` string, must not contain "/" or "%" characters and must be at least 32 characters long. [...]
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days