Gardez vos secrets en sécurité dans Kubernetes

Mise à jour : 28/02/2025

Dans un cluster Kubernetes, certaines applications nécessitent des données sensibles comme des mots de passe, des clés API ou des certificats. Stocker ces informations dans un ConfigMap ou directement dans le code présente un risque de sécurité important.

Comment protéger les données sensibles ?

Les Secrets Kubernetes offrent une solution sécurisée pour gérer ces données en les stockant de manière encodée et en limitant leur accès aux seuls pods autorisés. Ils permettent ainsi de protéger les informations confidentielles tout en maintenant une séparation claire entre la configuration et les secrets.

Les secrets sont stockés dans le cluster Kubernetes et peuvent être utilisés par les applications pour accéder à des données sensibles. Ils sont encodés en base64 pour éviter les fuites d’informations.

Prérequis pour tester les exemples

Avant de manipuler les deployments Kubernetes, assurez-vous d’avoir un environnement prêt avec les outils nécessaires.

Un cluster Kubernetes fonctionnel

Pour déployer des applications, vous avez besoin d’un cluster Kubernetes opérationnel. Deux options s’offrent à vous :

Un cluster déjà existant (on-premise ou cloud : OKS, AKS, EKS, GKE, etc.).
Un cluster local avec Minikube 🖥️ (pratique pour les tests et l’apprentissage).

L’outil `kubectl` pour interagir avec le cluster

kubectl est l’outil en ligne de commande qui permet de gérer un cluster Kubernetes. Il est indispensable pour :

Déployer et administrer des applications.
Vérifier l’état des ressources Kubernetes.
Déboguer les déploiements.

Un éditeur de code adapté

Pour éditer vos fichiers YAML et configurer vos deployments, utilisez un IDE comme :

VS Code (avec l’extension Kubernetes pour une meilleure expérience).
Vim, Nano, ou tout autre éditeur de votre choix.

Avec ces outils en place, vous êtes prêt à tester les exemples contenus dans ce guide. 🚀

Création d’un Secret

Il existe plusieurs méthodes pour créer un Secret dans Kubernetes : via un fichier YAML, avec kubectl, ou à partir d’un manifest kubernetes contenant les données.

Créer un Secret avec `kubectl`

Il est aussi possible de créer un Secret directement en ligne de commande :

kubectl create secret generic db-secret \
  --from-literal=username=admin \
  --from-literal=password=mon-mot-de-passe

Les valeurs seront automatiquement encodées en base64.

Vérifiez son contenu en YAML :

kubectl get secret db-secret -o yaml

Créer un Secret à partir d’un fichier

Si vous avez un fichier contenant un mot de passe, vous pouvez créer un Secret à partir de celui-ci.

Exemple avec un fichier db-password.txt :

echo "mon-mot-de-passe" > db-password.txt
kubectl create secret generic db-secret --from-file=password=db-password.txt

Le Secret stockera le contenu du fichier sous la clé password.

Vérifiez son contenu :

kubectl get secret db-secret -o yaml

Créer un Secret avec un manifest YAML

Les valeurs d’un Secret doivent être encodées en base64 avant d’être ajoutées au fichier YAML.

Avant de définir un Secret en YAML, encodez vos valeurs sensibles en base64 :

echo -n "mon-mot-de-passe" | base64

bW9uLW1vdC1kZS1wYXNzZQ==

Définition du Secret en YAML :

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: dXNlcm5hbWU=   # "username" encodé en base64
  password: bW9uLW1vdC1kZS1wYXNzZQ==  # "mon-mot-de-passe" encodé en base64

type: Opaque → Type de Secret standard pour des données génériques.
data: → Contient les clés et valeurs encodées en base64.

Appliquer le Secret :

kubectl apply -f secret.yaml

Vérifiez qu’il a bien été créé :

kubectl get secrets

Affichez ses détails :

kubectl describe secret db-secret

Utilisation des Secrets

Une fois un Secret Kubernetes créé, il peut être injecté dans un pod de différentes manières :

En tant que variable d’environnement
En tant que fichier monté dans un volume

L’objectif est de sécuriser l’accès aux données sensibles sans les exposer directement dans le code ou les fichiers de configuration.

Injection des valeurs sous forme de variables d’environnement

L’une des méthodes les plus simples consiste à utiliser un Secret pour définir des variables d’environnement dans un pod.

Exemple d’un Deployment utilisant un Secret :

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

Explication :

secretKeyRef permet de récupérer les valeurs du Secret db-secret.
Ces valeurs sont injectées sous forme de variables d’environnement DB_USERNAME et DB_PASSWORD.

