Commandes de base des Secrets Kubernetes avec exemples pratiques

Introduction

Les Secrets dans Kubernetes sont des objets qui stockent des informations sensibles telles que des mots de passe, des jetons OAuth et des clés SSH. Utiliser des Secrets plutôt que du texte en clair dans les spécifications des Pods ou les images de conteneurs réduit le risque d'exposition accidentelle et facilite la rotation des identifiants. Cependant, de nombreux ingénieurs ne mémorisent que quelques commandes kubectl et ne pratiquent pas les étapes d'observation, de vérification et de récupération qui transforment ces commandes en opérations fiables.

Cet article couvre les commandes kubectl essentielles pour créer, inspecter, monter et dépanner les Secrets. Il est destiné aux développeurs, consultants DevOps et équipes de startup qui ont besoin d'exemples pratiques avec des sorties attendues claires et des signaux d'échec. Chaque section comprend des commandes, des exemples de sortie et ce qu'il faut vérifier lorsque quelque chose ne se comporte pas comme prévu. L'objectif est la sécurité opérationnelle : observer avant de changer, limiter le rayon d'impact, utiliser des espaces réservés au lieu de vrais secrets et vérifier chaque modification.

Vous avez besoin d'un cluster Kubernetes fonctionnel et de kubectl configuré pour suivre. Les exemples supposent un espace de noms nommé demo ; créez-le avec kubectl create namespace demo s'il n'existe pas. Certaines commandes utilisent base64 pour l'encodage, disponible sur macOS, Linux et Windows Subsystem for Linux.

Inventaire de la version et de l'environnement

Avant d'exécuter toute commande liée aux Secrets, confirmez la version de votre cluster et la disponibilité de l'API. Les versions Kubernetes 1.19 et ultérieures incluent l'API stable v1 pour les Secrets, mais les clusters plus anciens peuvent nécessiter v1beta1. La commande kubectl version affiche les versions du client et du serveur :

kubectl version --short

Exemple de sortie :

Client Version: v1.28.2
Server Version: v1.27.3

Si la version du serveur est antérieure à 1.19, mettez à niveau ou utilisez la version d'API appropriée dans vos manifestes. Vérifiez que vous pouvez lire les Secrets dans l'espace de noms cible avec une commande non destructive :

kubectl auth can-i list secrets --namespace demo

Sortie attendue lorsque la permission existe :

yes

Si elle renvoie no, demandez à votre administrateur de cluster d'accorder un accès en lecture via un Role ou un ClusterRole. Vérifiez également que le jeton du ServiceAccount par défaut n'est pas utilisé pour l'accès aux secrets si vous avez désactivé le montage automatique :

kubectl get serviceaccount default -o yaml --namespace demo | grep automountServiceAccountToken

Si rien n'est renvoyé, le montage automatique est activé par défaut et peut être une considération de sécurité. Un inventaire d'environnement en lecture seule garantit que vous ne tentez pas de modifications que votre rôle ne peut pas prendre en charge.

Création de Secrets

Kubernetes prend en charge plusieurs façons de créer des Secrets : à partir de valeurs littérales, de fichiers et d'un manifeste YAML. La commande kubectl create secret generic est rapide pour les cas simples, mais elle écrit la valeur du secret dans votre historique de shell. Utilisez-la uniquement pour le développement ; en production, préférez les manifestes déclaratifs appliqués via CI/CD où la source du manifeste est protégée.

À partir de valeurs littérales

Créez un Secret avec des littéraux de nom d'utilisateur et de mot de passe :

kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password='S3cret!' \
  --namespace demo

Sortie attendue :

secret/db-credentials created

Vérifiez que le Secret a été créé :

kubectl get secret db-credentials --namespace demo

Sortie :

NAME             TYPE     DATA   AGE
db-credentials   Opaque   2      10s

À partir de fichiers

Si vous disposez déjà de fichiers d'identifiants, créez un Secret à partir d'eux :

echo -n 'admin' > username.txt
echo -n 'S3cret!' > password.txt
kubectl create secret generic db-credentials-file \
  --from-file=./username.txt \
  --from-file=./password.txt \
  --namespace demo

Les clés seront les noms de fichiers (username.txt, password.txt). Pour spécifier des clés personnalisées, utilisez --from-file=username=./username.txt --from-file=password=./password.txt.

Inspectez les clés de données résultantes :

kubectl get secret db-credentials-file -o jsonpath='{.data}' --namespace demo

Sortie (encodée en base64) :

{"password.txt":"UzNjcmV0IQ==","username.txt":"YWRtaW4="}

À partir d'un manifeste

Pour la production, écrivez un fichier YAML avec des valeurs encodées en base64 :

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials-manifest
  namespace: demo
type: Opaque
data:
  username: YWRtaW4=  # admin
  password: UzNjcmV0IQ==  # S3cret!

Appliquez-le :

