La gestion des secrets sur Kubernetes

À la suite du Meetup de la communauté Cloud Native Montpellier sur la sécurité, le hacking et les stratégies de défense contre les attaques (Chapitre 6), je vous propose cet article sur la gestion des secrets dans l’écosystème Cloud. Vous découvrirez les distinctions entre la gestion des secrets via Terraform et Kubernetes, ainsi qu’une solution hybride pour une industrialisation efficace. Je vais vous montrer comment intégrer et configurer External Secrets pour optimiser la gestion des secrets au sein de vos clusters Kubernetes.

Définition des termes utilisés liés au “secret” en fonction du contexte

Contexte générique

• Secret : un « secret » désigne une information confidentielle, telle qu’une clé d’authentification, un mot de passe ou une clé de chiffrement, utilisée pour assurer la sécurité et la confidentialité des données.

Contexte Cloud Provider

• Secret Manager : un « Secret Manager » fait référence à un service ou une plateforme qui permet de stocker, gérer et distribuer de manière sécurisée les secrets, tels que les mots de passe, les clés API, et autres informations sensibles utilisées par les applications et/ou des services déployés sur le Cloud provider.

Contexte Kubernetes

• Secret : dans un contexte Kubernetes, un « secret » (Ressource native Kubernetes) est un objet utilisé pour stocker des informations sensibles, telles que des clés d’authentification, des mots de passe ou d’autres données confidentielles, de manière sécurisée. Ces secrets sont ensuite utilisés par les applications pour accéder à des ressources sans exposer directement les informations confidentielles dans les fichiers de configuration ou dans le code source.

• External Secrets : la solution External Secrets permet d’intégrer et de gérer de manière centralisée des secrets provenant de sources externes au sein d’un cluster.

La solution External Secrets offre les bénéfices suivants

• Une gestion sécurisée des informations sensibles,
• Facilite l’intégration avec des gestionnaires de secrets externes,
• Réduit les risques de fuites de secrets,
• Améliore la sécurité globale des applications déployées, tout en simplifiant la rotation et la mise à jour des secrets.

Comment choisir une solution de gestion de secrets pour Kubernetes ?

Le choix de la solution de gestion de secrets doit évidemment être fait en fonction de votre contexte, et principalement de deux composantes :

Le choix du fournisseur de solution

• [Accès] Qui doit avoir accès au secret ? Si l’accès au secret est fait par un utilisateur ou par une application, le choix pourrait être différent.
• [Localisation] Où le secret est-il stocké ? L’endroit de stockage d’un secret peut être conditionné à des contraintes légales, techniques ou politiques.
• [Protection] Définir le type de menaces auxquelles le secret peut être soumis ? La définition du type de menaces peut être utile dans le choix de la solution retenue.

L’intégration de la solution

En effet, si le choix porte sur une solution de gestion de secret ne permettant pas une bonne intégration, l’adoption de celle-ci sera compliquée.

[Création] De quelle manière mon secret doit-il être créé ?
En fonction de la manière dont le secret doit être créé le choix peut différer.
Demander par exemple à un utilisateur (non développeur) d’utiliser une syntaxe json afin d’ajouter un secret peut être un élément rebutant dans l’adoption de la solution.

[Mise à jour] Comment je souhaite mettre mon secret à jour ?
Une fois que le secret est créé, il faut définir comment la mise à jour de celui-ci va être effectuée. En fonction du besoin, la solution utilisée peut être différente.

[Rafraichissement] Temps de rafraîchissement si je mets à jour mon secret ?
Le temps de rafraîchissement permet de définir sous combien de temps l’information sera répliquée.
Si un secret doit être modifié au sein d’une application plus ou moins critique un temps de rafraîchissement adapté devra être défini afin d’éviter que des erreurs apparaissent suite à une information devenue erronée.

[Intégration] Comment l’application peut accéder à mon secret ?

• La méthode d’accès au secret est un élément pouvant être différenciant.
• Aujourd’hui les intégrations diffèrent en fonction des solutions utilisées.
• Cela peut aller par exemple sur un Cloud provider, d’une Access Key / Secret Key, à un système complètement intégré basé sur les Service Accounts.

Les solution de gestion de secret, par Cloud provider

