Lorsque vous utilisez la fonction de sac de données chiffrées pour Chef, comment procédez-vous pour déployer la clé sur de nombreux serveurs? Si vous l'introduisez dans une recette, toute personne ayant accès à l'un des serveurs ou clients du chef peut tirer la clé et potentiellement décrypter n'importe quel sac de données.
Comment pouvez-vous vous assurer que la clé se trouve sur les machines qui en ont besoin, mais également à l'abri de quiconque fouine?
Réponses:
Malheureusement, vous ne pouvez pas vraiment faire grand-chose, car la clé doit se trouver quelque part sur le nœud Chef en texte brut. Si quelqu'un a un accès shell ou local à la boîte, il peut être possible pour lui de lire la ou les clés.
Pour atténuer un peu les choses, j'ajoute ce qui suit à mon noeud de base (c'est-à-dire une recette ou un rôle commun à tous les noeuds):
directory "/etc/chef/keys" do
mode 0700
owner "root"
group "root"
end
et quel que soit le mécanisme de distribution de clés que vous avez, il place les clés à cet endroit. Les autorisations et la propriété empêchent la lecture des clés si quelqu'un oublie de placer les autorisations appropriées sur un fichier de clés.
Comme je le vois, les sacs de données chiffrés visent davantage à protéger le matériel clé contre la lecture dans un système de contrôle de source, et moins en tant que fonctionnalité de sécurité sur les nœuds Chef eux-mêmes.
Mes EDB sont séparés par:
Nous téléchargeons toutes les clés avec un suffixe spécial dans chaque nouvelle instance EC2 au fur et à mesure que nous l'amorçons, puis supprimons toutes les clés qui n'ont été utilisées par aucune des recettes de la run_list à la fin des premières exécutions chef-client (qui seront juste au début de l'instance.)
Tous les fichiers sont téléchargés en tant que propriétaire et groupe "root" et avec uniquement des autorisations de lecture.
Chaque recette qui utilise un EDB, génère le nom de l'EDB et le nom du fichier de clé au moment de l'exécution de la recette en concaténant 'edb_' + l'environnement des nœuds + le nom spécifique à la recette / à l'élément + '.key', puis recherche la clé par ce nom . (S'il n'existe pas, cela déclenche une exception par défaut.)
Ainsi, pour notre serveur couchdb, exécutant un rôle appelé «couch», pour obtenir les informations d'identification que nous utilisons pour les utilisateurs admins dans l'environnement de développement, la recette recherche une clé nommée «edb_dev_couch.key»
Il recherche ensuite dans un sac de données nommé «edb_dev» un élément nommé «couch_credentials».
Pour la gestion des clés, j'utilise actuellement l'approche simple de:
Espérons que cela limite le temps pendant lequel les clés en dehors de la portée d'un nœud unique sont susceptibles jusqu'à ce que la machine ait été amorcée et ait exécuté la première exécution de chef_client.
Il s'agit de notre première série de tests sur la façon de sécuriser les clés, mais jusqu'à présent, il répond à nos besoins actuels car il empêche un serveur de développement enraciné d'être en mesure d'accéder immédiatement à toutes les autres informations d'identification de serveur stockées dans un EDB.
Pour conserver une recette à la fin de chaque liste d'exécution, j'utilise un travail d'exécution de couteau qui s'assure que cette recette delete_keys est exactement la dernière recette sur chaque nœud.
Mes clés sont intégrées dans les AMI que nous utilisons ou les images que nous utilisons. Je ne le fais pas dans le cadre du bootstrap car ces données ne sont pas sécurisées. Vous pouvez généralement voir les données dans les journaux et autres si vous ne faites pas attention.