-
Bug
-
Resolution: Done-Errata
-
Normal
-
4.15
-
No
-
False
-
This is a clone of issue OCPBUGS-21626. The following is the description of the original issue:
—
Description: If tokenConfig.accessTokenInactivityTimeout set to less than 300s, the accessTokenInactivityTimeout doesn't work in hosted cluster whereas in Management cluster, we get below error while trying to set the timeout < 300s :
spec.tokenConfig.accessTokenInactivityTimeout: Invalid value: v1.Duration{Duration:100000000000}: the minimum acceptable token timeout value is 300 seconds*
Steps to reproduce the issue:
1. Install a fresh 4.15 hypershift cluster 2. Configure accessTokenInactivityTimeout as below: $ oc edit hc -n clusters ... spec: configuration: oauth: identityProviders: ... tokenConfig: accessTokenInactivityTimeout: 100s ... 3. Wait for the oauth pods to redeploy and check the oauth cm for updated accessTokenInactivityTimeout value: $ oc get cm oauth-openshift -oyaml -n clusters-hypershift-ci-xxxxx ... tokenConfig: accessTokenInactivityTimeout: 1m40s ... 4. Login to guest cluster with testuser-1 and get the token $ oc login https://a889<...>:6443 -u testuser-1 -p xxxxxxx $ TOKEN=`oc whoami -t`
Actual result:
Wait for 100s and try login with the TOKEN $ oc login --token="$TOKEN" WARNING: Using insecure TLS client config. Setting this option is not supported! Logged into "https://a889<...>:6443" as "testuser-1" using the token provided. You don't have any projects. You can try to create a new project, by running oc new-project <projectname>
Expected result:
1. Login fails if the user is not active within the accessTokenInactivityTimeout seconds.
2. In Management cluster, we get below error when trying to set the timeout to less than 300s :
spec.tokenConfig.accessTokenInactivityTimeout: Invalid value: v1.Duration{Duration:100000000000}: the minimum acceptable token timeout value is 300 seconds*
Implement the same in hosted cluster.
- clones
-
-
- Closed
-
- is blocked by
-
-
- Closed
-
- links to
-
RHBA-2024:0204
OpenShift Container Platform 4.14.z bug fix update
[OCPBUGS-22360] tokenConfig's accessTokenInactivityTimeout in hosted cluster is not consistent with management cluster
Below is the verification steps:
# cat cluster.yaml | grep -A1 tokenConfig tokenConfig: accessTokenInactivityTimeout: 100s # oc apply -f cluster.yaml The HostedCluster "hypershift-ci-25146" is invalid: spec.configuration.oauth: Invalid value: "object": spec.configuration.oauth.tokenConfig.accessTokenInactivityTimeout minimum acceptable token timeout value is 300 seconds Changed accessTokenInactivityTimeout to 300s # cat cluster.yaml | grep -A1 tokenConfig tokenConfig: accessTokenInactivityTimeout: 300s # oc apply -f cluster.yaml hostedcluster.hypershift.openshift.io/hypershift-ci-25146 configured Login Hypershift cluster configured using user # oc login -u user --kubeconfig=./hypershift-ci-25146.kubeconfig Console URL: https://af4117a73738941d6b853a0c0af0f755-750fb07d10004490.elb.us-east-2.amazonaws.com:6443/console Authentication required for https://af4117a73738941d6b853a0c0af0f755-750fb07d10004490.elb.us-east-2.amazonaws.com:6443 (openshift) Username: user Password: Login successful. You don't have any projects. You can try to create a new project, by running oc new-project <projectname> # TOKEN=`oc whoami -t --kubeconfig=./hypershift-ci-25146.kubeconfig` # oc login --token="$TOKEN" https://af4117a73738941d6b853a0c0af0f755-750fb07d10004490.elb.us-east-2.amazonaws.com:6443 WARNING: Using insecure TLS client config. Setting this option is not supported! Logged into "https://af4117a73738941d6b853a0c0af0f755-750fb07d10004490.elb.us-east-2.amazonaws.com:6443" as "user" using the token provided. You don't have any projects. You can try to create a new project, by running oc new-project <projectname> # sleep 300s && oc login --token="$TOKEN" https://af4117a73738941d6b853a0c0af0f755-750fb07d10004490.elb.us-east-2.amazonaws.com:6443 WARNING: Using insecure TLS client config. Setting this option is not supported! error: The token provided is invalid or expired.
OpenShift Jira Bot
added a comment - Bugs should not be moved to Verified without first providing a Release Note Type("Bug Fix" or "No Doc Update") and for type "Bug Fix" the Release Note Text must also be provided. Please populate the necessary fields before moving the Bug to Verified.
OpenShift Jira Bot
added a comment - Hi agarcial@redhat.com ,
Bugs should not be moved to Verified without first providing a Release Note Type("Bug Fix" or "No Doc Update") and for type "Bug Fix" the Release Note Text must also be provided. Please populate the necessary fields before moving the Bug to Verified. OpenShift Jira Bot
added a comment - Looks like this bug is far enough along in the workflow that a code fix is ready. Customers and support need to know the backport plan. Please complete the "Target Backport Versions" field to indicate which version(s) will receive the fix.
OpenShift Jira Bot
added a comment - Looks like this bug is far enough along in the workflow that a code fix is ready. Customers and support need to know the backport plan. Please complete the " Target Backport Versions " field to indicate which version(s) will receive the fix.
Since the problem described in this issue should be resolved in a recent advisory, it has been closed.
For information on the advisory (Moderate: OpenShift Container Platform 4.14.9 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-2024:0204