A noter : Le format utilisé pour le stockage des secrets (Key/Value ou json) est important car l’intégration sera différente en fonction de ce critère.

La gestion des secrets chez Kaliop

Le choix du fournisseur de solution à utiliser

Chez Kaliop nous avons choisi d’utiliser comme fournisseur de solution le Cloud provider où se trouve notre Cluster Kubernetes pour plusieurs raisons.

Sécurité renforcée : limitation de la surface d’attaque des secrets contre les accès non autorisés, les fuites de données et les attaques malveillantes. En effet la gestion des accès est gérée au sein du Cloud provider avec des mécanismes permettant notamment d’éviter l’utilisation d’Access Key / Secret Key pouvant être utilisé hors du Cloud provider.

Gestion des secrets optimisée :

• L’accès aux secrets peut être très granulaire basé sur les rôles et les identités des utilisateurs.
• Possibilité de mettre en place des systèmes de rotation des secrets afin de minimiser le risque de compromission à long terme.
• Suivi et audit précis des accès aux secrets pour une meilleure visibilité et une meilleure responsabilisation.

Intégration transparente : la compatibilité avec des outils de gestion des secrets (External Secrets) facilite l’adoption de la solution.

Exemple d’utilisation :
Imaginez un cluster Kubernetes exécutant une application qui nécessite des clés d’API pour accéder à des services externes. En stockant ces clés d’API dans le Secret Manager du Cloud provider, l’application peut y accéder en toute sécurité sans les exposer dans le code ou les configurations. Cela réduit le risque de fuite des clés d’API et d’accès non autorisé aux services externes.

En plus des avantages mentionnés ci-dessus, l’utilisation de Secret Manager sur le fournisseur de Cloud où se trouve le cluster Kubernetes peut également s’avérer conforme aux exigences de conformité et de réglementation.

Choix de la solution de gestion des secrets à utiliser

Chez Kaliop, nous avons choisi d’utiliser directement les solutions managées proposées sur les différents Cloud providers. Quand plusieurs solutions sont présentes (Exemple : AWS) nous choisissons la solution la plus adaptée aux besoins du client.

Intégration de la solution via trois approches différentes

Approche Ops

L’approche Ops est une approche basée sur les outils d’infrastructure tels que Terraform avec une CI afin d’amener de l’automatiser sur l’ensemble.

Dans ce schéma nous pouvons voir les informations suivantes:

• Terraform est utilisé afin de provisionner le secret au sein du Secret Manager du Cloud provider
• Terraform est utilisé afin de créer le secret au sein du cluster Kubernetes
• Terraform est placé dans une CI afin de permettre de l’exécuter plus facilement afin de mettre à jour le secret

Le point bloquant de cette approche est qu’il sera obligatoire de mettre les secrets dans le code Terraform si ceux-ci doivent être managés par Terraform. Terraform fonctionnant avec un système de “Desired State” les secrets devront être présents si des updates doivent être effectuées.

Approche Développeur

L’approche Développeur est basée sur l’utilisation de Helm afin d’éviter d’avoir à utiliser d’outil de provisioning d’infrastructure car cela pose la plupart des problèmes de droits sur le Cloud provider et de périmètre de responsabilité.

Dans ce schéma nous pouvons voir les informations suivantes:

• Helm est utilisé afin de créer le secret au sein du cluster Kubernetes
• Helm est placé dans une CI afin de permettre de l’exécuter plus facilement afin de mettre à jour le secret

Les points bloquant de cette approche sont qu’il sera obligatoire de mettre les secrets dans le chart Helm en clair.

L’utilisation d’un outil additionnel tel que SOPS pourrait être utilisé mais cela nécessite l’ajout d’un outil additionnel afin de gérer les secrets, une intégration spécifique avec Helm et l’installation de l’outil (SOPS) sur les postes des différents intervenants.

Aucun lien n’est fait au niveau du Secret Manager du Cloud provider. Cela ne permettra pas de bénéficier des différents atouts que le Secret Manager peut offrir.

Approche DevOps

L’approche DevOps est une culture collaborative entre les développeurs et les équipes d’exploitation qui vise à automatiser et optimiser le processus de développement logiciel et de livraison, en mettant l’accent sur la communication, la collaboration et l’intégration continue.

