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

26

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.

orage
la source
Discussion très pertinente: danielsomerfield.github.io/turtles
Xiong Chiamiov
Il y a de bonnes réponses ici: devops.stackexchange.com/questions/3806/…
Vish

Réponses:

13

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.

Vincenzo Pii
la source
1
Bon point sur le stockage du mot de passe Ansible Vault dans un endroit plus sécurisé (HashiCorp Vault ou coffre-fort SaaS comme AWS Secrets Manager). Cependant, il doit encore être tourné (changé) si quelqu'un quitte l'équipe, car il y a eu accès même brièvement. Cela peut être atténué peut-être en utilisant des coffres-forts distincts (dev, test, production), c'est-à-dire des fichiers secrets dans YAML. Ansible 2.4+ vous permet également de spécifier différents mots de passe pour ces fichiers à l'aide d'un «ID de coffre-fort» - page docs
RichVel
1
Ansible 2.3 a introduit une fonctionnalité qui chiffre uniquement les valeurs des fichiers YAML, pas le fichier entier - c'est plus simple à maintenir que l'ancienne convention que vous mentionnez au point 3 à la fin de cette réponse.
RichVel
7

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.

Xiong Chiamiov
la source
2
La meilleure façon d'utiliser le coffre-fort ansible est de ne pas l'utiliser .. Merci de l'avoir signalé!
tempête
1
Pour les petites et moyennes organisations, je recommanderais de regarder un gestionnaire de secrets basé sur le cloud comme AWS Secrets Manager - c'est beaucoup moins de travail que d'exécuter un cluster hautement disponible pour HashiCorp Vault, mais une grande amélioration de la sécurité que vous obtenez avec Ansible Vault, y compris l'audit et le contrôle d'accès granulaire. Bien sûr, vous finissez par dépendre de ce service, mais cela peut être encapsulé avec du codage d'application et du travail Ansible. Le principal avantage est que certains secrets n'ont pas du tout besoin d'être gérés par Ansible, par exemple les mots de passe de base de données - laissez simplement l'application obtenir le secret du gestionnaire de secrets.
RichVel
3

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.

13dimitar
la source
1
Nice combinaison .. vérifiez l'autre réponse bien qu'elle puisse vous intéresser.
tempête
0

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 ...

Gillg
la source
Il serait utile que vous rendiez le plus simple et plus concret plutôt que d'ajouter quelque chose de générique. J'ai lu le LISEZMOI de la page github, mais pourriez-vous changer la réponse pour qu'elle contienne un exemple clair? Je voudrais l'essayer.
030