Compte de service OpenShift 4 : gérer son cluster

10 novembre 2024

Imaginez-vous, développeur, en train d’administrer un cluster OpenShift ou OKD 4 utilisé principalement pour des tests de performance ou de validation. Votre rôle principal reste le développement de nouvelles fonctionnalités et la correction d’anomalies, et la gestion complète du cluster pourrait prendre plus de temps que vous ne pouvez en consacrer.

J’ai rencontré cette même situation lorsque notre équipe a obtenu un contrat de maintenance pour une application microservice hébergée sur un cluster OpenShift 4. En tant que responsable technique, j’ai dû mettre en place et administrer la plateforme pour que l’équipe puisse y travailler efficacement. C’est là que j’ai découvert l’importance d’un compte de service pour administrer un cluster OpenShift 4 et automatiser les tâches récurrentes d’administration.

Dans cet article, je partagerai avec vous les étapes essentielles pour gérer un cluster OpenShift 4 avec un compte de service, en m’appuyant sur mon expérience et en vous guidant pour rendre la gestion de votre cluster plus simple et plus efficace.

Quelle est la stratégie d’administration du cluster OpenShift ?

Une plateforme dédiée aux tests

Comme mentionné précédemment, notre cluster OpenShift est principalement utilisé par les développeurs pour valider les livrables avant la livraison au client. Les tests réalisés tout au long du cycle de développement sont variés :

Tests de déploiement
Tests d’intégration
Tests de performance
Tests de non-régression
Tests de montée de version du cluster
etc.

Avec la maturité de l’application, bien que le rythme de développement soit encore soutenu, la fréquence des tests diminue par rapport aux premières phases du projet. Par exemple, une fois que les ressources Kubernetes sont définies, les tests de déploiement deviennent plus rares.

Optimisation des coûts : un défi pour une plateforme de tests

Le budget du client pour cette plateforme peut être limité, voire être revu à la baisse, rendant une disponibilité continue (24h/24 et 7j/7) peu viable. Deux options s’offrent à nous pour continuer à réaliser les tests :

Installer et désinstaller le cluster à chaque session de tests, ce qui est chronophage et qui nécessite une intervention humaine.
Démarrer et arrêter le cluster tout en maintenant les ressources de stockage (ESXi, Cloud, etc.) pour réduire les coûts humains tout en préservant la configuration de base.

Adapter l’administration : une solution sur mesure pour OpenShift

Notre plateforme OpenShift est hébergée chez un fournisseur cloud, générant des coûts liés à la consommation de CPU et de RAM lorsque la plateforme est active, ainsi qu’au stockage tant que les disques sont alloués aux machines virtuelles.

Un cluster majoritairement utilisé pour des tests de performance

Actuellement, notre cluster OpenShift 4 est principalement dédié aux tests de performance et de validation. La fréquence élevée de ces tests rend l’installation et la désinstallation du cluster plus coûteuses que de maintenir un stockage constant. En effet, certaines actions manuelles requièrent des ressources humaines, ce qui engendre des frais supplémentaires. Dans notre cas, arrêter et relancer la plateforme est la solution la plus économique et pratique.

Anticiper les futurs besoins de compatibilité

Nous devons également vérifier la compatibilité de notre application avec les versions futures d’OpenShift. Cela implique, quelques fois par an, la réinstallation complète du cluster et la reconfiguration des namespaces.

Automatisation des tâches répétitives

Pour alléger cette gestion, nous pouvons automatiser plusieurs tâches récurrentes, dont :

La configuration des namespaces du cluster
La consultation des dates d’expiration des certificats (certificat de l’autorité de certification ou ceux des nœuds)
L’arrêt du cluster dans les règles de l’art

Créer et configurer le compte de service d’administration

Étape 1 : Création du compte de service d’administration

La première étape pour automatiser la gestion de votre cluster consiste à créer un compte de service dédié à l’administration. Ce compte de service, nommé ici admin-sa, sera configuré avec les droits nécessaires pour exécuter des opérations d’administration.

Pour créer ce compte de service, exécutez les commandes suivantes dans votre terminal :

$ oc create serviceaccount admin-sa # <1>
$ oc adm policy add-cluster-role-to-user cluster-admin -z admin-sa # <2>

Pour déclarer le compte sur un namespace spécifique, utiliser l’option -n.

L’option -z est nécessaire pour un compte de service.

Une fois ces étapes effectuées, le compte de service admin-sa est prêt et dispose des autorisations nécessaires pour administrer les nœuds et ressources de votre cluster OpenShift.

Étape 2 : Obtenir le token d’authentification

Plutôt qu’utiliser un token temporaire d’un compte utilisateur administrateur, nous allons utiliser le token permanent du compte de service. Ce token permet de s’authentifier sur le cluster OpenShift en tant qu’utilisateur admin-sa, avec les mêmes droits d’administration qu’un compte administrateur classique.

Pour récupérer le token d’authentification du compte de service admin-sa, exécutez les commandes suivantes :

$ oc describe sa admin-sa
Name:                admin-sa
Namespace:           your-namespace
Labels:              <none>
Annotations:         <none>
Image pull secrets:  pull-secret-name
Mountable secrets:   mount-secret-name
Tokens:              admin-sa-token-name # <1>
Events:              <none>
$ oc describe secret admin-sa-token-name
Name:         admin-sa-token-name
Namespace:    your-namespace
Labels:       <none>
Annotations:  kubernetes.io/created-by: openshift.io/create-dockercfg-secrets
              kubernetes.io/service-account.name: admin-sa
              kubernetes.io/service-account.uid: 80652074-043d-42bb-86c7-9497d86992bd

Type:  kubernetes.io/service-account-token

