Intégration de Kubernetes Vault via Sidecar Agent Injector vs. Vault Secrets Operator vs. CSI provider (2023)

Dans cet article, j'explorerai trois méthodes différentes pour intégrer HashiCorp Vault à Kubernetes :

1. L'injecteur d'agent Vault Sidecar
2. Le fournisseur Vault Container Storage Interface (CSI)
3. L'opérateur des secrets du coffre-fort

Je fournirai des conseils pratiques pour chaque méthode afin de vous aider à comprendre et à choisir la meilleure méthode pour votre cas d'utilisation.

Cet article n'est pas destiné à être une documentation de produit ou un guide de mise en œuvre étape par étape. Il s'adresse aux praticiens DevOps familiarisés avec HashiCorp Vault et Kubernetes qui ont également une compréhension de base des concepts de gestion des secrets.

»Injecteur d'agent Vault Sidecar

LeInjecteur d'agent Vault Sidecartire parti de lamodèle de side-carpour modifier les spécifications du pod afin d'inclure un conteneur Vault Agent qui restitue les secrets Vault à un volume de mémoire partagée. En rendant des secrets à un volume partagé, les conteneurs du pod peuvent consommer des secrets Vault sans être conscients de Vault. L'injecteur est un contrôleur de webhook de mutation Kubernetes. Le contrôleur intercepte les événements de pod et applique des mutations au pod si des annotations existent dans la demande. Cette fonctionnalité est fournie par levoûte-k8sprojet et peut être installé et configuré automatiquement à l'aide de la charte Vault Helm.

»Fournisseur Vault CSI

LeFournisseur Vault CSIpermet aux pods de consommer des secrets Vault en utilisant des données éphémèresMagasin de secrets CSItomes. À un niveau élevé, le pilote CSI Secrets Store permet aux utilisateurs de créerSecretProviderClassobjets. Ces objets définissent le fournisseur de secrets à utiliser et les secrets à récupérer. Lorsque des pods demandant des volumes CSI sont créés, le pilote CSI Secrets Store envoie la demande au fournisseur Vault CSI si le fournisseur estsauter. Le fournisseur Vault CSI utilise ensuite leSecretProviderClasset le compte de service du pod pour récupérer les secrets de Vault et les monter dans le volume CSI du pod. Notez que le secret est extrait de Vault et rempli dans le volume de stockage des secrets CSI pendant laCréationConteneurphase. Cela signifie que le démarrage des pods sera bloqué jusqu'à ce que les secrets aient été lus depuis Vault et écrits sur le volume.

»Opérateur des secrets du coffre-fort

LeOpérateur des secrets du coffre-fortest une nouvelle méthode d'intégration qui implémente un opérateur de secrets Kubernetes avec un ensemble de CRD responsables de la synchronisation native des secrets Vault avec les secrets Kubernetes. L'opérateur prend en charge la synchronisation du cycle de vie complet de la gestion des secrets, y compris les secrets statiques, dynamiques et basés sur PKI à partir d'une ou plusieurs instances de serveur Vault. L'opérateur est également capable de gérer la rotation secrète et d'effectuer des actions de post-rotation, y compris la notification d'une application directement via unmise à jour progressived'unDéploiementou en déclenchant une mise à jour continue.

»Considérations de conception courantes

Il existe certaines similitudes et différences entre les trois solutions que vous devez prendre en compte lors de la conception et de la mise en œuvre de votre stratégie de gestion des secrets dans les environnements Kubernetes.

