Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1951637

Summary:	don't rollout a new kube-apiserver revision on oauth accessTokenInactivityTimeout changes
Product:	OpenShift Container Platform	Reporter:	Standa Laznicka <slaznick>
Component:	kube-apiserver	Assignee:	Standa Laznicka <slaznick>
Status:	CLOSED ERRATA	QA Contact:	Ke Wang <kewang>
Severity:	medium	Docs Contact:
Priority:	high
Version:	4.8	CC:	aos-bugs, kewang, mfojtik, xxia
Target Milestone:	---
Target Release:	4.8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-07-27 23:02:11 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 Standa Laznicka 2021-04-20 15:42:55 UTC

Description of problem:
kube-apiserver-operator will attempt to rollout a new revision when oauth/cluster spec.tokenConfig.accessTokenInactivityTimeout field changes

Version-Release number of selected component (if applicable):
4.8

How reproducible:
100%

Steps to Reproduce:
1. edit the oauth.spec.tokenConfig.accessTokenInactivityTimeout field

Actual results:
new rollout of kube-apiservers is started

Expected results:
no new rollouts of kube-apiservers should be triggered if webhook token authenticators are already configured

Comment 2 Xingxing Xia 2021-04-21 01:58:18 UTC

Really? Saw this happen when trying https://issues.redhat.com/browse/API-471 but thought it was not bug, maybe "if webhook token authenticators are already configured" is the difference between. Ke, when verifying, could discuss with Pravin if necessary. Thanks

Comment 3 Ke Wang 2021-04-25 08:52:29 UTC

$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.8.0-0.nightly-2021-04-24-234710   True        False         47m     Cluster version is 4.8.0-0.nightly-2021-04-24-234710

$ oc patch oauth.config cluster -p '{"spec":{"tokenConfig":{"accessTokenInactivityTimeout": "600s"}}}' --type='merge'

$  oc get oauth cluster -o json | jq '.spec.tokenConfig'
{
  "accessTokenInactivityTimeout": "600s"
}

After several minutes, check operators, only authentication is rolling out, kube-apiserver doesn't occur.
$ oc get co --no-headers | grep -v '.True.*False.*False'
authentication                             4.8.0-0.nightly-2021-04-24-234710   True   True    False   13m

Created one user testuser and logged in,
$ oc login -u testuser 
Authentication required for https://api.ci-ln-8fi1h9b-002ac.ci.azure.devcluster.openshift.com:6443 (openshift)
Username: testuser
Password: 
Login successful.
...

$ TOKEN=`oc whoami -t`

$ oc config use-context admin
Switched to context "admin".

$ oc get oauthaccesstoken --sort-by .metadata.creationTimestamp
NAME                                                 USER NAME   CLIENT NAME                    CREATED                EXPIRES                         REDIRECT URI                                                                                              SCOPES
sha256~<TOKEN>  testuser    openshift-challenging-client   2021-04-25T08:23:08Z   2021-04-26 08:23:08 +0000 UTC   https://oauth-openshift.apps.ci-ln-8fi1h9b-002ac.ci.azure.devcluster.openshift.com/oauth/token/implicit   user:full

$ oc get oauthaccesstoken sha256~<TOKEN> -oyaml | grep inactivity
inactivityTimeoutSeconds: 600
...

Logged in again,
$ oc login --token="$TOKEN"
Logged into "https://api.ci-ln-8fi1h9b-002ac.ci.azure.devcluster.openshift.com:6443" as "testuser" using the token provided.

After the time specified by the inactivity time-out, login again,
$ oc login --token="$TOKEN"
error: The token provided is invalid or expired.

From above, without kube-apiserver, there is no impact on the feature inactivityTimeoutSeconds, the PR works as expected, so move the bug VERIFIED

Comment 6 errata-xmlrpc 2021-07-27 23:02:11 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