Introduction

La gestion sécurisée des secrets est cruciale pour le déploiement des applications dans Kubernetes, notamment pour protéger des informations sensibles telles que les mots de passe, les jetons d’API, et les clés privées. Bien que Kubernetes offre une gestion de base des secrets, plusieurs outils communautaires offrent des fonctionnalités avancées répondant aux exigences de sécurité plus strictes des environnements de production. Dans ce guide, nous explorerons trois solutions avancées : l’External Secrets Operator, le Secret Store CSI Driver et les Sealed Secrets. Chaque outil sera examiné sous les angles de son architecture, de son fonctionnement, des différences avec les autres outils, et de ses cas d’utilisation spécifiques.

I – External Secrets Operator

1.1 Architecture et Fonctionnement

L’External Secrets Operator (ESO) est conçu pour automatiser la gestion des secrets dans Kubernetes en les synchronisant depuis des sources de données externes, telles que AWS Secrets Manager, Azure Key Vault, ou GCP Secret Manager. Ce processus est principalement basé sur deux types d’objets Kubernetes : SecretStore (ou ClusterSecretStore) et ExternalSecret.

1. SecretStore et ClusterSecretStore : Ces objets définissent où et comment les données externes peuvent être accessibles. Un SecretStore est typiquement utilisé au niveau du namespace, tandis qu’un ClusterSecretStore s’applique à l’ensemble du cluster.
2. ExternalSecret : L’objet ExternalSecret déclenche l’opérateur pour qu’il récupère les données de secret externes et les transforme en un objet Secret natif de Kubernetes. Lorsque vous créez ou mettez à jour un ExternalSecret, l’ESO réagit immédiatement en récupérant les données spécifiées depuis le gestionnaire de secrets externe configuré.

Flux de Travail

• Étape 1 : Un administrateur configure un SecretStore ou ClusterSecretStore avec les détails de connexion nécessaires pour accéder au système de gestion des secrets externe.
• Étape 2 : Un développeur ou un administrateur définit un ExternalSecret qui spécifie quels secrets synchroniser. Cette définition inclut le lien vers le SecretStore ou ClusterSecretStore, ainsi que des détails sur le secret spécifique à récupérer (par exemple, son nom dans le gestionnaire de secrets externe).
• Étape 3 : L’External Secrets Operator détecte la création ou la modification de l’objet ExternalSecret et lance un processus pour récupérer le secret externe.
• Étape 4 : Le secret est récupéré et stocké dans Kubernetes sous forme d’un objet Secret dans le namespace spécifié, où il peut être utilisé par des applications de manière sécurisée.

1.2 Installation et Configuration de base

Pour mieux illustrer ce fonctionnement, je détaillerai l’installation de l’opérateur et la configuration de base du SecretStore ou ClusterSecretStore dans la prochaine itération, suivie par des exemples spécifiques de création et gestion des ExternalSecret.

Pour installer l’External Secrets Operator dans votre cluster Kubernetes, nous utiliserons Helm, qui est un outil de gestion de packages pour Kubernetes. Voici les étapes à suivre :

• Ajouter le dépôt Helm de l’External Secrets Operator:

helm repo add external-secrets https://external-secrets.github.io/external-secrets/
helm repo update

• Installer l’External Secrets Operator avec Helm:

helm install external-secrets external-secrets/external-secrets

Cette installation va déployer l’External Secrets Operator dans votre cluster, le rendant prêt à écouter les objets ExternalSecret et à interagir avec des systèmes externes pour la gestion des secrets.

Configuration du SecretStore

Avant de pouvoir utiliser l’External Secrets Operator pour synchroniser les secrets, vous devez configurer un SecretStore ou ClusterSecretStore. Nous allons configurer un ClusterSecretStore pour AWS Secrets Manager, ce qui permettra à l’opérateur de se connecter à AWS et de récupérer les secrets.

1. Création d’un secret Kubernetes pour les identifiants AWS: Il est nécessaire de stocker les identifiants AWS dans un secret Kubernetes, qui sera ensuite utilisé par le ClusterSecretStore pour authentifier les requêtes vers AWS Secrets Manager.

1. Note : Remplacez <base64-encoded-access-key-id> et <base64-encoded-secret-access-key> par vos clés AWS encodées en base64.
2. Définir un ClusterSecretStore pour AWS Secrets Manager: Ce ClusterSecretStore fait référence au secret créé précédemment pour l’authentification.

Création et Gestion des ExternalSecrets

Après avoir configuré le ClusterSecretStore, la prochaine étape consiste à définir des ExternalSecrets qui spécifient les secrets à synchroniser. Voici comment procéder :

1. Définir un ExternalSecret: Cet objet indique à l’External Secrets Operator quel secret externe récupérer et comment le stocker dans Kubernetes.