1. Projections secrètes :Chaque application nécessite que des secrets lui soient présentés d'une manière spécifique. En règle générale, les applications s'attendent à ce que les secrets soient soit exportés sous forme de variables d'environnement, soit écrits dans un fichier que l'application peut lire au démarrage. Gardez cela à l'esprit lorsque vous décidez de la bonne méthode à utiliser.
2. Portée secrète :Certaines applications sont déployées dans plusieurs environnements Kubernetes (par ex.dev, qa, prod) dans vos centres de données, la périphérie ou les clouds publics. Certains services s'exécutent en dehors de Kubernetes sur des machines virtuelles, sans serveur ou d'autres services gérés dans le cloud. Vous pouvez être confronté à des scénarios dans lesquels ces applications doivent partager des ensembles de secrets dans ces environnements hétérogènes. Définir correctement la portée des secrets pour qu'ils soient locaux dans l'environnement Kubernetes ou globaux dans différents environnements permet de garantir que chaque application peut accéder facilement et en toute sécurité à son propre ensemble de secrets dans l'environnement dans lequel elle est déployée.
3. Types secrets :Les secrets peuvent être des fichiers texte, des fichiers binaires, des jetons ou des certificats. Ils peuvent être générés statiquement ou dynamiquement. Ils peuvent être valides en permanence ou dans le temps. Ils varient également en taille. Vous devez tenir compte des types de secrets requis par votre application et de la manière dont ils sont projetés dans l'application.
4. Définition secrète :Vous devez également tenir compte de la manière dont chaque secret est défini, créé, mis à jour et supprimé, ainsi que des outils associés à ce processus.
5. Chiffrement:Le chiffrement des secrets au repos et en transit est une exigence essentielle pour de nombreuses entreprises.
6. Gouvernance :Les applications et les secrets peuvent avoir une relation plusieurs-à-plusieurs qui nécessite une attention particulière lorsqu'il s'agit d'accorder l'accès aux applications pour récupérer leurs secrets respectifs. À mesure que le nombre d'applications et de secrets augmente, le défi de la gestion de leurs politiques d'accès augmente également.
7. Mises à jour et rotation des secrets :Les secrets peuvent être loués, limités dans le temps ou pivotés automatiquement, et chaque scénario doit être un processus programmatique pour garantir que le nouveau secret est correctement propagé aux pods d'application.
8. Mise en cache secrète :Dans certains environnements Kubernetes (par exemple, périphérie ou vente au détail), il existe un besoin potentiel de mise en cache secrète en cas de défaillance de communication ou de réseau entre l'environnement et le stockage secret.
9. Auditabilité :La tenue d'un journal d'audit d'accès secret détaillant toutes les informations d'accès secret est essentielle pour assurer la traçabilité des événements d'accès secret.

En gardant à l'esprit ces considérations de conception, passons en revue certaines des similitudes et des différences entre les trois solutions d'intégration.

»Similitudes

Solutions Vault Operator, CSI et side-car :

• Simplifiez la récupération de différents types de secrets stockés dans Vault et exposez-les au pod cible exécuté sur Kubernetes sans qu'il soit conscient des processus Vault pas si triviaux. Il est important de noter qu'il n'est pas nécessaire d'apporter des modifications à la logique ou au code de l'application pour qu'elle utilise ces solutions, ce qui facilite la migration des applications brownfield vers Kubernetes. Les développeurs travaillant sur des applications entièrement nouvelles peuvent tirer parti de laSDK Vaultpour s'intégrer directement à Vault.

• Prend en charge tous les types de coffre-fortmoteurs secrets. Cela signifie que vous pouvez tirer parti d'un ensemble complet de types de secrets, allant des secrets clé-valeur statiques aux informations d'identification de base de données générées dynamiquement et aux certificats TLS avec TTL personnalisé.

  (Video) How to Get Vault Secrets into Kubernetes

• Tirez parti du jeton de compte de service de pod Kubernetes de l'application en tant que"Zéro secret"pour s'authentifier auprès de Vault via la méthode d'authentification Kubernetes. Cela signifie qu'il n'est pas nécessaire de gérer une autre identité distincte pour identifier les pods d'application lors de l'authentification auprès de Vault.

Workflow d'authentification Kubernetes de Vault

• Exiger que les secrets souhaités existent dans Vault avant de déployer l'application
• Exiger que le compte de service du pod soit lié à un rôle Vault avec une stratégie permettant l'accès aux secrets souhaités (c'est-à-dire que Kubernetes RBAC n'est pas utilisé pour autoriser l'accès aux secrets)
• Déployable via Helm
• Exiger la récupération réussie des secrets de Vault avant le démarrage des pods
• S'appuyer sur des annotations de pod définies par l'utilisateur pour récupérer les secrets requis à partir de Vault
• Les deuxService d'injecteur de side-caretPilote CSIpeut automatiquement renouveler, faire pivoter et récupérer des secrets/tokens.

»Différences

Voici comment les trois solutions sont différentes :

• La solution Sidecar Agent Injector est composée de deux éléments :
  • L'injecteur de service Sidecar, qui est déployé en tant que service de cluster et est responsable de l'interception des événements de pod apiserver Kubernetes et de la mutation des spécifications de pod pour ajouter les conteneurs sidecar requis
  • Le conteneur Vault Sidecar, qui est déployé à côté de chaque pod d'application et est responsable de l'authentification dans Vault, de la récupération des secrets de Vault et du rendu des secrets pour l'application à consommer
