Gestion sécurisée des Secrets (revisité, chiffrement etcd, solutions externes)

Revisiter les Secrets Kubernetes : enjeux et limitations

Nous avons déjà abordé les objets Secret dans Kubernetes (Chapitre 7) comme le mécanisme natif pour stocker et injecter des données sensibles (mots de passe, clés API, tokens, certificats TLS) dans les Pods, évitant ainsi de les coder en dur dans les images ou les manifestes. Cependant, une compréhension plus approfondie de leur fonctionnement et de leurs limitations en matière de sécurité est cruciale.

Par défaut, les données contenues dans les objets Secret sont stockées dans etcd (la base de données clé-valeur du control plane) simplement encodées en Base64. Le Base64 n'est pas une forme de chiffrement ; c'est un encodage trivialement réversible. Cela signifie que quiconque ayant accès à etcd (directement ou via une sauvegarde) peut facilement lire le contenu des Secrets en clair.

De plus, l'accès aux objets Secret via l'API Kubernetes est contrôlé par RBAC, mais une fois qu'un Secret est monté en volume dans un Pod ou exposé via une variable d'environnement, sa sécurité dépend de la sécurité du Pod lui-même. Bien que supérieurs au stockage en clair dans le code ou les images, les Secrets natifs de Kubernetes présentent donc des défis de sécurité qui nécessitent des mesures supplémentaires dans des environnements sensibles.

Chiffrement au repos dans etcd : une protection essentielle

Pour pallier le problème du stockage en clair (encodé en Base64) dans etcd, Kubernetes offre une fonctionnalité essentielle : le chiffrement au repos (Encryption at Rest) pour les ressources de l'API Server, et plus particulièrement pour les Secrets.

Lorsque cette fonctionnalité est activée, l'API Server chiffre les données des Secrets avant de les écrire dans etcd, en utilisant une clé de chiffrement. Lorsque les données sont lues depuis etcd, l'API Server les déchiffre de manière transparente avant de les retourner à l'appelant autorisé (via RBAC).

La configuration du chiffrement au repos se fait via la création d'une ressource EncryptionConfiguration (un fichier YAML) qui spécifie :

• Quelles ressources chiffrer (typiquement secrets, mais peut inclure d'autres ressources).
• Quels fournisseurs de chiffrement utiliser (providers). Kubernetes supporte plusieurs fournisseurs :
  • aescbc : Chiffrement symétrique AES-CBC (considéré moins sûr que GCM).
  • aesgcm : Chiffrement symétrique AES-GCM (recommandé).
  • kms : Utilise un Key Management Service externe (comme AWS KMS, GCP KMS, Azure Key Vault, ou HashiCorp Vault) pour gérer la clé de chiffrement des données (DEK - Data Encryption Key). C'est souvent la méthode la plus sécurisée et la plus gérable en production, car la clé maître (KEK - Key Encryption Key) reste en dehors du cluster Kubernetes.
  • identity : Ne chiffre pas (stockage en clair/Base64). Doit toujours être présent en dernier recours si les autres échouent.
  • secretbox : Autre méthode symétrique.
• Les secrets (clés) utilisés par les fournisseurs locaux (aescbc, aesgcm, secretbox), ou les détails de connexion pour le fournisseur kms.

Ce fichier de configuration EncryptionConfiguration est ensuite référencé via un flag (--encryption-provider-config) lors du démarrage de l'API Server. Il est absolument crucial de gérer la clé de chiffrement (ou l'accès au KMS) de manière sécurisée et de mettre en place des procédures de rotation des clés.

Activer le chiffrement au repos pour les Secrets est une étape fondamentale pour protéger les données sensibles contre un accès non autorisé à la base de données etcd.

Bonnes pratiques pour l'utilisation des Secrets natifs

Même avec le chiffrement etcd activé, plusieurs bonnes pratiques s'appliquent à l'utilisation des Secrets Kubernetes :