Dans cette configuration, l’ESO surveille l’objet ExternalSecret, récupère le secret correspondant depuis AWS Secrets Manager en utilisant les informations fournies, et crée un secret Kubernetes nommé my-k8s-secret dans le namespace default. Ce secret peut alors être utilisé par d’autres ressources dans le cluster.

1.3 Cas pratique d’un ExternalSecret

Les ExternalSecrets permettent de synchroniser les secrets de manière sécurisée et automatisée entre les systèmes de gestion des secrets externes et Kubernetes. Voyons comment cela fonctionne dans la pratique avec un cas d’usage courant.

Cas d’Usage : Synchronisation d’un Secret de Base de Données

Imaginons que vous ayez stocké les informations de connexion à une base de données dans AWS Secrets Manager. Vous souhaitez que ces informations soient accessibles par une application déployée dans Kubernetes. Voici les étapes pour configurer cela avec l’External Secrets Operator :

• Définition d’un ExternalSecret pour le secret de base de données : Cet ExternalSecret dira à l’opérateur de récupérer les informations de connexion depuis AWS Secrets Manager.

Dans cet exemple, my-database/credentials est le chemin du secret dans AWS Secrets Manager qui contient les informations username et password. Ces valeurs seront récupérées et stockées dans un secret Kubernetes nommé db-credentials-k8s.

• Utilisation du secret dans une application Kubernetes : Une fois que l’ExternalSecret est créé et que l’ESO a synchronisé les informations dans un secret Kubernetes, vous pouvez référencer ce secret dans vos déploiements Kubernetes pour utiliser ces informations de connexion.

Monitoring et Gestion des Événements

Lorsque vous créez ou modifiez un ExternalSecret, l’External Secrets Operator est immédiatement informé grâce aux mécanismes de surveillance des ressources de Kubernetes. L’opérateur réagit en vérifiant la configuration de l’ExternalSecret et en initiant la récupération des données du secret externe correspondant. Ce processus assure que les secrets dans Kubernetes sont toujours synchronisés et à jour avec les sources externes.

II- Secret Store CSI Driver

2.1 Architecture et Fonctionnement

Le Secret Store CSI Driver est une solution qui permet d’intégrer les gestionnaires de secrets externes avec Kubernetes en utilisant le standard Container Storage Interface (CSI). Ce driver sert de pont entre Kubernetes et les services de secrets externes tels qu’Azure Key Vault, AWS Secrets Manager, et Google Secret Manager. Il crée des volumes secrets que vos applications peuvent consommer, offrant ainsi un moyen sûr et flexible d’accéder aux secrets sans les exposer directement comme des objets Secret dans Kubernetes.

Flux de Travail

1. Installation du Driver : Le CSI Driver doit être installé sur le cluster Kubernetes. Ce driver s’occupera de la communication entre les services de gestion de secrets externes et les pods qui consomment ces secrets.
2. Configuration des Providers de Secrets : Chaque fournisseur de secrets nécessite une configuration spécifique pour permettre au CSI Driver de récupérer les secrets.
3. Définition de SecretProviderClass : Cet objet Kubernetes définit comment les secrets doivent être récupérés. Il spécifie le provider de secrets et les paramètres nécessaires pour l’acquisition des secrets.
4. Montage des Secrets comme Volumes dans les Pods : Les applications utilisent les secrets en montant des volumes dans leurs pods, où les données des secrets sont accessibles comme des fichiers.

2.2 Installation

L’installation du Secret Store CSI Driver se fait également via Helm. Voici les commandes de base pour installer ce driver dans votre cluster Kubernetes :

helm repo add secrets-store-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/secrets-store-csi-driver/master/charts
helm repo update
helm install csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver

Cette installation déploie le Secret Store CSI Driver sur votre cluster, le rendant prêt à intégrer des secrets externes dans vos applications.

Configuration pour AWS Secrets Manager

Pour configurer le Secret Store CSI Driver avec AWS Secrets Manager, vous devez définir un SecretProviderClass et un Secret qui spécifient comment les secrets doivent être récupérés.

• Stockage des clés d’accès AWS dans un Secret Kubernetes

Vous devez d’abord créer un secret Kubernetes qui contiendra vos clés d’accès AWS. Ce secret sera utilisé par le CSI Driver pour s’authentifier auprès d’AWS Secrets Manager.

• Configurer un SecretProviderClass pour AWS Secrets Manager: Ce document Kubernetes décrit comment le driver doit interagir avec AWS pour récupérer les secrets.

• Montage des secrets dans un pod

Les secrets sont montés dans un pod en référençant le SecretProviderClass configuré.