• En revanche, le pilote Vault CSI est déployé en tant que démonset sur chaque nœud du cluster Kubernetes et utilise la classe de fournisseur de secrets spécifiée et le compte de service du pod pour récupérer les secrets de Vault et les monter dans le volume CSI du pod.
• L'opérateur de coffre-fort est également capable de gérer la rotation secrète et d'effectuer des actions de post-rotation, notamment de notifier une application directement via (ou en déclenchant) une mise à jour continue d'un déploiement.
• L'injecteur d'agent Sidecar prend en chargetousSauterauthentification automatiqueméthodes. Le pilote Sidecar CSIne prend en charge que la méthode d'authentification Kubernetes de Vaultet Vault Operator ne prend en charge que la méthode d'authentification Kubernetes pour le moment.
• Le conteneur side-car qui est lancé avec chaque pod d'application utiliseAgent de coffre-fort, qui fournit un ensemble puissant de fonctionnalités telles que l'authentification automatique, la création de modèles et la mise en cache. Le pilote CSI n'utilise pas Vault Agent et ne dispose donc pas de ces fonctionnalités.
• L'opérateur Vault inclut la prise en charge de l'opérateur Promethus pour les rapports de gouvernance.
• Le pilote Vault CSI prend en charge le rendu des secrets Vault dans les secrets Kubernetes et les variables d'environnement. Sidecar Injector Service ne prend pas en charge le rendu des secrets dans les secrets Kubernetes, mais il existefaçons d'utiliser les modèles d'agentpour rendre les secrets dans les variables d'environnement.
• Le pilote CSI utilisehostPathpour monter des volumes éphémères dans les pods, que certaines plates-formes de conteneurs (par exemple OpenShift) désactivent par défaut. D'autre part, Sidecar Agent Service utilise en mémoiretmpfstomes.
• Service d'injecteur de side-carautomatiquementrenouvelle, tourne et récupère les secrets/jetons. Le pilote CSI ne prend pas cela en charge.

»Tableau de comparaison

Le tableau ci-dessous fournit une comparaison de haut niveau des trois solutions :

*obtenue parModèles d'agent

»Aller au-delà des secrets natifs de Kubernetes

À première vue, les secrets natifs de Kubernetes peuvent sembler similaires aux trois approches présentées ci-dessus, mais il existe des différences majeures entre elles :

• Kubernetes estpasune solution de gestion des secrets. Il a un support natif pour les secrets, mais c'est assez différent d'une solution de gestion des secrets d'entreprise. Les secrets Kubernetes sont limités au cluster uniquement et de nombreuses applications auront des services exécutés en dehors de Kubernetes ou dans différents clusters Kubernetes. Par conséquent, la prise en compte de la portée secrète dans le cadre du processus de conception est essentielle. Faire en sorte que ces applications utilisent des secrets Kubernetes depuis l'extérieur d'un environnement Kubernetes sera fastidieux et posera des problèmes d'authentification et d'autorisation.

• Les secrets Kubernetes sont de nature statique. Vous pouvez définir des secrets à l'aide de kubectl ou de l'API Kubernetes, mais une fois qu'ils sont définis, ils sont stockés dans etcd et présentés aux pods uniquement lors de la création du pod. Cela peut créer des scénarios dans lesquels les secrets deviennent obsolètes, obsolètes ou expirés, nécessitant des flux de travail supplémentaires pour mettre à jour et faire pivoter les secrets, puis redéployer l'application pour utiliser la nouvelle version des secrets. Cela peut ajouter de la complexité et perdre du temps. Assurez-vous donc de tenir compte de toute exigence de fraîcheur secrète, de mises à jour et de rotation dans le cadre de votre processus de conception.

• Le modèle de sécurité de la gestion des accès secrets est lié au modèle Kubernetes RBAC. Cela peut être difficile à adopter pour les utilisateurs qui ne sont pas familiers avec Kubernetes. L'adoption d'un modèle de gouvernance de la sécurité indépendant de la plate-forme peut vous permettre d'adopter des workflows pour les applications, quels que soient leur mode d'exécution et leur lieu d'exécution.

»Résumé

Concevoir pour la gestion des secrets dans Kubernetes n'est pas une tâche facile. Il existe plusieurs approches, chacune avec son propre ensemble d'avantages et d'inconvénients. Je vous recommande fortement d'explorer les options présentées dans ce billet de blog pour comprendre leur fonctionnement interne et décider de la meilleure option pour votre cas d'utilisation.

»Ressources additionnelles

• HashiCorp Vault : livrer des secrets avec Kubernetes
• Opérateur de coffre de secrets Kubernetes
• Référentiel d'opérateur de coffre-fort Kubernetes
• Récupérer les secrets du coffre HashiCorp avec Kubernetes CSI
• Monter les secrets du coffre-fort via le volume CSI (Container Storage Interface)
• Injecter des secrets dans des pods Kubernetes via des conteneurs Vault Agent
• Configurations et exemples d'injecteurs Vault Sidecar
• Configurations et exemples de pilotes Vault CSI