kubectl apply -f db-secret.yaml

Sortie attendue :

secret/db-credentials-manifest created

Si le Secret existe déjà, apply le met à jour (sous réserve de validation). Vous pouvez générer les valeurs base64 avec :

echo -n 'admin' | base64
# YWRtaW4=
echo -n 'S3cret!' | base64
# UzNjcmV0IQ==

Ne commitez jamais de fichiers manifestes bruts avec de vraies valeurs base64 dans un dépôt public ; utilisez des secrets scellés ou un gestionnaire de secrets externe pour le chiffrement.

Lecture et décodage des Secrets

Pour voir ce qu'il y a à l'intérieur d'un Secret sans décoder manuellement, utilisez kubectl get secret -o yaml puis décodez les valeurs base64 :

kubectl get secret db-credentials-manifest -o yaml --namespace demo

Extrait de sortie :

data:
  password: UzNjcmV0IQ==
  username: YWRtaW4=
kind: Secret
metadata:
  ...

Décodez une valeur :

echo 'UzNjcmV0IQ==' | base64 --decode
# S3cret!

Pour une extraction rapide d'une seule valeur :

kubectl get secret db-credentials-manifest \
  -o jsonpath='{.data.password}' --namespace demo | base64 --decode

Attention : Le décodage des secrets sur votre poste de travail les expose dans la sortie du terminal. Limitez cela au dépannage et évitez de les rediriger vers des journaux ou des écrans partagés.

Montage des Secrets en tant que variables d'environnement

Un Pod peut consommer des Secrets sous forme de variables d'environnement. C'est courant pour la configuration d'applications. Créez un manifeste de Pod :

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
  namespace: demo
spec:
  containers:
  - name: app
    image: busybox:1.28
    command: ["sleep", "3600"]
    env:
    - name: DB_USER
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: username
    - name: DB_PASS
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: password

Appliquez et vérifiez :

kubectl apply -f secret-env-pod.yaml
kubectl exec secret-env-pod --namespace demo -- printenv DB_USER

Sortie attendue :

admin

Si la variable d'environnement est absente, vérifiez les événements du Pod pour des références de Secret invalides :

kubectl describe pod secret-env-pod --namespace demo

Recherchez des événements comme Error: secret "db-credentials" not found.

Montage des Secrets en tant que volumes