Dans cet exemple, les secrets de AWS Secrets Manager seront montés dans le chemin /mnt/secrets du pod. Chaque secret récupéré de AWS peut être exposé sous forme de fichier individuel dans ce répertoire monté.

2.3 Cas pratiques d’Utilisation et Gestion Avancée

Le Secret Store CSI Driver peut être configuré pour gérer des secrets complexes et sensibles, qui sont essentiels pour le bon fonctionnement des applications. Nous aborderons un cas d’utilisation typique qui montre comment intégrer des secrets de base de données dans une application déployée sur Kubernetes.

Cas d’Usage : Montage des Secrets de Base de Données pour une Application

Supposons que vous avez des informations de connexion à une base de données stockées dans AWS Secrets Manager et que vous souhaitez les utiliser dans une application. Vous avez configuré un SecretProviderClass comme décrit précédemment. Maintenant, voyons comment monter ces secrets dans une application.

• Création du Pod avec Montage de Secrets: Utilisons un déploiement Kubernetes pour montrer comment ces secrets peuvent être montés et utilisés par une application.

Dans cet exemple, le volume CSI est monté dans le pod de l’application sous /mnt/secrets. Les secrets sont mappés comme des fichiers dans ce répertoire, permettant à l’application de lire ces fichiers pour obtenir les informations de connexion à la base de données.

• Accès aux Secrets dans l’Application: L’application accède aux secrets en lisant les fichiers dans /mnt/secrets. Chaque fichier correspond à un secret dans AWS Secrets Manager, tel que configuré dans le SecretProviderClass. L’application peut par exemple lire le fichier /mnt/secrets/username pour obtenir le nom d’utilisateur de la base de données.

Monitoring et Gestion des Événements

Avec le Secret Store CSI Driver, il est également crucial de surveiller l’accès aux secrets et de gérer les mises à jour des secrets de manière sécurisée. Kubernetes ne met pas automatiquement à jour les secrets montés lorsque le secret original dans AWS est modifié. Une stratégie de mise à jour doit être mise en place pour assurer que les secrets utilisés par les applications sont à jour. Cela peut inclure des redéploiements programmés ou l’utilisation de mécanismes de rechargement de configuration dans les applications pour qu’elles puissent recharger les secrets sans redémarrage complet.

III – Sealed Secrets

3.1 Architecture et Fonctionnement

Les Sealed Secrets sont une solution de Bitnami qui permet de chiffrer des secrets dans des fichiers qui peuvent être commités en toute sécurité dans des dépôts de versionnement (comme Git). Cela résout le problème du stockage sécurisé des secrets qui doivent être distribués ou versionnés avec le code de l’application.

Flux de Travail

1. Chiffrement des Secrets : Un utilisateur crée un secret normal dans Kubernetes, qui est ensuite converti en un « Sealed Secret » à l’aide de la CLI kubeseal. Le secret chiffré peut être stocké en toute sécurité dans un dépôt de code.
2. Déchiffrement et Application par le Contrôleur Sealed Secrets : Lorsque le fichier Sealed Secret est appliqué à un cluster Kubernetes, le contrôleur Sealed Secrets le déchiffre (à condition qu’il s’exécute dans le même cluster qui a généré la clé de chiffrement) et crée un secret Kubernetes normal.
3. Utilisation des Secrets : Une fois le secret déchiffré et recréé, il peut être utilisé par d’autres ressources dans le cluster de la même manière qu’un secret non chiffré.

Installation

Pour utiliser les Sealed Secrets, vous devez installer le contrôleur dans votre cluster Kubernetes ainsi que l’outil de ligne de commande kubeseal.

• Installer le Contrôleur Sealed Secrets:

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.16.0/controller.yaml

• Installer Kubeseal CLI:

Vous pouvez installer kubeseal localement en utilisant Homebrew ou en téléchargeant le binaire approprié :

brew install kubeseal

Ou téléchargez le binaire depuis la page de releases de GitHub et l’ajoutez à votre chemin d’exécution.

Configuration et Utilisation

• Création d’un Secret: Commencez par créer un secret Kubernetes normal:

• Sceller le Secret

Utilisez kubeseal pour transformer ce secret en Sealed Secret :

kubectl create secret generic mysecret --dry-run=client --from-literal=username='myuser' --from-literal=password='mypassword' -o yaml | kubeseal --format yaml > mysealedsecret.yaml

• Appliquer le Sealed Secret

Appliquez le Sealed Secret dans votre cluster :

kubectl apply -f mysealedsecret.yaml

Le contrôleur Sealed Secrets déchiffrera ce secret et créera le secret original dans votre cluster.

Scénarios d’Utilisation

Les Sealed Secrets sont particulièrement utiles dans les flux de travail de développement où les secrets doivent être partagés entre les membres de l’équipe ou stockés dans des dépôts de source sans compromettre la sécurité. Ils permettent également de suivre les modifications apportées aux secrets de manière plus transparente et auditable.

