Meilleures pratiques pour la gestion des secrets et des données sensibles dans les clusters Kubernetes

Les secrets Kubernetes sont pratiques, mais ils ne sont pas automatiquement sûrs simplement parce que l'objet s'appelle Secret. Si votre RBAC est trop large ou si etcd n'est pas chiffré, un jeton divulgué peut exposer des mots de passe de base de données, des clés API et des certificats privés dans tout votre cluster.

Utilisez les secrets Kubernetes comme une couche, puis ajoutez le chiffrement, le contrôle d'accès, des modèles d'injection plus sûrs et des magasins de secrets externes là où le risque le justifie.

Comprendre les secrets Kubernetes : le mécanisme par défaut

Kubernetes introduit l'objet Secret spécialement conçu pour contenir des informations sensibles. Bien qu'utile, il est crucial de comprendre ses limites et son comportement par défaut en matière de sécurité.

Comportement par défaut et mises en garde

Par défaut, les secrets Kubernetes ne sont pas chiffrés au repos dans etcd, le magasin de sauvegarde du cluster pour toutes les données de configuration. Ils sont simplement encodés en Base64, ce qui n'offre aucun chiffrement réel. Toute personne ayant accès au magasin de données etcd (par exemple, les administrateurs du cluster, les nœuds compromis) peut facilement décoder ces valeurs.

Avertissement : Ne vous fiez jamais uniquement à l'objet Secret Kubernetes par défaut pour des données hautement sensibles sans appliquer de mesures de chiffrement.

Encodage Base64 vs chiffrement

C'est une idée fausse courante que l'encodage Base64 offre une sécurité. Base64 est un schéma d'encodage, pas un schéma de chiffrement. Il est facilement réversible :

# Exemple de décodage d'une valeur de secret Kubernetes
echo 'c3VwZXItc2VjcmV0Cg==' | base64 -d
# Sortie : super-secret

Couche 1 : Sécuriser les secrets au repos (chiffrement etcd)

L'étape la plus fondamentale pour sécuriser les secrets est de s'assurer qu'ils sont chiffrés au niveau de la couche de stockage (etcd). Cela protège les données même si la base de données sous-jacente est accessible directement.

Activer le chiffrement au repos

Le chiffrement au repos est configuré via le serveur API Kubernetes à l'aide d'un objet EncryptionConfiguration. Cette configuration spécifie quels fournisseurs doivent être utilisés pour chiffrer différents types de données stockées dans etcd, y compris les secrets.

Composants clés de la configuration de chiffrement :

1. kind: EncryptionConfiguration : Déclare le type de ressource.
2. resources : Spécifie les ressources API qui doivent être chiffrées.
3. providers : Définit le mécanisme de chiffrement. Les fournisseurs courants incluent aescbc, aesgcm et les fournisseurs KMS (comme AWS KMS ou GCP KMS).

Meilleure pratique : Utilisez un fournisseur KMS lorsque votre plateforme le prend en charge. Si vous utilisez des clés locales, gérez soigneusement la rotation des clés et conservez les anciennes clés jusqu'à ce que les données existantes aient été réchiffrées.

Couche 2 : Sécuriser les secrets en transit et en cours d'utilisation

Bien que le chiffrement etcd résolve le problème 'au repos', les secrets sont toujours déchiffrés par le Kubelet lorsqu'ils sont montés dans un Pod. Nous devons contrôler comment et où ces secrets apparaissent.

Stratégie 1 : Montage de volume des secrets

La méthode standard pour injecter des données secrètes dans un conteneur consiste à les monter en tant que volume (ce qui donne souvent un fichier dans le système de fichiers du conteneur).

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/config/db"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: my-sensitive-secret

Considération de sécurité : Les volumes de secrets montés sont généralement sauvegardés par tmpfs sur les nœuds Linux, mais les valeurs sont toujours visibles par le processus du conteneur et par quiconque dispose d'un accès suffisant au nœud ou au Pod. Utilisez readOnly: true, évitez de vider l'environnement ou les fichiers de configuration dans les journaux, et restreignez l'accès shell aux Pods de production.

Stratégie 2 : Variables d'environnement (déconseillées pour une sensibilité élevée)

Bien que pratiques, l'utilisation de variables d'environnement provenant de secrets est généralement déconseillée pour les secrets de grande valeur. Les variables d'environnement peuvent facilement être divulguées via :

• Les journaux de conteneurs générés par des applications mal configurées.
• La lecture de /proc/1/environ depuis l'intérieur du conteneur ou d'autres conteneurs privilégiés.
• Les outils d'inspection de conteneurs.

Utilisez les variables d'environnement uniquement pour les données de configuration de faible sensibilité si vous devez les utiliser.

