3.5. Configuration du délai d'inactivité du jeton pour le serveur OAuth interne
Vous pouvez configurer les jetons OAuth pour qu'ils expirent après une période d'inactivité donnée. Par défaut, aucun délai d'inactivité n'est défini.
Si le délai d'inactivité du jeton est également configuré dans votre client OAuth, cette valeur remplace le délai défini dans la configuration interne du serveur OAuth.
Conditions préalables
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
. - Vous avez configuré un fournisseur d'identité (IDP).
Procédure
Mettre à jour la configuration de
OAuth
pour définir un délai d'inactivité des jetons.Modifiez l'objet
OAuth
:$ oc edit oauth cluster
Ajoutez le champ
spec.tokenConfig.accessTokenInactivityTimeout
et définissez la valeur de votre délai d'attente :apiVersion: config.openshift.io/v1 kind: OAuth metadata: ... spec: tokenConfig: accessTokenInactivityTimeout: 400s 1
- 1
- Définissez une valeur avec les unités appropriées, par exemple
400s
pour 400 secondes, ou30m
pour 30 minutes. La valeur minimale autorisée pour le délai d'attente est300s
.
- Enregistrez le fichier pour appliquer les modifications.
Vérifier que les pods du serveur OAuth ont redémarré :
$ oc get clusteroperators authentication
Ne passez pas à l'étape suivante tant que
PROGRESSING
n'est pas répertorié commeFalse
, comme le montre le résultat suivant :Exemple de sortie
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.12.0 True False False 145m
Vérifiez qu'une nouvelle révision des pods du serveur Kubernetes API a été déployée. Cela prendra plusieurs minutes.
$ oc get clusteroperators kube-apiserver
Ne passez pas à l'étape suivante tant que
PROGRESSING
n'est pas répertorié commeFalse
, comme le montre le résultat suivant :Exemple de sortie
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE kube-apiserver 4.12.0 True False False 145m
Si
PROGRESSING
afficheTrue
, attendez quelques minutes et réessayez.
Vérification
- Connectez-vous au cluster avec l'identité de votre IDP.
- Exécuter une commande et vérifier qu'elle a abouti.
- Attendre plus longtemps que le délai configuré sans utiliser l'identité. Dans l'exemple de cette procédure, il faut attendre plus de 400 secondes.
Essayer d'exécuter une commande à partir de la session de la même identité.
Cette commande doit échouer car le jeton doit avoir expiré en raison d'une inactivité plus longue que le délai d'attente configuré.
Exemple de sortie
error: You must be logged in to the server (Unauthorized)