1 changed files with 99 additions and 0 deletions
@ -0,0 +1,99 @@ |
|||
--- |
|||
title: "Mettre à jour la configuration de l'Identity Provider OpenShift, version ceinture, bretelles et parachute" |
|||
date: 2023-12-18T00:00:00+02:00 |
|||
opensource: |
|||
- OpenShift |
|||
--- |
|||
|
|||
Depuis OpenShift 4, la configuration de l'*Identity Provider* OpenShift est gérée sous la forme de *Custom Resource Definitions* (CRD) Kubernetes. |
|||
Ce mécanisme permet de modifier sa configuration en utilisant l'API Kubernetes. |
|||
Mais si l'accès à l'API Kubernetes est soumis à l'authentification du dit *Identity Provider*, n'y a t'il pas un risque de se retrouver dehors avec la clé à l'intérieur ? |
|||
Effectivement, c'est un risque. |
|||
|
|||
Dans cet article, je présente une méthode pour mettre à jour la configuration de l'*Identity Provider* OpenShift quand on n'a ni le mot de passe **kubeadmin**, ni le fichier **kube.config** généré à l'installation. |
|||
|
|||
<!--more--> |
|||
|
|||
Mettre à jour la configuration de l'*Identity Provider* OpenShift, c'est prendre le risque de se retrouver dehors avec la clé à l'intérieur. |
|||
Pour éviter cela, j'essaie d'avoir toujours une solution "ceinture, bretelles et parachute". |
|||
|
|||
La ceinture, c'est le contrôle de surface appliqué par l'opérateur **authentication** d'OpenShift : si je me trompe dans le nom d'un champ ou sa syntaxe, une erreur est levée et la configuration n'est pas appliquée. |
|||
|
|||
Les bretelles, c'est la session CLI ou Console avec les privilèges **cluster-admin**, que je garde bien précieusement à portée de main. |
|||
|
|||
Et si tout ça échoue, il me faut le parachute ! |
|||
Mon parachute, dans cet article, c'est le *Service Account* ayant des droits **cluster-admin**. |
|||
|
|||
Je commence donc par créer un projet temporaire. |
|||
|
|||
``` |
|||
$ oc new-project tmp-auth |
|||
|
|||
Now using project "tmp-auth" on server "https://api.workshop-opp.sandbox2156.opentlc.com:6443". |
|||
|
|||
You can add applications to this project with the 'new-app' command. For example, try: |
|||
|
|||
oc new-app rails-postgresql-example |
|||
|
|||
to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application: |
|||
|
|||
kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.43 -- /agnhost serve-hostname |
|||
|
|||
``` |
|||
|
|||
Je crée ensuite un objet *Service Account*. |
|||
|
|||
``` |
|||
$ oc create serviceaccount backdoor |
|||
serviceaccount/backdoor created |
|||
``` |
|||
|
|||
Je donne les droits **cluster-admin** à ce *Service Account*. |
|||
|
|||
``` |
|||
$ oc adm policy add-cluster-role-to-user cluster-admin -z backdoor -n tmp-auth |
|||
clusterrole.rbac.authorization.k8s.io/cluster-admin added: "backdoor" |
|||
``` |
|||
|
|||
Je récupère le jeton d'authentification du *Service Account*. |
|||
|
|||
``` |
|||
$ oc get secrets -o name | sed -r 's|^(secret/backdoor-token-.*)$|\1|;t;d' |
|||
secret/backdoor-token-dx5lv |
|||
|
|||
$ SECRET_NAME=$(oc get secrets -o name | sed -r 's|^(secret/backdoor-token-.*)$|\1|;t;d') |
|||
|
|||
$ mkdir /tmp/backdoor |
|||
$ oc extract $SECRET_NAME --to=/tmp/backdoor |
|||
/tmp/backdoor/ca.crt |
|||
/tmp/backdoor/namespace |
|||
/tmp/backdoor/service-ca.crt |
|||
/tmp/backdoor/token |
|||
``` |
|||
|
|||
Et enfin, je récupère une session CLI en utilisant ce jeton. |
|||
|
|||
``` |
|||
$ oc login --token $(cat /tmp/backdoor/token) |
|||
|
|||
Logged into "https://api.workshop-opp.sandbox2156.opentlc.com:6443" as "system:serviceaccount:tmp-auth:backdoor" using the token provided. |
|||
|
|||
You have access to 127 projects, the list has been suppressed. You can list all projects with 'oc projects' |
|||
|
|||
Using project "tmp-auth". |
|||
|
|||
$ oc whoami |
|||
system:serviceaccount:tmp-auth:backdoor |
|||
``` |
|||
|
|||
Et comme l'authentification des *Service Accounts* ne dépend pas de la configuration de l'*Identity Provider* OpenShift, si quelque chose se passe mal, je peux toujours reprendre la configuration manuellement. |
|||
|
|||
Évidemment, une fois la configuration validée, je peux supprimer mon *Service Account*, mon projet et enlever les droits **cluster-admin**. |
|||
|
|||
``` |
|||
$ oc adm policy remove-cluster-role-from-user cluster-admin -z backdoor -n tmp-auth |
|||
$ oc delete project tmp-auth |
|||
``` |
|||
|
|||
Est-il nécessaire de le faire à chaque modification de la configuration ? Non. |
|||
Mais quand le changement est important et qu'on n'a pas la possibilité de tester sa modification avant, c'est plus rassurant ! |
|||
Loading…
Reference in new issue