• Limiter l'accès via RBAC : Appliquez le principe de moindre privilège. N'accordez les permissions get, list, watch sur les Secrets qu'aux ServiceAccounts et utilisateurs qui en ont absolument besoin. Evitez d'accorder les droits create, update, delete sauf aux systèmes de gestion de secrets ou aux administrateurs dédiés.
• Préférer le montage en volume : Lorsque vous injectez un Secret dans un Pod, préférez le montage en tant que volume (ex: via volumeMounts et volumes.secret) plutôt que l'injection via des variables d'environnement. Les variables d'environnement peuvent être plus facilement exposées (via des logs, des erreurs, ou l'inspection du processus). Les volumes peuvent être montés avec des permissions spécifiques et certains types de volumes (comme ceux utilisant le pilote CSI Secrets Store) peuvent même monter les secrets directement depuis des gestionnaires externes sans les stocker dans l'API K8s.
• Utiliser des volumes projetés : Pour monter plusieurs sources (Secrets, ConfigMaps, Downward API) dans un même répertoire, utilisez les volumes projetés (volumes.projected).
• Ne pas stocker de secrets dans Git (même encodés) : Evitez de commiter les manifestes de Secrets (même encodés en Base64) directement dans vos dépôts Git. Utilisez des solutions comme Sealed Secrets, SOPS (Secrets OPerationS), ou des références à des gestionnaires de secrets externes.
• Rotation des secrets : Mettez en place des procédures pour renouveler régulièrement les identifiants et les clés stockés dans les Secrets.

Au-delà des Secrets natifs : Solutions externes et intégrations

Pour des besoins de sécurité plus avancés, de nombreuses organisations se tournent vers des gestionnaires de secrets externes dédiés. Ces systèmes offrent des fonctionnalités plus riches que les Secrets Kubernetes natifs, telles que :

• Gestion centralisée des secrets pour plusieurs environnements et applications.
• Audit détaillé des accès aux secrets.
• Politiques de sécurité fines (contrôle d'accès, TTL - Time To Live).
• Gestion dynamique des secrets (génération à la volée d'identifiants pour bases de données, etc.).
• Chiffrement renforcé et gestion sécurisée des clés (souvent avec support HSM - Hardware Security Module).
• Rotation automatique des secrets.

Les solutions populaires incluent :

• HashiCorp Vault : Une solution open-source et commerciale très répandue, offrant un large éventail de fonctionnalités.
• Gestionnaires de secrets Cloud : AWS Secrets Manager, Google Secret Manager, Azure Key Vault.
• Autres : CyberArk Conjur, Akeyless, etc.

L'intégration de ces gestionnaires externes avec Kubernetes se fait généralement via plusieurs méthodes :

• Agent Injecteur / Sidecar : Un conteneur 'sidecar' (comme le Vault Agent Injector) est ajouté au Pod. Il s'authentifie auprès du gestionnaire externe (souvent via un ServiceAccount Kubernetes et une méthode d'authentification spécifique comme Kubernetes Auth Method pour Vault), récupère les secrets nécessaires, et les rend disponibles pour le conteneur applicatif principal (souvent via un volume mémoire partagé).
• Pilote CSI (Container Storage Interface) Secrets Store : Un pilote CSI spécifique (comme le Secrets Store CSI Driver) est installé dans le cluster. Il permet de monter les secrets provenant de gestionnaires externes directement en tant que volumes dans les Pods, sans que les secrets ne transitent par l'API Server Kubernetes ou etcd. C'est souvent considéré comme l'approche la plus sécurisée et la plus découplée.
• Opérateurs Kubernetes : Certains gestionnaires fournissent des opérateurs Kubernetes qui peuvent synchroniser les secrets externes dans des objets Secret Kubernetes natifs (tout en bénéficiant des fonctionnalités de rotation et de gestion centralisée). Exemple : External Secrets Operator.

Le choix d'utiliser un gestionnaire de secrets externe dépend du niveau de sécurité requis, de la complexité de l'environnement et des fonctionnalités spécifiques nécessaires (audit, rotation dynamique...). Pour de nombreux cas d'usage, les Secrets Kubernetes natifs, combinés au chiffrement etcd et à des pratiques RBAC strictes, peuvent être suffisants, mais les solutions externes offrent une sécurité et une flexibilité accrues pour les environnements les plus exigeants.