IV – Quand privilégier chaque outil

4.1. External Secrets Operator

Utiliser quand :

• Vous souhaitez une synchronisation dynamique des secrets avec des services de gestion de secrets externes comme AWS Secrets Manager, Azure Key Vault, ou Google Secret Manager.
• Il est essentiel de ne pas stocker les secrets de manière persistante dans le cluster Kubernetes pour des raisons de sécurité.
• Vous voulez profiter de la rotation automatique des secrets sans redémarrage des applications.

Différences principales :

• L’External Secrets Operator synchronise les secrets directement dans Kubernetes en tant qu’objets Secrets, ce qui les rend facilement utilisables par les applications sans configuration supplémentaire pour l’accès aux fichiers.
• Il est conçu pour être hautement configurable avec le support de multiples providers de secrets externes.

4.2. Secret Store CSI Driver

Utiliser quand :

• Vous avez besoin que les secrets soient accessibles sous forme de fichiers montés dans des volumes de pod, ce qui peut être une exigence pour certaines applications qui lisent la configuration à partir de fichiers.
• La sécurité des secrets doit être maintenue sans les exposer directement en tant qu’objets dans Kubernetes, les gardant hors de l’ETCD même sous forme chiffrée.
• Vous travaillez dans un environnement multi-cloud ou hybride où l’uniformisation de l’accès aux secrets à travers différents clouds est nécessaire.

Différences principales :

• Le Secret Store CSI Driver ne crée pas d’objets Secret mais monte les secrets directement dans les pods sous forme de fichiers, offrant une couche supplémentaire de sécurité en limitant l’accès au niveau du système de fichiers.
• Il peut également gérer l’utilisation des identités gérées par le cloud pour l’accès aux secrets, réduisant la nécessité de gérer les clés API ou les secrets d’accès.

4.3. Sealed Secrets

Utiliser quand :

• Vous devez versionner vos secrets avec vos applications dans des dépôts de code source, permettant une gestion de configuration et une automatisation du déploiement complet.
• Il est crucial de garantir que les secrets ne soient pas accessibles ou visibles dans les pipelines de CI/CD ou par des personnes non autorisées.
• Vous cherchez à simplifier le processus de gestion des secrets dans des environnements où les développeurs doivent être capables de gérer les déploiements sans accéder directement aux secrets en production.

Différences principales :

• Les Sealed Secrets sont conçus pour être stockés de manière sécurisée dans des systèmes de contrôle de version, car ils sont chiffrés avant d’être enregistrés ou partagés.
• Ils nécessitent une étape de déchiffrement qui est gérée par le contrôleur Sealed Secrets au sein de Kubernetes, rendant les secrets utilisables uniquement à l’intérieur du cluster où ils ont été scellés.

Chacun de ces outils a des forces uniques et répond à des besoins spécifiques en matière de sécurité et de gestion des configurations dans les environnements Kubernetes. Le choix entre ces outils dépendra largement de vos exigences spécifiques en matière de sécurité, de la manière dont les applications sont conçues pour accéder aux secrets, et de l’environnement opérationnel de votre infrastructure.

Conclusion

La gestion des secrets dans Kubernetes est une composante cruciale de la sécurité et de la gestion des configurations dans les environnements modernes de déploiement d’applications. Comme nous l’avons exploré, il existe plusieurs outils qui peuvent aider à améliorer la gestion des secrets au-delà des capacités natives fournies par Kubernetes. Chacun de ces outils — External Secrets Operator, Secret Store CSI Driver, et Sealed Secrets — offre des avantages uniques qui peuvent être adaptés aux différents besoins des entreprises en matière de sécurité, de gestion et d’automatisation des déploiements.

L’External Secrets Operator est idéal pour les organisations qui nécessitent une intégration transparente avec des systèmes de gestion de secrets externes et une synchronisation dynamique des secrets dans le cluster Kubernetes. Le Secret Store CSI Driver convient aux applications qui bénéficient de l’accès aux secrets via un système de fichiers monté, offrant une sécurité renforcée en ne stockant pas les secrets en tant qu’objets dans Kubernetes. Enfin, les Sealed Secrets sont parfaitement adaptés aux flux de travail où les secrets doivent être versionnés avec le code de l’application, offrant une manière sécurisée de gérer les secrets dans les dépôts de versionnement.

Choisir l’outil approprié dépendra de vos exigences spécifiques en matière de sécurité, de la nature de vos applications, et de votre environnement de déploiement. Il est crucial de comprendre non seulement les capacités de chaque outil mais aussi les meilleures pratiques de sécurité pour leur mise en œuvre afin de maximiser la sécurité tout en facilitant le développement et l’opération des applications.