Couche 3 : Gestion avancée avec des magasins de secrets externes

Le modèle le plus sécurisé consiste à conserver les données sensibles entièrement en dehors du plan de contrôle Kubernetes (etcd) et à les récupérer dynamiquement au moment de l'exécution à l'aide d'outils spécialisés.

Utilisation des opérateurs de secrets externes

Les opérateurs de secrets externes comblent le fossé entre un secret stocké en toute sécurité dans un coffre dédié (comme HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) et l'objet Secret Kubernetes natif.

1. Stockage : Le secret réel vit uniquement dans le coffre externe.
2. Synchronisation/Injection : Un opérateur surveille une ressource personnalisée (comme ExternalSecret) et récupère les données du coffre.
3. Création : L'opérateur crée ensuite un objet Secret Kubernetes standard localement, qui peut ensuite être monté dans les Pods.

Avantage : La source de vérité reste en dehors du cluster, ce qui améliore la rotation et l'auditabilité. Cependant, le secret Kubernetes synchronisé existe toujours dans le cluster, vous avez donc toujours besoin de RBAC, de chiffrement etcd et d'isolation des espaces de noms.

Utilisation du pilote CSI Secrets Store

Pour les applications qui ont besoin d'un accès direct et éphémère sans stocker le secret localement dans etcd du tout, le pilote CSI Secrets Store est le choix supérieur.

• Le pilote exploite un fournisseur (par exemple, fournisseur Vault, fournisseur Azure).
• Il monte le secret directement depuis le magasin externe dans le système de fichiers du Pod en tant que volume temporaire, contournant ainsi la nécessité d'écrire les données secrètes dans etcd.

Cela offre le plus haut niveau de sécurité en éliminant complètement le secret de la base de données etcd.

Meilleures pratiques opérationnelles pour la gestion des secrets

Au-delà des mécanismes de stockage techniques, l'hygiène opérationnelle est cruciale pour maintenir une posture de sécurité.

1. Principe du moindre privilège (PoLP)

Assurez-vous que le compte de service associé à un Pod n'a que les autorisations pour lire le secret spécifique dont il a besoin, et aucun autre. Utilisez le contrôle d'accès basé sur les rôles (RBAC) pour limiter étroitement les autorisations.

2. Rotation fréquente des secrets

Mettez en œuvre des calendriers de rotation automatisés pour toutes les informations d'identification. Les secrets à longue durée de vie augmentent la fenêtre d'opportunité pour une compromission. Les outils intégrés aux coffres externes gèrent souvent cette rotation automatiquement.

3. Audit et surveillance des accès

Configurez la journalisation d'audit pour suivre qui lit ou modifie les objets Secret. Les outils qui s'intègrent aux coffres externes (comme les agents Vault ou les pilotes CSI) doivent également enregistrer les tentatives d'accès au magasin externe.

4. Ne jamais valider les secrets dans Git

C'est une règle fondamentale. Ne stockez jamais de secrets bruts ou même encodés en Base64 dans des dépôts Git, même privés. Utilisez des outils comme git-secrets ou des outils de templating de gestion de configuration (comme Helm ou Kustomize) combinés à des mécanismes d'injection de secrets externes pour gérer les manifestes de déploiement.

Exemple avec Kustomize (référence externe) :

Lors de l'utilisation de templating, vous pouvez utiliser des espaces réservés dans vos fichiers manifestes et vous appuyer sur une étape de construction ou un pipeline CI/CD pour injecter les valeurs secrètes réelles récupérées en toute sécurité depuis un coffre avant d'appliquer le YAML au cluster.

Comparaison des stratégies de gestion

Stratégie	Niveau de sécurité	Exposition etcd ?	Complexité	Meilleur pour
Secret K8s par défaut (pas de chiffrement etcd)	Très faible	Oui (texte clair)	Faible	Tests temporaires uniquement
Secret K8s avec chiffrement etcd	Moyen	Oui (chiffré)	Moyen	Données de configuration générales
Opérateur de secrets externes	Élevé	Oui (Secret géré par l'opérateur)	Élevé	Standardisation de la gestion des secrets
Pilote CSI Secrets Store	Le plus élevé	Non (montage direct)	Élevé	Informations d'identification et jetons hautement sensibles

Commencez par activer le chiffrement etcd et resserrer le RBAC. Ensuite, décidez si chaque charge de travail peut utiliser des secrets synchronisés, des montages CSI directs ou des informations d'identification dynamiques provenant d'un coffre externe. La meilleure configuration est celle qui limite qui peut lire le secret, où il est stocké et combien de temps il reste utile après une exposition.