Data
====
namespace:       7 bytes
service-ca.crt:  8516 bytes
token:           eyJpc3Mi... # <2>
ca.crt:          7303 bytes

La valeur affichée est le nom du secret contenant le token.

La valeur retournée par la commande est un JWT utilisable avec la commande oc login --token

Automatiser l’arrêt du cluster OpenShift

Automatiser les tâches d’administration dans un script Shell

Pour automatiser l’arrêt d’un cluster OpenShift, nous allons utiliser un script Shell. Ce script suit les étapes décrites dans la documentation OpenShift 4.12 (Shutting down the cluster gracefully) pour effectuer un arrêt propre du cluster tout en récupérant la date d’expiration des certificats.

#!/bin/bash


# Arrêt à la première commande en échec
set -e


# Définition des variables
token="..." # <1>
server_url="https://api...:6443" # <1>


# Authentification sur l'API OpenShift/OKD 4 avec le token
echo "Authentification sur le cluster" >&2
oc login "--token=${token}" \
  "--server=${server_url}" >/dev/null # <2>


echo "Récupération de la date d'expiration des certificats" >&2
# Extraction de la date d'expiration de l'autorité de certification
ca_certificate_expiration_date=$(
  oc -n openshift-kube-apiserver-operator get secret kube-apiserver-to-kubelet-signer \
    -o jsonpath='{.metadata.annotations.auth\.openshift\.io/certificate-not-after}{"\n"}'
)
echo -e "Expiration du certificat CA : $(date -d"$ca_certificate_expiration_date")\n" >&2

# Extraction des dates d'expiration des certificats clients et serveurs
for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do
  # Certificat client
  client_expiration_date=$(
    oc debug node/${node} \
      -- chroot /host openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate 2>/dev/null \
      | grep "notAfter=" \
      | sed -re "s/^notAfter=(.*)$/\1/g"
  )
  # Certificat serveur
  server_expiration_date=$(
    oc debug node/${node} \
      -- chroot /host openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -noout -enddate 2>/dev/null \
      | grep "notAfter=" \
      | sed -re "s/^notAfter=(.*)$/\1/g"
  )

  echo "${node} :
- Expiration du certificat client : $(date -d"$client_expiration_date")
- Expiration du certificat serveur : $(date -d"$server_expiration_date")
" >&2
done


# Arrêt du cluster
echo "Arrêt des noeuds du cluster" >&2
for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do
  echo "  $node" >&2
  oc debug node/${node} -- chroot /host shutdown -h 1 >/dev/null 2>&1;
done

Modifier les variables avec vos propres valeurs ou utiliser des variables d’environnement.

Si le cluster utilise un certificat auto signé, vous pouvez ajouter l’option --insecure-skip-tls-verify=true.

Arrêt du cluster OpenShift grâce au script Shell

Lorsque nous exécutons le script précédent, le cluster s’arrête proprement et nous obtenons les messages suivants dans le terminal :

$ ./gracefull-shutdown.bash
Authentification sur le cluster
Récupération de la date d'expiration des certificats
Expiration du certificat CA : Thu Sep 11 07:41:26 UTC 2025
...-master-0... :
- Expiration du certificat client : Sat Oct 12 02:56:35 UTC 2024
- Server certificate expires: Sat Oct 12 02:56:35 UTC 2024
...-master-1... :
- Expiration du certificat client : Sat Oct 12 02:56:35 UTC 2024
- Expiration du certificat serveur : Sat Oct 12 02:56:35 UTC 2024
...
Arrêt des noeuds du cluster

Ce script permet un arrêt dans les règles de l’art de chaque nœud du cluster, assurant ainsi le suivi des certificats essentiel pour éviter les interruptions de service.

Sécuriser le cluster : les bonnes pratiques

La gestion des droits dans un cluster OpenShift est cruciale pour maintenir une infrastructure sécurisée. Une bonne pratique en sécurité consiste à appliquer le principe du moindre privilège. Nous n’accordons que les droits strictement nécessaires à chaque compte pour accomplir les tâches requises :

Compte de service pour projet spécifique : Par exemple, pour un compte de service dédié à un projet, vous pouvez limiter les droits aux opérations nécessaires comme la gestion des Deployments, des ConfigMaps, etc. Les ressources sensibles, comme les Secrets et les Volumes Physiques, pourront être réservées aux administrateurs.
Compte de service pour l’administration : Pour les tâches d’administration automatisées, il est préférable de limiter les droits en fonction des actions requises par le script. Parfois, cela peut nécessiter la création de plusieurs comptes de service, chacun configuré pour une tâche précise.

Dans mon cas, les mesures de sécurité mises en place autour de notre cluster permettent d’accorder le rôle de cluster-admin au compte de service d’administration. Toutefois, selon les spécificités de votre plateforme et vos exigences de sécurité, ce niveau de privilège pourrait être inapproprié.

Conclusion

Administrer un cluster OpenShift/OKD 4 avec un compte de service constitue une solution efficace pour automatiser les tâches récurrentes tout en assurant une gestion sécurisée de la plateforme. Cette approche permet non seulement de réduire les coûts opérationnels, mais aussi de libérer du temps pour se concentrer sur le développement et l’amélioration des applications.

En suivant les étapes décrites dans cet article, vous serez en mesure de configurer et de lancer l’automatisation de l’administration de votre cluster. Cela vous permettra de garantir la continuité de vos développements et de vos tests. Toutefois, n’oubliez pas que chaque infrastructure est unique : il est essentiel d’adapter votre stratégie et votre configuration en fonction de vos besoins spécifiques pour tirer pleinement parti de votre cluster tout en respectant vos exigences en matière de sécurité.

Laisser un commentaire Annuler la réponse

Vous devez vous connecter pour publier un commentaire.