Description of problem: When lowering the inactivity timeout for tokens either by configuration at an oauthclient or in the oauth/cluster object, the tokens don't get their timeout shortened so that they would time out at max (time.Now() + newTimeoutValue) Version-Release number of selected component (if applicable): 4.6 How reproducible: always Steps to Reproduce: 1. configure inactivity timeout to 15 minutes 2. create a token by logging in at any openshift component 3. lower the inactivity timeout to 5 minutes Actual results: token from 2. keeps its original timeout Expected results: token from 2. gets a new timeout which makes it time out at max (Now + newShorterTimeout)
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.
as discussed OOB this needs to slip.
This needs documentation in the API.
@Standa, the change in PR https://github.com/openshift/api/pull/989/files is not bumped. Please help check.
The cluster-config-operator bump already happened in one of the many bump PRs, moving to MODIFIED.
I just realized that we need the bump in the oauth-apiserver as well.
The bump merged in https://github.com/openshift/oauth-apiserver/pull/63
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.
Verified on 4.10.0-0.nightly-2021-11-25-205516 oc explain oauth.spec.tokenConfig.accessTokenInactivityTimeout KIND: OAuth VERSION: config.openshift.io/v1 FIELD: accessTokenInactivityTimeout <string> DESCRIPTION: accessTokenInactivityTimeout defines the token inactivity timeout for tokens granted by any client. The value represents the maximum amount of time that can occur between consecutive uses of the token. Tokens become invalid if they are not used within this temporal window. The user will need to acquire a new token to regain access once a token times out. Takes valid time duration string such as "5m", "1.5h" or "2h45m". The minimum allowed value for duration is 300s (5 minutes). If the timeout is configured per client, then that value takes precedence. If the timeout value is not specified and the client does not override the value, then tokens are valid until their lifetime. WARNING: existing tokens' timeout will not be affected (lowered) by changing this value
The "WARNING: existing tokens' timeout will not be affected (lowered) by changing this value" is present in the description of tokenConfig.accessTokenInactivityTimeout in clusterversion 4.10.0-0.nightly-2021-11-25-205516
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.10.3 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-2022:0056