Les fichiers offrent une manière dynamique de consommer des Secrets ; les modifications du Secret sont reflétées dans le volume monté (bien que l'application doive recharger le fichier). Exemple de Pod avec un montage de volume :

apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-pod
  namespace: demo
spec:
  containers:
  - name: app
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: credentials
      mountPath: /etc/credentials
      readOnly: true
  volumes:
  - name: credentials
    secret:
      secretName: db-credentials

Après application, vérifiez les fichiers :

kubectl exec secret-volume-pod --namespace demo -- ls /etc/credentials
# password  username
kubectl exec secret-volume-pod --namespace demo -- cat /etc/credentials/username
# admin

Si le montage échoue, le Pod ne démarrera pas. Vérifiez le statut du Pod et les événements :

kubectl get pod secret-volume-pod --namespace demo
kubectl describe pod secret-volume-pod --namespace demo

Les erreurs courantes incluent un Secret manquant, un mauvais chemin de montage ou des problèmes de permission en lecture seule.

Mise à jour des Secrets

Kubernetes ne fournit pas de commande de mise à jour sur place pour les données d'un Secret ; vous devez appliquer un nouveau manifeste ou utiliser kubectl edit. Lorsque vous mettez à jour un Secret, les montages en tant que volumes sont éventuellement mis à jour (par la synchronisation du kubelet), mais les variables d'environnement ne sont pas modifiées jusqu'au redémarrage du Pod. Pour mettre à jour un Secret à partir d'un manifeste après avoir modifié le fichier YAML :

kubectl apply -f db-secret.yaml

Pour mettre à jour une seule clé via la CLI, vous pouvez patcher avec une fusion JSON ou une fusion stratégique :

kubectl patch secret db-credentials -p '{"data":{"password":"bmV3cGFzcw=="}}' --namespace demo

Remplacez bmV3cGFzcw== par le base64 de votre nouveau mot de passe. Vérifiez la mise à jour :

kubectl get secret db-credentials -o jsonpath='{.data.password}' --namespace demo | base64 --decode

Nouveau mot de passe attendu. Si vous devez effectuer une rotation des identifiants, mettez à jour le Secret, puis redémarrez les Pods qui le consomment :

kubectl rollout restart deployment.apps/myapp --namespace demo

Pour les StatefulSets, une mise à jour progressive peut être effectuée en supprimant les Pods un par un.

Dépannage des Secrets

Les problèmes avec les Secrets se manifestent souvent par des erreurs d'application : échecs d'authentification, fichiers manquants ou boucles de crash. Commencez par le statut du Pod :

kubectl get pods --namespace demo

Si un Pod est en CrashLoopBackOff, inspectez les journaux :

kubectl logs secret-env-pod --namespace demo --previous

Si le journal indique une variable d'environnement manquante, vérifiez la spécification du Pod et l'existence du Secret :

kubectl get secret db-credentials -o yaml --namespace demo
kubectl describe pod secret-env-pod --namespace demo

Assurez-vous que le Secret est dans le même espace de noms que le Pod ; les Secrets sont des objets délimités par espace de noms. Vérifiez également le RBAC : le ServiceAccount utilisé par le Pod doit avoir la permission d'obtenir le Secret si le Secret n'est pas autorisé par défaut dans l'espace de noms. Par défaut, un Pod peut monter n'importe quel Secret dans son espace de noms si le ServiceAccount a la permission get, souvent accordée par le rôle view.

Modes de défaillance et récupération

Les modes de défaillance courants incluent :

1. Secret introuvable : L'événement du Pod montre MountVolume.SetUp failed for volume "credentials" : secret "db-credentials" not found. Confirmez que le Secret existe et est correctement orthographié. S'il a été supprimé accidentellement, recréez-le à partir d'une source fiable connue.
2. Données base64 invalides : Si les données du Secret ne peuvent pas être décodées par Kubernetes (par exemple, pas en base64), vous verrez une erreur lors de l'application : Invalid value: "...": must be base64. Ré-encodez la valeur avec base64 et ré-appliquez.
3. Permission refusée : Le Pod ne peut pas lire le fichier du Secret en raison des paramètres runAsUser, fsGroup ou readOnly. Vérifiez le contexte de sécurité du Pod et les options de montage du volume.
4. Variables d'environnement obsolètes : Après la mise à jour d'un Secret, les variables d'environnement restent anciennes jusqu'au redémarrage du Pod. Utilisez kubectl rollout restart ou supprimez le Pod pour forcer la recréation.
5. Secret trop volumineux : Un Secret Kubernetes a une limite de 1 Mo. Si vous la dépassez, la création du Secret échoue. Utilisez un secret plus petit ou divisez-le en plusieurs Secrets ; pour les gros blobs, envisagez un ConfigMap ou un stockage externe.

Pour la récupération, gardez toujours une sauvegarde des manifestes de Secrets dans un emplacement sécurisé (chiffré au repos). Si un Secret est corrompu, supprimez et recréez à partir de la sauvegarde :

kubectl delete secret db-credentials --namespace demo
kubectl apply -f db-secret-backup.yaml

Ensuite, redémarrez les Pods consommateurs.

Pièges courants

• Utiliser du texte en clair dans les manifestes : Ne stockez jamais de valeurs en texte clair dans stringData à long terme ; utilisez data avec base64 (bien que base64 soit un encodage, pas un chiffrement). Pour une vraie sécurité, intégrez un fournisseur KMS ou utilisez des Secrets scellés.
• Accès large via le ServiceAccount par défaut : Évitez de monter automatiquement le jeton du ServiceAccount par défaut ; définissez automountServiceAccountToken: false dans la spécification du Pod si l'application n'a pas besoin d'accès à l'API.
• Oublier de faire une rotation des Secrets : Les Secrets sont statiques ; sans processus de rotation, les identifiants deviennent obsolètes. Définissez un rappel d'expiration ou utilisez un gestionnaire de secrets externe avec rotation automatique.
• Ne pas nettoyer les Secrets de test : Les Secrets inutilisés encombrent le cluster et peuvent exposer des données sensibles. Listez et supprimez régulièrement ceux qui ne sont pas utilisés :

kubectl get secrets --namespace demo
kubectl delete secret unwanted-secret --namespace demo

• Mélanger les espaces de noms : Un Secret référencé par un Pod dans un espace de noms différent échouera car les Secrets sont délimités par espace de noms. Si vous avez besoin d'un accès inter-espaces de noms, envisagez un magasin de secrets externe partagé ou copiez le Secret dans l'espace de noms cible.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant et après toute opération sur les Secrets :

Attribuez une personne responsable pour chaque étape et révisez la liste de contrôle mensuellement lors d'une réunion d'équipe. La colonne de fréquence reflète la fréquence à laquelle l'étape doit être validée.

Conclusion

Les Secrets Kubernetes exigent plus que quelques commandes ; ils demandent un flux de travail discipliné qui observe, vérifie et récupère. En suivant les exemples de cet article, vous pouvez créer, monter, mettre à jour et dépanner les Secrets en toute confiance. Rappelez-vous toujours de limiter l'accès, d'utiliser le moindre privilège et de traiter les Secrets comme des données sensibles même s'ils sont encodés en base64. Votre prochaine étape devrait être de pratiquer ces commandes dans un espace de noms non productif, puis d'intégrer la gestion des Secrets dans votre pipeline CI/CD avec des politiques de chiffrement et de rotation.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision.