Bonnes pratiques de gestion des Secrets Kubernetes

Kubernetes utilise des objets secrets, appelés Secrets, pour stocker des jetons OAuth, des clés SSH (Secure Shell), des mots de passe et d’autres données secrètes. Les Secrets Kubernetes permettent de séparer les données confidentielles du code de notre application, en les créant indépendamment des pods. Cette séparation, associée à une configuration bien définie du contrôle d’accès basé sur les rôles (RBAC), réduit le risque d’exposition du Secret — et d’exploitation potentielle — lors des interactions avec les pods, renforçant ainsi la sécurité.

Bien que les Secrets Kubernetes contribuent à éviter toute exposition accidentelle des données, ils ne protègent pas nécessairement les données du cluster contre les cyberattaques malveillantes. Par exemple, un utilisateur non autorisé ayant la permission d’accéder à notre cluster etcd peut accéder à tous nos Secrets Kubernetes. Nous devons donc gérer les Secrets Kubernetes avec soin pour garantir leur sécurité.

Dans cet article, nous explorons les bonnes pratiques de gestion des Secrets Kubernetes. Consultez notre article sur la sécurité Kubernetes pour découvrir d’autres risques de sécurité et bonnes pratiques.

Fonctionnement des Secrets Kubernetes

Les Secrets Kubernetes permettent de stocker des données dans un objet secret, auquel les clients Kubernetes peuvent ensuite accéder ou qu’ils peuvent modifier. Un Secret est une paire clé-valeur qui comprend un ID de Secret et des informations d’authentification. Kubelet utilise l’ID de Secret pour identifier les identifiants à fournir à un conteneur d’application lors de la création d’un pod.

Kubelet s’exécute sur chaque nœud d’un cluster et gère les pods et leurs conteneurs. Les pods ne peuvent accéder aux Secrets que si ceux-ci font explicitement partie d’un volume monté ou au moment où kubelet récupère une image à utiliser dans un pod.

Le serveur d’API Kubernetes stocke les Secrets Kubernetes. Seuls certains utilisateurs autorisés à accéder au serveur d’API Kubernetes peuvent y accéder. Le serveur d’API Kubernetes constitue un point de défaillance unique pour notre application : nous devons donc protéger nos données.

Les Secrets Kubernetes :

• permettent de partager de manière sécurisée des données de configuration entre un contrôleur et ses processus de travail, par exemple entre kubelet et un pod

• offrent une autre façon de stocker des données sensibles dans le cluster Kubernetes, comme des identifiants permettant d’accéder à des applications externes

• permettent de créer facilement de nouvelles ressources dans notre cluster Kubernetes, comme de nouveaux déploiements ou espaces de noms

Bonnes pratiques pour les Secrets Kubernetes

Les Secrets, comme les clés, mots de passe, jetons et autres valeurs de configuration, doivent être stockés correctement. Si notre cluster Kubernetes est compromis, les Secrets doivent rester sécurisés. Un attaquant ne doit pas pouvoir exploiter les Secrets pour compromettre des données sensibles, créer un botnet ou prendre le contrôle de serveurs de commande et de contrôle (C2).

Voici quelques techniques pour protéger nos Secrets Kubernetes :

1. Activer le chiffrement au repos

2. Configurer les règles RBAC

3. Chiffrer les données etcd

4. Utiliser un magasin centralisé de Secrets pour simplifier la gestion

Activer le chiffrement au repos

Les données des Secrets Kubernetes sont encodées au format base64 et stockées en texte brut dans etcd. Etcd est un magasin clé-valeur qui sert de stockage aux états du cluster Kubernetes et aux données de configuration. Stocker les Secrets en texte brut dans etcd est risqué, car des attaquants peuvent facilement les compromettre et s’en servir pour accéder à des systèmes.

La base de données etcd n’est pas chiffrée par défaut. Nous devons donc chiffrer les données des Secrets au repos pour protéger les informations sensibles qu’ils contiennent et éviter qu’elles ne tombent entre les mains d’un attaquant. Un attaquant ayant accès au système de fichiers peut lire les Secrets qui s’y trouvent.

En outre, Kubernetes propose une fonctionnalité de chiffrement au repos qui nous permet d’utiliser l’API Kubernetes pour chiffrer les Secrets avant leur stockage dans etcd. Nous pouvons également utiliser des fournisseurs de chiffrement, tels que KMSConfiguration, IdentityConfiguration, SecretboxConfiguration et AESConfiguration, pour protéger nos Secrets au repos.

Un cluster Kubernetes comprend plusieurs nœuds, chacun disposant d’identifiants uniques pour les opérations de chiffrement et de déchiffrement. L’objet EncryptionConfiguration définit le matériel cryptographique utilisé pour ces opérations sur chaque nœud. La configuration de ces fournisseurs de chiffrement figure dans l’objet EncryptionConfiguration, qui permet de chiffrer les Secrets localement à l’aide d’une clé gérée localement.

Configurer les règles RBAC

Chiffrer les Secrets Kubernetes au repos ne suffit pas à les protéger. Nous devons également contrôler l’accès aux secrets à l’aide des règles RBAC de Kubernetes. La politique de sécurité qui autorise l’accès aux Secrets peut être basée sur une tâche, une durée ou un rôle.

Les Secrets Kubernetes et les règles RBAC fonctionnent de concert. Les objets Secret existent notamment pour accorder des accès RBAC différents de ceux que nous attribuerions à un ConfigMap.

Nous pouvons utiliser l’objet ClusterRoles pour définir les actions qu’un utilisateur peut effectuer dans un cluster, et un rôle pour définir celles qu’il peut effectuer dans un espace de noms. RBAC limite la création, la suppression et la modification des Secrets à certains utilisateurs. Par exemple, nous pouvons définir une règle interdisant aux développeurs de créer des Secrets dans un espace de noms donné, mais pas dans les autres.

Le framework RBAC intégré à Kubernetes nous permet d’appliquer le principe du moindre privilège (PoLP), afin de limiter l’accès des utilisateurs ou des programmes aux seules ressources ou informations nécessaires à leurs tâches ou à leur bon fonctionnement. Il nous aide à garantir que seuls les comptes et conteneurs privilégiés peuvent accéder aux Secrets. Si un attaquant compromet un composant, le PoLP l’empêche d’élever ses privilèges et de compromettre d’autres composants.

Chiffrer les données etcd

Comme il suffit d’avoir l’autorisation d’accéder au cluster etcd pour accéder aux Secrets, nous devons protéger avec vigilance les données sensibles, notamment en automatisant la rotation des clés, en surveillant leur ancienneté et en conservant des journaux d’audit. Le meilleur moyen d’y parvenir est de rendre ces données indisponibles dans etcd. Le pilote de stockage par défaut d’etcd est local, et les clés de chiffrement sont stockées localement dans le fichier de configuration. Cette configuration peut donc être vulnérable aux logiciels malveillants et à d’autres menaces.

Pour renforcer la sécurité des données etcd, nous pouvons chiffrer les Secrets avant de les stocker. Nous devrions utiliser un fournisseur de chiffrement, comme un service de gestion des clés (KMS), pour stocker nos clés et nos Secrets. Il convient de noter que la plupart des fournisseurs Kubernetes managés chiffrent par défaut le stockage des Secrets etcd lors de la création d’un cluster, ce qui contribue à protéger nos données etcd.

Une autre méthode consiste à réserver l’accès à etcd au serveur d’API. Seuls les nœuds qui doivent accéder aux clusters etcd devraient y être autorisés. Nous pouvons accorder l’accès à etcd via le serveur d’API Kubernetes et accorder des permissions de lecture et d’écriture uniquement à certains utilisateurs ou groupes.

Utiliser un magasin centralisé de Secrets pour simplifier la gestion

Les Secrets Kubernetes sont essentiels au fonctionnement de notre application et peuvent être stockés à plusieurs endroits. Lorsqu’ils sont dispersés, leur sécurisation devient difficile, en particulier si nous devons les gérer dans plusieurs clusters ou si nous utilisons à la fois des paires de clés privées et publiques. Sans système centralisé de gestion des Secrets, ceux-ci se retrouvent éparpillés dans différents emplacements, ce qui élargit la surface d’attaque pour les utilisateurs non autorisés.

La gestion centralisée des Secrets présente de nombreux avantages, surtout lorsqu’ils sont utilisés dans plusieurs instances. Une solution centralisée offre une vue unifiée de la sécurité Kubernetes. Nous pouvons facilement gérer les Secrets, les contrôles d’accès et les audits. De plus, un journal d’audit centralisé permet de mieux comprendre les événements de sécurité critiques.

Des fournisseurs tiers proposent des fonctionnalités plus avancées et plus sécurisées pour la gestion des Secrets Kubernetes. Voici quelques services de gestion des Secrets tiers populaires.

AWS Secrets Manager