Dans notre cas, cette approche se matérialise par l’utilisation des outils d’infrastructure tels que Terraform, ainsi que les outils tels que Helm, modifiables également par les développeurs.

Dans ce schéma nous pouvons voir les informations suivantes:

• Terraform est utilisé afin de provisionner le secret au sein du Secret Manager du Cloud provider uniquement pour la partie initialisation. Cela a pour but de garantir l’idempotence entre les différents environnements.
• Terraform est placé dans une CI afin de permettre de l’exécuter plus facilement si de nouveaux secrets sont à créer.
• Terraform est utilisé afin de déployer le Helm chart External Secrets sur notre cluster Kubernetes et de faire la configuration du Cluster Secret Store.
• ArgoCD est utilisé pour gérer les applications (Helm Chart).
• Une ressource ExternalSecret est créée dans le chart de l’application afin de faire le mapping entre l’emplacement des secrets sur le Secret manager du Cloud provider et le secret Kubernetes.

Les différents points que nous souhaitions valider le sont, et il n’y a aucun point bloquant dans cette approche.

L’approche DevOps est l’approche utilisée actuellement chez Kaliop dans la Gestion des secrets sur Kubernetes.

Schéma de fonctionnement de External Secrets :

Exemples d’utilisation de External Secrets

Besoin : Je veux connecter External Secrets au secret manager de mon Cloud provider

Création d’une ressource de type “ClusterSecretStore” (Global) ou “SecretStore” (Namespace) via la CRD External Secrets, afin de déclarer la méthode de connexion au secret Manager du Cloud provider.

Besoin : Je veux avoir le mot de passe de mon Utilisateur MySQL dans un secret Kubernetes (Le mot de passe de mon user MySQL se trouve dans le secret manager de mon cloud provider)

Création d’une ressource ExternalSecret via la CRD External Secrets afin de faire le mapping entre l’emplacement du secret sur mon Cloud provider et le secret Kubernetes que je souhaite créer afin de placer les informations.

Besoin : Je veux utiliser le mot de passe MySQL dans mon secret Kubernetes dans ma variable d’environnement “DATABASE_PASSWORD”.

Le référencement de l’emplacement du mot de passe se fait en indiquant le nom de la variable à utiliser puis le nom du secret Kubernetes utilisé ainsi que le champ souhaité.

Besoin: Je veux utiliser le mot de passe MySQL dans mon secret Kubernetes via un fichier monté sur mon pod (/opt/mysql/database-password)

Création d’un volume en indiquant le nom du secret Kubernetes utilisé ainsi que le champ souhaité.

Forces et faiblesses de l’utilisation d’External Secrets

Forces

• Granularité des droits : l’attribution des droits pour mettre à jour les secrets sur le Secret Manager se fait au niveau du Cloud provider, ce qui permet une grande granularité.
• Configuration du temps de rafraîchissement : le temps de rafraîchissement peut être configuré par ressource (ExternalSecret).
• Découpage des périmètres : Les périmètres peuvent être séparés entre la partie infrastructure et la partie application.

Faiblesses

• Automatisation nécessaire : la mise à jour en masse des secrets sur le Cloud provider nécessite une automatisation via un mécanisme propre au Cloud provider en question

Choisir une solution de gestion de secrets sur Kubernetes : une décision cruciale

Nous pouvons conclure que le choix d’une solution de gestion de secrets sur Kubernetes est loin d’être anodin. Il est important de bien comprendre les besoins et l’intégration de celle-ci. Cela nécessite une collaboration étroite entre les équipes Ops et Dev pour déterminer ensemble la solution adéquate.

Il est également crucial de noter que lorsqu’une variable d’environnement est modifiée, le pod Kubernetes n’est pas relancé, contrairement à la modification d’un volume Kubernetes qui déclenche un redémarrage du conteneur. Cela peut poser un problème lors du rafraîchissement des secrets, car le pod n’est pas redémarré, ce qui peut entraîner des incohérences.

Un prochain article concernant “Reloader” permettra de traiter ce problème. En attendant, je vous invite à visionner le webinar que nous avons animé il y a quelques temps : Comment déployer Kubernetes sur le Cloud souverain Scaleway : témoignage de l’ADEME.

Retrouvez tous les use cases et configurations présentés dans cet article dans ce repository.