Bug 1986504

Summary: docs should contain an information on how the oauthaccesstokens can be created manually
Product: OpenShift Container Platform Reporter: milti leonard <mleonard>
Component: apiserver-authAssignee: Sebastian Łaskawiec <slaskawi>
Status: CLOSED CURRENTRELEASE QA Contact: Yash Tripathi <ytripath>
Severity: low Docs Contact:
Priority: low    
Version: 4.7CC: aos-bugs, mfojtik, slaskawi, slaznick, surbania, xxia, ytripath
Target Milestone: ---Flags: ytripath: needinfo-
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-04-21 07:50:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description milti leonard 2021-07-27 17:20:53 UTC
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

Comment 1 Sergiusz Urbaniak 2021-07-30 08:37:54 UTC
@milti a relogin should be sufficient. Are you creating those tokens in some automated way?

Comment 2 milti leonard 2021-08-05 15:46:38 UTC
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.

Comment 3 milti leonard 2021-08-09 15:29:39 UTC
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.

Comment 4 Sergiusz Urbaniak 2021-08-16 12:48:46 UTC
sprint review: due to other high priority work this wasn't been worked on.

Comment 5 Sebastian Łaskawiec 2021-08-23 10:44:09 UTC
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.

Comment 8 Sebastian Łaskawiec 2021-08-26 06:31:15 UTC
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

Comment 9 Sebastian Łaskawiec 2021-08-26 06:53:35 UTC
We will add additional REST api docs.

Comment 10 Sebastian Łaskawiec 2021-09-03 05:59:01 UTC
This bug is actively worked on.

Comment 12 liyao 2021-10-08 10:08:03 UTC
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

...

Comment 13 Sergiusz Urbaniak 2021-10-12 12:53:47 UTC
bump this in cluster-config-operator to finalize it.

Comment 14 Sergiusz Urbaniak 2021-11-08 06:55:29 UTC
reviewed-in-sprint: not enough capacity to work on this bugzilla.

Comment 15 Sergiusz Urbaniak 2021-11-09 07:23:27 UTC
correction: this needs to be bumped in oauth-apiserver

Comment 20 Sergiusz Urbaniak 2021-11-26 07:25:27 UTC
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.

Comment 21 Yash Tripathi 2021-11-26 21:53:02 UTC
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

Comment 24 Yash Tripathi 2022-01-25 02:58:10 UTC
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

Comment 25 Sebastian Łaskawiec 2022-01-25 07:21:18 UTC
This change hasn't been pulled so far. @

Comment 26 Sebastian Łaskawiec 2022-01-25 07:21:53 UTC
Maciej Szulik will know when this gets merged.

Comment 28 Sebastian Łaskawiec 2022-04-21 07:50:29 UTC
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.
[...]

Comment 29 Red Hat Bugzilla 2023-09-15 01:12:09 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days