AWS Secrets Manager permet de stocker et de renouveler les Secrets facilement et en toute sécurité. Il propose une console de gestion unifiée pour toutes nos ressources Amazon Web Services (AWS). L’outil AWS Secrets Manager est intégré à Kubernetes, ce qui nous permet d’y stocker nos Secrets chiffrés en toute sécurité. Nous pouvons ensuite utiliser l’API Kubernetes pour accéder à ces secrets au moment de l’exécution sans risquer de les exposer dans notre code.

Ce service de gestion des Secrets permet de récupérer, consulter et gérer les identifiants et secrets AWS depuis un emplacement unique et sécurisé. Nous pouvons utiliser AWS Secrets Manager avec d’autres services AWS, tels qu’AWS Identity and Access Management (IAM), AWS Key Management Service (AWS KMS) et AWS Simple Storage Service (S3).

Azure Key Vault et Azure Kubernetes Service

Microsoft Azure Key Vault est un gestionnaire de Secrets qui permet de stocker et d’utiliser des clés cryptographiques. Nous pouvons sauvegarder et récupérer les objets de coffre supprimés, journaliser et surveiller les Secrets, et utiliser les coffres de clés pour authentifier les utilisateurs.

Nous pouvons également utiliser Azure Kubernetes Service (AKS) pour l’autorisation Azure RBAC et Kubernetes RBAC. Nous pouvons aussi utiliser Azure RBAC pour contrôler l’accès aux ressources au moyen d’attributions de rôles. Il autorise également les groupes et les utilisateurs, tandis que le RBAC intégré à Kubernetes permet d’utiliser des comptes de service Kubernetes.

HashiCorp Vault

HashiCorp Vault est un outil open source de gestion des Secrets qui permet de stocker et de gérer les Secrets et de protéger les données sensibles. Cet outil gère l’accès des utilisateurs aux données sensibles et nous permet de renouveler ces données ou de révoquer leur accès en cas de menace pour la sécurité.

Nous pouvons utiliser HashiCorp Vault pour mettre en œuvre différentes mesures de sécurité Kubernetes, notamment le chiffrement des données, le contrôle d’accès basé sur l’identité et la gestion des Secrets. HashiCorp Vault utilise le chiffrement TSL et AES 256 bits pour sécuriser les données en transit et au repos, respectivement.

Conclusion

Les Secrets authentifient les utilisateurs et les services, et contrôlent l’accès aux ressources et aux autres Secrets. Les Secrets Kubernetes permettent de stocker des données dans un objet secret, auquel les clients Kubernetes peuvent ensuite accéder ou qu’ils peuvent modifier. Comme les Secrets contiennent des données sensibles, telles que des jetons, des clés et des mots de passe, il est essentiel de suivre les bonnes pratiques pour les protéger.

Il existe plusieurs façons de protéger nos Secrets. Pour commencer, nous devrions activer le chiffrement au repos. Celui-ci renforce la sécurité de nos Secrets. Toutefois, chiffrer les objets Secret Kubernetes au repos ne suffit pas à les protéger. Nous devons également contrôler l’accès aux secrets à l’aide des règles RBAC. Le framework RBAC intégré à Kubernetes nous permet de limiter l’accès des utilisateurs ou des programmes aux seules ressources ou informations nécessaires. Nous pouvons également faire appel à un service tiers de gestion des Secrets, comme ceux présentés plus haut, pour mieux protéger nos Secrets.

Pour gérer correctement les Secrets, les développeurs et les administrateurs de clusters Kubernetes doivent surveiller de près la sécurité de nos informations sensibles. En complément des bonnes pratiques présentées ici, consultez le guide de Kubernetes sur la gestion des Secrets — destiné aux développeurs comme aux administrateurs de clusters — afin de protéger vos Secrets.

La sécurisation des identifiants et des autres secrets n’est qu’une étape vers des applications plus sûres : vous devez sécuriser chaque étape du cycle de développement logiciel. Identifiez et corrigez les vulnérabilités potentielles dans le code que vous écrivez et les projets open source que vous utilisez avec Snyk Code et Snyk Open Source. Utilisez Snyk Container pour commencer avec une image de base plus sûre et détecter les vulnérabilités supplémentaires que vous pourriez introduire lors du processus de build. Enfin, vérifiez que le code que vous déployez ne présente aucune faille de sécurité avec Snyk IaC.

Articles associés :

• Gestion des secrets : outils et bonnes pratiques

• Sécurité AWS

• Créer des images Docker avec Kubernetes

• 10 paramètres de contexte de sécurité Kubernetes à connaître

• Implications des opérateurs Kubernetes en matière de sécurité

• Surveillance Kubernetes

• Orchestration de conteneurs