Secrets Kubernetes : stocker les données sensibles

Un Secret Kubernetes permet de stocker des données sensibles comme des mots de passe, des clés API, des tokens ou des certificats. Il fournit un conteneur dédié pour ce type d’information, mais sa sécurité dépend surtout du RBAC, du chiffrement au repos et de la manière dont vous l’injectez dans vos Pods.

Ce guide montre comment créer un Secret, choisir son type, l’injecter dans un Pod et appliquer les bonnes pratiques de sécurité.

Prérequis : un cluster Kubernetes avec kubectl configuré.

Ce que vous allez apprendre

• Comprendre ce qu’un Secret protège (et ce qu’il ne protège pas)
• Créer des Secrets de différents types (Opaque, TLS, docker-registry)
• Injecter les Secrets dans vos Pods (env ou volume)
• Appliquer les bonnes pratiques de sécurité essentielles
• Décider quand passer à un gestionnaire de secrets externe

Ce qu’un Secret apporte de plus qu’un ConfigMap

Un Secret Kubernetes est pensé pour des données sensibles, mais il ne devient réellement sûr que si vous mettez en place les bonnes protections autour :

• Contrôle d’accès strict avec RBAC
• Chiffrement au repos dans etcd
• Limitation des accès API
• Montage en volume plutôt qu’en variables d’environnement lorsque c’est pertinent

Par défaut, un Secret reste lisible par toute identité autorisée à le récupérer via l’API Kubernetes.

Ce qu'un Secret ne fait PAS

Un Secret n’est pas chiffré par défaut. Il est encodé en base64, ce qui n’est pas une protection. Sans configuration supplémentaire, toute personne ayant accès à l’API Kubernetes peut lire vos secrets.

Permission de création de Pod = accès indirect aux Secrets

Dans un namespace, une identité autorisée à créer des Pods peut indirectement lire les Secrets de ce namespace en montant ces Secrets dans un Pod qu’elle contrôle. C’est aussi vrai via un Deployment.

Pourquoi base64 n’est pas du chiffrement

C’est le piège le plus courant. Beaucoup pensent que l’encodage base64 protège leurs données. C’est faux.

# Créer un Secret
kubectl create secret generic demo-secret --from-literal=password='S3cr3t!P@ss'

# Voir le Secret "protégé"
kubectl get secret demo-secret -o jsonpath='{.data.password}'

Sortie

UzNjcjN0IVBAc3M=

# Décoder en une commande
echo 'UzNjcjN0IVBAc3M=' | base64 -d

Sortie

S3cr3t!P@ss

Le décodage est instantané. Base64 sert uniquement à transporter des données binaires dans du YAML/JSON, pas à les protéger.

Conséquence

Quiconque peut exécuter kubectl get secret dans votre namespace peut lire tous vos mots de passe. Le RBAC est votre première ligne de défense.

Types de Secrets Kubernetes

Kubernetes propose plusieurs types de Secrets, chacun avec une structure adaptée :

Type	Usage	Clés créées
Opaque	Usage générique (mots de passe, tokens)	Libres
kubernetes.io/tls	Certificats TLS	tls.crt, tls.key
kubernetes.io/dockerconfigjson	Authentification registry	.dockerconfigjson
kubernetes.io/basic-auth	Authentification HTTP basique	username, password
kubernetes.io/ssh-auth	Clé SSH	ssh-privatekey

Glissez pour voir

Créer un Secret

Secret Opaque (usage courant)

La méthode la plus simple pour des identifiants :

kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password='S3cr3t!P@ss'

Vérifiez la création :

kubectl get secret db-credentials

Sortie

NAME             TYPE     DATA   AGE
db-credentials   Opaque   2      5s

Secret TLS

Pour stocker un certificat et sa clé privée :

kubectl create secret tls my-tls-secret \
  --cert=server.crt \
  --key=server.key

kubectl get secret my-tls-secret

Sortie

NAME            TYPE                DATA   AGE
my-tls-secret   kubernetes.io/tls   2      5s

Secret docker-registry

Pour s’authentifier auprès d’un registre privé :

kubectl create secret docker-registry my-registry \
  --docker-server=registry.example.com \
  --docker-username=myuser \
  --docker-password=mypassword

Utilisez-le dans un Pod avec imagePullSecrets :

spec:
  imagePullSecrets:
  - name: my-registry
  containers:
  - name: app
    image: registry.example.com/myapp:latest

Secret depuis un fichier YAML

Pour un contrôle total et la gestion en GitOps :

secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=           # echo -n 'admin' | base64
  password: UzNjcjN0IVBAc3M=   # echo -n 'S3cr3t!P@ss' | base64

Ne commitez jamais ce fichier

Un fichier YAML avec des Secrets encodés en base64 ne doit jamais être commité dans Git. Utilisez Sealed Secrets ou un gestionnaire externe pour chiffrer vos Secrets avant de les versionner.

Vous pouvez aussi utiliser stringData pour éviter l’encodage manuel :

secret-stringdata.yaml

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  username: admin
  password: S3cr3t!P@ss

Kubernetes convertit automatiquement stringData en data encodé.

stringData ne protège pas le fichier YAML

stringData simplifie l’écriture des manifests, mais ne rend pas le fichier plus sûr : le secret reste présent en clair dans votre YAML avant application.

Injecter un Secret dans un Pod

Deux méthodes principales, chacune avec ses cas d’usage :

Méthode	Cas d’usage	Mise à jour auto
Variable d’environnement	Identifiants simples	Non
Volume	Certificats, fichiers de config	Oui (~60s)

Glissez pour voir

Méthode 1 : Variables d’environnement

deployment-secret-env.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: nginx
        env:
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: username
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: password

