Quelle est la meilleure pratique pour stocker les mots de passe et les clés API avec Chef ? Il est très tentant de stocker les mots de passe des bases de données, les clés API AWS et d'autres informations d'identification sensibles en tant qu'attributs du serveur Chef pour les utiliser dans les recettes, mais qu'en est-il des considérations de sécurité ? Quelle est la meilleure pratique en la matière ?
Réponses
Trop de publicités?D'après le canal IRC #chef, de nombreuses personnes stockent ce type de données dans un sac de données sur le serveur chef.
Par exemple, un sac de données pourrait être "aws", avec un élément "main", faisant référence au compte AWS principal. Des clés séparées dans l'élément seraient pour chaque valeur particulière. Par exemple :
{
"id": "main",
"aws_secret_key": "The secret access key",
"aws_access_key": "The access key"
}
Vous pouvez également être intéressé par sacs de données cryptées . Je les ai décrits plus en détail pour la gestion authentification SASL de postfix .
Mise à jour : J'ai écrit des articles de blog sur Chef Vault sur mon blog y sysadvent .
Cette question est ancienne et n'a pas de réponse acceptée, cependant, la réponse correcte à cette question est que Chef permet l'utilisation de Sacs de données cryptées pour le stockage de données sensibles dans Sacs de données .
Chef Encrypted data_bags est en effet une solution légitime. En outre, vous pouvez également utiliser un Gem ruby qui vous permet de crypter un élément de sac de données Chef en utilisant les clés publiques d'une liste de nœuds Chef. Cela permet uniquement à ces nœuds de chef de décrypter les valeurs cryptées. cf. https://github.com/Nordstrom/chef-vault
Chef Vault peut être un bon choix. Il fournit une interface simple pour le stockage de données cryptées sur le serveur chef, la gestion des accès. Télécharger, modifier, mettre à jour les données avec knife vault ...
des commandes.
Pour obtenir les données d'une recette, utilisez ChefVault::Item.load
commande
chef_gem "chef-vault"
require 'chef-vault'
item = ChefVault::Item.load("passwords", "root")
item["password"]
Pour définir les utilisateurs qui peuvent mettre à jour les données, utilisez le couteau. vault_admins
propriété.
knife[:vault_admins] = [ 'example-alice', 'example-bob', 'example-carol' ]
Je n'ai jamais essayé les sacs de données, mais c'est probablement parce que je trouve tout ce qui est à part chef-solo un peu trop compliqué. C'est pourquoi j'utilise les recettes de chef avec un service appelé Scalarium .
La question des mots de passe, ou par exemple des clés privées et de toutes sortes d'autres informations d'identification, est donc assez difficile. J'ai moi aussi un certain nombre de recettes pour lesquelles des mots de passe doivent être créés ou définis correctement.
En général, ce que je fais, c'est que je spécifie ce que les gens du scalarium appellent json personnalisé . Ce json est similaire au node.json
certaines personnes donnent à chef-solo en utilisant chef-solo -j node.json
.
Ainsi, par exemple, dans mon json personnalisé sur l'interface web de Scalarium, j'ai ce qui suit :
{"super_secure_password":"foobar"}
Ce que ça fait, c'est que mon mot de passe super sécurisé est disponible pendant mon exécution du chef dans node[:super_secure_password]
et je peux l'utiliser dans des recettes ou des modèles.
Cela fonctionne bien tant que je ne déploie mon serveur qu'en utilisant Scalarium, mais nous utilisons également nos recettes dans des boîtes vagrant locales pour un environnement de développement et des tests plus faciles. Et lorsque j'utilise vagrant (ou même chef-solo par lui-même), je n'ai pas accès à l'interface de l'application json personnalisé sur Scalarium.
Voici ce que je fais pour résoudre ce problème, en my_recipe/attributes/default
:
set_unless[:super_secure_password] = "test123"
Cela signifie que lorsque ma recette est exécutée en dehors de scalarium, le mot de passe est toujours disponible dans le fichier node[:super_secure_password]
et mes recettes fonctionnent et ainsi de suite. Lorsque la recette est exécutée dans le contexte de scalarium, elle ne remplacera pas ce qu'ils fournissent.