Vérifier que les valeurs sont bien injectées :

Lancez le Deployment :

kubectl apply -f app-deployment.yaml

Listez les pods créés :

kubectl get pods

Testez si les variables d’environnement sont bien accessibles dans un pod :

kubectl exec -it <nom-du-pod> -- env | grep DB_

Si tout fonctionne, vous devriez voir :

DB_USERNAME=admin
DB_PASSWORD=mon-mot-de-passe

Monter un Secret en tant que fichier dans un volume

Plutôt que d’utiliser des variables d’environnement, il est possible de monter un Secret sous forme de fichier. Cette approche est particulièrement utile pour les certificats, les clés SSH ou les fichiers de configuration sensibles.

Définition du Deployment avec un volume Secret :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: app-container
        image: nginx
        volumeMounts:
          - name: secret-volume
            mountPath: "/etc/secret"
            readOnly: true
      volumes:
        - name: secret-volume
          secret:
            secretName: db-secret

📌 Explication :

Le Secret db-secret est monté en tant que volume sous /etc/secret.
Chaque clé du Secret devient un fichier dans ce répertoire.
Le pod peut alors lire le fichier contenant les données sensibles sans les exposer sous forme de variables d’environnement.

Vérifier le contenu du Secret dans le pod :

Après avoir appliqué le Deployment :

kubectl apply -f app-deployment.yaml

Entrez dans un pod et affichez le contenu du volume monté :

kubectl exec -it <nom-du-pod> -- ls /etc/secret

Vous devriez voir les fichiers suivants :

username
password

Pour afficher la valeur d’un Secret :

kubectl exec -it <nom-du-pod> -- cat /etc/secret/username

Résultat attendu :

admin

Mettre à jour un Secret et son impact sur les pods

Par défaut, les pods ne sont pas automatiquement redémarrés après une mise à jour d’un Secret.

Si vous modifiez un Secret :

kubectl edit secret db-secret

Les pods existants ne prendront pas en compte ces changements. Pour forcer l’application de la nouvelle version, redémarrez les pods associés :

kubectl rollout restart deployment app-deployment

Bonnes pratiques de sécurité

Les Secrets Kubernetes permettent de stocker des informations sensibles, mais par défaut, ils sont encodés en base64, ce qui ne constitue pas un chiffrement. Il est donc essentiel de mettre en place des bonnes pratiques de sécurité pour éviter l’exposition accidentelle de données confidentielles.

Faire une rotation régulière des Secrets : Pour limiter les risques de fuites de données, il est recommandé de changer régulièrement les Secrets. Cette pratique est essentielle pour garantir la sécurité des données sensibles.
Ne pas stocker de Secrets en clair dans des fichiers YAML : Les fichiers YAML contenant des Secrets ne doivent pas être stockés dans un dépôt Git sans chiffrement. Utiliser Kubeseal pour chiffrer les Secrets dans vos manifests.
Limiter l’accès aux Secrets avec RBAC : Par défaut, tous les pods d’un namespace peuvent accéder aux Secrets s’ils ont les permissions nécessaires. Il est donc important de restreindre cet accès avec Role-Based Access Control (RBAC).
Activer le chiffrement des Secrets dans etcd : Par défaut, Kubernetes stocke les Secrets en clair dans etcd, sa base de données interne. Il est donc recommandé d’activer le chiffrement des Secrets au repos.
Utiliser des solutions de gestion externe des Secrets : Dans un environnement de production, il est préférable d’utiliser une solution externe pour gérer les Secrets plutôt que Kubernetes natif. Solutions tierces comme HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault offrent des fonctionnalités avancées pour la gestion des Secrets. Toutes ces solutions seront détaillées dans des guides dédiés!

Conclusion

Les Secrets Kubernetes permettent de sécuriser les informations sensibles, mais leur gestion doit être rigoureuse pour éviter les fuites et les mauvaises configurations. En appliquant les bonnes pratiques comme la restriction des accès avec RBAC, le chiffrement des Secrets dans etcd, ou encore l’utilisation d’une solution de gestion externe, vous renforcez la sécurité de vos applications Kubernetes.

Pour aller plus loin et améliorer la gestion des Secrets dans un environnement sécurisé :

Découvrez notre guide dédié au RBAC Kubernetes pour mieux contrôler l’accès aux ressources sensibles.
Apprenez à intégrer HashiCorp Vault pour une gestion avancée des Secrets et du chiffrement.

Une gestion efficace des Secrets est essentielle pour garantir la sécurité et la conformité de votre infrastructure Kubernetes.