Où mettre le mot de passe du coffre-fort ansible

Nous prévoyons d'utiliser le coffre-fort ansible dans notre projet pour éviter les fuites de mots de passe ou de clés dans git.

L'idée est de mettre toutes nos données sensibles dans un fichier ordinaire puis de crypter ce fichier avec ansible-vault en utilisant un mot de passe avant de pousser vers git.

Pour décrypter le fichier, il faut passer le mot de passe du coffre-fort à ansible, je pense à 3 possibilités:

• Stockez-le dans une variable d'environnement de serveur
• Passez-le en option à la commande ansible-playbook
• Stockez-le dans un fichier non versionné.

Existe-t-il d'autres options, qui sont la meilleure façon (et sécurisée) de stocker le mot de passe ansible-vault, la documentation des meilleures pratiques ansible ne dit rien à ce sujet.

L'idée est de mettre toutes nos données sensibles [...]

La signification de «tous» dans cette phrase doit être analysée très attentivement avant de mettre en œuvre la solution que vous envisagez.

Le coffre-fort Ansible est un outil très utile, mais il ne doit être utilisé que pour stocker des secrets qui sont:

1. Spécifiquement nécessaire pour les déploiements ansibles
2. Inutilisable facilement pour les propriétaires qui ne devraient pas les connaître, mais qui peuvent se souvenir d'eux de manière illégale (généralement des employés hors-bord)

Le deuxième point est critique.

De nombreuses personnes, et potentiellement toute l'équipe DevOps, auront accès au mot de passe du coffre-fort ansible et donc à tous les secrets.

Par conséquent, pour tous les secrets stockés dans le coffre-fort, une condition doit être respectée pour laquelle une personne ou une machine avec un accès non autorisé à ceux-ci devrait être incapable de les utiliser si cela est souhaité.

Concrètement, si vous utilisez ansible pour déployer une base de données et ses utilisateurs, vous pouvez stocker les mots de passe dans le coffre-fort, mais vous devrez être très prudent (et probablement envisager une autre solution) si ce service sera disponible sur Internet. et sans avoir besoin d'authentification VPN!

Les utilisateurs (DevOps) exposés au secret devraient être incapables d'utiliser des mots de passe "mémorisés" si une barrière de sécurité leur est imposée (par exemple, l'accès VPN révoqué). En plus de cela, l'accès au référentiel de code source (où le coffre-fort est stocké) doit également être révoqué avant de changer les mots de passe.

Dans ces conditions, ansible vault est un outil très utile.

Essayer de stocker un secret qui pourrait être utilisé par n'importe quelle personne ou machine sur Internet dans le coffre-fort serait plutôt une erreur (par exemple, les informations d'identification VPN des utilisateurs).

Existe-t-il d'autres options, qui sont la meilleure façon (et sécurisée) de stocker le mot de passe du coffre-fort ansible

Dans les conditions du paragraphe précédent, je pense qu'une bonne pratique serait:

1. Stockez le mot de passe du coffre-fort dans un coffre-fort sécurisé externe (quelque chose comme Vault de HashiCorp ou tout SaaS pour la gestion des informations d'identification)
2. Autoriser l'accès à l'élément de coffre externe à DevOps (ils auront besoin du mot de passe pour les tests) et au système CI / CD ou au contrôleur ansible

3. Gardez une convention pour utiliser des secrets ! Vous ne pourrez pas consulter les modifications apportées aux secrets et vous ne pourrez pas rechercher les variables ansibles dans les fichiers secrets! Soyez donc minutieux depuis le début. Une bonne convention consiste à nommer toutes les variables stockées dans le coffre-fort ansible avec un secret_préfixe. Quand vous verrez quelque chose comme:

   postgres.yml:

   postgres_password: "{{ secret_postgres_password }}"
   

   vous saurez que la valeur est stockée dans le coffre-fort ansible.

Nous prévoyons d'utiliser le coffre-fort ansible dans notre projet pour éviter les fuites de mots de passe ou de clés dans git.

Comme vous n'avez encore rien implémenté, vous pouvez reconsidérer cela. L'utilisation d'un système comme Ansible vault présente un certain nombre d'inconvénients de sécurité:

• il n'y a pas de piste d'audit pour savoir qui y a accédé
• quand un employé part, il est facile pour lui de prendre le magasin secret avec lui
• lorsqu'un employé quitte, supprimer son accès signifie changer le mot de passe et le redistribuer à tout le monde
• un mot de passe de coffre-fort Ansible compromis peut être utilisé pour toujours sur une ancienne version du coffre-fort, tel que stocké dans le contrôle de version
• les secrets doivent être statiques

Un système potentiellement beaucoup plus sécurisé, bien que plus complexe, qui ne présente pas ces inconvénients consiste à utiliser Hashicorp Vault pour stocker vos secrets. Vous pouvez ensuite en extraire des valeurs presque aussi facilement que depuis le coffre-fort Ansible en utilisant https://github.com/jhaals/ansible-vault .

Vous devez ensuite gérer l'authentification auprès de Hashicorp Vault, et c'est la question des tortues . Pour les humains, je pense que la meilleure solution consiste à demander périodiquement un mot de passe et à expirer le jeton après un court laps de temps; pour les machines, pour utiliser le backend d'authentification AWS ou similaire. Vous ne pouvez jamais vous débarrasser entièrement du besoin d'authentification quelque part, mais vous pouvez rendre plus difficile pour un attaquant d'y accéder.

Maintenant, si configurer et administrer un serveur de secrets est trop pour vous, alors vous pouvez certainement utiliser le coffre-fort Ansible. Mais pourquoi stocker le mot de passe sur les machines individuelles? Pour une utilisation interactive, vous pouvez simplement demander le mot de passe et les utilisateurs peuvent le stocker dans le gestionnaire de mots de passe de leur choix. iTerm sur OS X dispose d'un gestionnaire de mots de passe qui s'intègre à Keychain.app qui rend cela particulièrement facile là-bas.

Cela dépend en grande partie des politiques internes que vous avez sur le traitement des données sensibles.

J'aimerais vous expliquer mon approche et expliquer ce que je considère comme des avantages et des inconvénients. Je garde le mot de passe Ansible Vault dans un fichier sur la machine de contrôle et j'ai une variable d'environnement pointant dessus:

export ANSIBLE_VAULT_PASSWORD_FILE=/deep/dark/place

Je l'ai sur mon poste de travail (car j'ai besoin de tester et de développer des playbooks), certains collègues l'ont aussi, et bien sûr nous l'avons sur la machine de contrôle Ansible principale.

Avantages:

• pas dans un emplacement / référentiel partagé (c'est un fichier non versionné comme vous le dites)
• on n'a pas besoin de connaître votre mot de passe de coffre Ansible pour exécuter une lecture (c'est à la condition que vous ayez un outil CI, par exemple Jenkins, où vous pouvez facilement lancer des playbooks)

Les inconvénients:

• pas facile de faire tourner le mot de passe
• tous ceux qui travaillent sur vos playbooks doivent l'avoir sur son poste de travail

Les inconvénients ont des atténuations, mais encore une fois, cela dépend des politiques et des règles que vous avez adoptées dans vos opérations quotidiennes.

Jetez un oeil sur ce projet pour gérer vos mots de passe de cryptage du coffre-fort ansible https://github.com/Smile-SA/ansible-vault-manager

Il gère plusieurs plates-formes de stockage de clés avec des plugins (pour l'instant, seul AWS SSM est implémenté). De plus, l'intégration avec un projet Ansible en cours est très facile ...