Vérifiez l’injection :

kubectl exec deploy/myapp -- env | grep DB_

Sortie

DB_USERNAME=admin
DB_PASSWORD=S3cr3t!P@ss

Les valeurs sont décodées automatiquement dans le conteneur.

Limitation

Les variables d’environnement ne sont jamais rafraîchies automatiquement. Si vous modifiez le Secret, vous devez redémarrer les Pods : kubectl rollout restart deployment myapp.

Méthode 2 : Monter comme volume

Recommandé pour les certificats et fichiers de configuration :

deployment-secret-volume.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: nginx
        volumeMounts:
        - name: secret-volume
          mountPath: /etc/secrets
          readOnly: true
      volumes:
      - name: secret-volume
        secret:
          secretName: db-credentials
          defaultMode: 0400

Vérifiez les fichiers montés :

kubectl exec deploy/myapp -- ls -la /etc/secrets

Sortie

lrwxrwxrwx 1 root root 15 password -> ..data/password
lrwxrwxrwx 1 root root 15 username -> ..data/username

Les liens symboliques permettent la mise à jour automatique (~60s de délai).

Monter une seule clé avec un nom personnalisé

volumes:
- name: secret-volume
  secret:
    secretName: db-credentials
    items:
    - key: password
      path: db-password

Le fichier /etc/secrets/db-password contient uniquement le mot de passe.

Sécurité : les pratiques essentielles

1. Restreindre l’accès avec RBAC

Par défaut, tout utilisateur avec get sur les Secrets peut les lire. Créez des Roles restrictifs :

role-secrets-readonly.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["db-credentials"]  # Limiter aux Secrets nécessaires
  verbs: ["get"]

Bonne pratique

Évitez de donner list sur les Secrets à large échelle. list permet de voir tous les noms de Secrets, ce qui peut révéler des informations sensibles.

2. Activer le chiffrement dans etcd

Par défaut, Kubernetes stocke les Secrets en clair dans etcd. Activez le chiffrement au repos :

encryption-config.yaml (sur le control plane)

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-32-byte-key>
  - identity: {}

Clusters managés

Sur les clusters managés, vérifiez explicitement la documentation de votre provider pour savoir si le chiffrement au repos des Secrets est activé et comment il est configuré.

3. Préférer le montage volume aux variables d’environnement

Aspect	Variable env	Volume
Visible dans docker inspect	Oui	Non
Visible dans /proc/<pid>/environ	Oui	Non
Mise à jour automatique	Non	Oui

Glissez pour voir

Le montage en volume est souvent préférable pour limiter certaines expositions accidentelles et bénéficier de mises à jour automatiques, mais il ne remplace ni un bon cloisonnement des accès ni un durcissement du runtime. Si le conteneur est compromis, les fichiers montés restent accessibles au processus.

4. Faire la rotation des Secrets

# Mettre à jour le Secret
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password='N0uv3@uP@ss!' \
  --dry-run=client -o yaml | kubectl apply -f -

# Redémarrer les Pods pour appliquer
kubectl rollout restart deployment myapp

Quand passer à un gestionnaire externe

Les Secrets Kubernetes natifs ont des limites :

Limite	Impact
Pas de rotation automatique	Vous devez mettre à jour manuellement
Pas d’audit détaillé	Qui a accédé à quel Secret ?
Chiffrement etcd à configurer	Pas activé par défaut
Secrets visibles en YAML	Risque de commit accidentel

Glissez pour voir

Utilisez un gestionnaire externe si vous avez besoin de :

• Rotation automatique des secrets
• Audit détaillé des accès
• Intégration avec des secrets existants (AWS, Azure, GCP)
• Secrets dynamiques (credentials de BDD à durée limitée)

Solutions recommandées :

• HashiCorp Vault avec External Secrets ou Vault Sidecar
• AWS Secrets Manager / Azure Key Vault / GCP Secret Manager
• Sealed Secrets pour chiffrer les Secrets dans Git

Debug : problèmes courants

1. Le Secret existe-t-il ?

   kubectl get secret db-credentials

   Si “NotFound”, créez-le d’abord.

2. La clé existe-t-elle dans le Secret ?

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

   Vérifiez l’orthographe exacte de la clé.

3. Le Pod référence-t-il le bon Secret ?

   kubectl describe pod myapp-xxx | grep -A5 "Environment\|Mounts"

4. Erreur CreateContainerConfigError ?

   Secret ou clé introuvable. Vérifiez que le Secret existe dans le même namespace que le Pod.

Erreurs fréquentes

Erreur	Cause	Solution
CreateContainerConfigError	Secret ou clé introuvable	Vérifier nom et namespace
Variable vide	Clé mal orthographiée	kubectl get secret -o yaml
unauthorized	RBAC insuffisant	Vérifier les permissions

Glissez pour voir

À retenir

1. Un Secret stocke les données sensibles, mais base64 n’est pas du chiffrement
2. Les types de Secrets (Opaque, TLS, docker-registry) structurent vos données
3. Variables d’environnement : simples mais jamais rafraîchies automatiquement
4. Volumes : préférables pour la sécurité et la mise à jour automatique
5. RBAC est votre première ligne de défense — restreignez l’accès aux Secrets
6. Chiffrement etcd : activez-le pour protéger les Secrets au repos
7. Pour la rotation automatique ou l’audit, passez à un gestionnaire externe

Prochaines étapes

ConfigMaps Stocker la configuration non sensible

RBAC Kubernetes Contrôler l'accès aux ressources sensibles

Sealed Secrets Chiffrer vos Secrets pour les versionner dans Git

HashiCorp Vault Gestionnaire de secrets avancé avec rotation automatique

×

📖 Voir la documentation →