Remplissage de conteneurs Docker avec des informations sensibles à l'aide de kubernetes

Question

J'ai un pod qui exécute des conteneurs qui nécessitent l'accès à des informations sensibles telles que les clés API et les mots de passe DB. En ce moment, ces valeurs sensibles sont intégrées dans les définitions de contrôleur comme ceci:

env: 
- name: DB_PASSWORD 
    value: password 

qui sont alors disponibles à l'intérieur du conteneur Docker comme la variable d'environnement $DB_PASSWORD. Tout est assez facile. Mais en lisant leur documentation sur Secrets, ils disent explicitement que mettre des valeurs de configuration sensibles dans votre définition viole les meilleures pratiques et est potentiellement un problème de sécurité. La seule autre stratégie que je peux penser est la suivante:

• créer une clé OpenPGP par la communauté des utilisateurs ou espace de noms
• utilisation crypt pour définir la valeur de configuration dans ETCD (qui est crypté avec la clé privée)
• créer un secret Kubernetes contenant la clé privée, like so
• associé ce secret avec le conteneur (ce qui signifie que la clé privée sera accessible en tant que volume de montage), like so
• lorsque le récipient i s lancé, il accédera au fichier à l'intérieur du montage de volume pour la clé privée, et l'utilisera pour décrypter les valeurs de conf retournées par etcd
• cela peut alors être incorporé dans confd, qui remplit les fichiers locaux selon une définition de modèle (tel comme fichiers de configuration Apache ou WordPress)

Cela semble assez compliqué, mais plus sûr et flexible, car les valeurs ne seront plus statiques et stockées en clair.

Donc, ma question, et je sais que ce n'est pas entièrement objectif, est de savoir si c'est absolument nécessaire ou non? Seuls les administrateurs seront en mesure d'afficher et d'exécuter les définitions RC en premier lieu; donc si quelqu'un a violé le maître des kubernetes, vous avez d'autres problèmes à vous inquiéter. Le seul avantage que je vois est qu'il n'y a aucun danger que des secrets soient commis dans le système de fichiers en texte clair ...

Existe-t-il d'autres façons de remplir de manière sécurisée les conteneurs Docker avec des informations secrètes?

Answer 1

À moins d'avoir plusieurs mégaoctets de configuration, ce système semble inutilement complexe. L'utilisation prévue est pour vous de mettre chaque config dans un secret, et les pods ayant besoin de la config peuvent monter ce secret en tant que volume.

Vous pouvez ensuite utiliser un certain nombre de mécanismes pour transmettre cette configuration à votre tâche, par ex. si c'est des variables d'environnement source secret/config.sh; ./mybinary est un moyen simple.

Je ne pense pas que vous gagnez une sécurité supplémentaire en stockant une clé privée comme un secret.

Answer 2

Je me déciderais personnellement à utiliser un gestionnaire de clés distant auquel votre logiciel pourrait accéder sur le réseau via une connexion HTTPS. Par exemple, Keywhiz ou Vault correspondrait probablement à l'addition.

Je voudrais héberger le gestionnaire de clés sur un sous-réseau isolé distinct, et configurer pare-feu pour autoriser uniquement l'accès aux adresses IP dont je pensais avoir besoin les clés.KeyWhiz et Vault sont livrés avec un mécanisme ACL, vous n'avez donc pas à faire quoi que ce soit avec des pare-feu, mais cela ne fait pas de mal de les considérer. Cependant, la clé ici est d'héberger le gestionnaire de clés sur un réseau séparé. un fournisseur d'hébergement séparé. Votre fichier de configuration local dans le conteneur ne contient que l'URL du service de clé, et éventuellement des informations d'identification pour récupérer la clé auprès du gestionnaire de clés - les informations d'identification seraient inutiles pour un attaquant s'il ne correspondait pas à la liste de contrôle d'accès/Adresses IP.