From bb62e939c254546b0586e3ecd361acb427617519 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Nicolas=20Mass=C3=A9?= <nicolas.masse@itix.fr>
Date: Mon, 18 Dec 2023 21:31:43 +0100
Subject: [PATCH] new article

---
 .../blog/mettre-jour-idp-openshift-gitops.md  | 99 +++++++++++++++++++
 1 file changed, 99 insertions(+)
 create mode 100644 content/french/blog/mettre-jour-idp-openshift-gitops.md

diff --git a/content/french/blog/mettre-jour-idp-openshift-gitops.md b/content/french/blog/mettre-jour-idp-openshift-gitops.md
new file mode 100644
index 0000000..d83103e
--- /dev/null
+++ b/content/french/blog/mettre-jour-idp-openshift-gitops.md
@@ -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 !