Wo man das Passwort für ansible-vault ablegt


24

Wir planen, in unserem Projekt einen anonymen Tresor zu verwenden, um zu verhindern, dass Passwörter oder Schlüssel in git verloren gehen.

Die Idee ist, alle unsere sensiblen Daten in eine einfache Datei zu packen und diese Datei mit einem Passwort mit ansible-vault zu verschlüsseln, bevor Sie zu git gehen.

Um die Datei zu entschlüsseln, müssen wir das Tresorkennwort an ansible übergeben. Ich denke über drei Möglichkeiten nach:

  • Speichern Sie es in einer Server-Umgebungsvariablen
  • Übergeben Sie es als Option an den Befehl ansible-playbook
  • Speichern Sie es in einer nicht versionierten Datei.

Gibt es noch andere Optionen, die die beste (und sicherste) Möglichkeit zum Speichern von Ansible-Vault-Kennwörtern darstellen? In der Dokumentation zu Ansible-Best Practices wird hierzu nichts gesagt.



Es gibt einige gute Antworten hier: devops.stackexchange.com/questions/3806/...
Vish

Antworten:


12

Die Idee ist, alle unsere sensiblen Daten [...]

Die Bedeutung von "all" in diesem Satz sollte sehr sorgfältig analysiert werden, bevor Sie die von Ihnen geplante Lösung implementieren.

Ansible Vault ist ein sehr nützliches Tool, das jedoch nur zum Speichern der folgenden Geheimnisse verwendet werden sollte:

  1. Speziell für die ansible Bereitstellungen benötigt
  2. Für Eigentümer, die sich ihrer nicht bewusst werden sollten, leicht unbrauchbar gemacht, die sich jedoch möglicherweise unrechtmäßig an sie "erinnern" (in der Regel Mitarbeiter außerhalb des Büros)

Der zweite Punkt ist kritisch.

Viele Menschen und möglicherweise das gesamte DevOps-Team haben Zugriff auf das gültige Tresorkennwort und damit auf alle Geheimnisse.

Daher sollte für alle im Tresor aufbewahrten Geheimnisse eine Bedingung gelten, für die eine Person oder Maschine mit unbefugtem Zugriff nicht in der Lage sein sollte, sie zu verwenden, wenn dies gewünscht wird.

Konkret ausgedrückt, wenn Sie eine Datenbank und ihre Benutzer mit ansible bereitstellen, können Sie die Kennwörter im Tresor speichern. Sie müssen jedoch sehr vorsichtig sein (und überlegen höchstwahrscheinlich eine andere Lösung), wenn dieser Dienst über das Internet verfügbar sein wird und ohne VPN-Authentifizierung!

Benutzer (DevOps), die dem Geheimnis ausgesetzt sind, sollten nicht in der Lage sein, "gespeicherte" Kennwörter zu verwenden, wenn ihnen eine Sicherheitsbarriere auferlegt wird (z. B. VPN-Zugriff widerrufen). Darüber hinaus sollte der Zugriff auf das Quellcode-Repository (in dem der Tresor gespeichert ist) ebenfalls widerrufen werden, bevor Kennwörter geändert werden.

Unter diesen Umständen ist ein anzeigbarer Tresor ein sehr nützliches Werkzeug.

Der Versuch, ein Geheimnis zu speichern, das von einer beliebigen Person oder Maschine im Internet im Tresor verwendet werden könnte, wäre stattdessen ein Fehler (z. B. VPN-Anmeldeinformationen von Benutzern).

Gibt es noch andere Optionen, die die beste (und sicherste) Möglichkeit zum Speichern eines anzeigbaren Tresorkennworts darstellen?

Unter den Bedingungen aus dem vorherigen Absatz denke ich, dass eine gute Praxis wäre:

  1. Speichern Sie das Tresorkennwort in einem externen sicheren Tresor (etwa in einem Tresor von HashiCorp oder einem beliebigen SaaS für die Verwaltung von Anmeldeinformationen).
  2. Ermöglichen Sie DevOps den Zugriff auf das externe Tresorelement (zum Testen benötigen sie das Kennwort) und auf das CI / CD-System oder den ansiblen Controller
  3. Halten Sie eine Konvention ein, um Geheimnisse zu nutzen ! Sie können Änderungen an den Geheimnissen nicht überprüfen und Sie können nicht nach ansiblen Variablen in Geheimnisdateien suchen! Sei also von Anfang an gründlich. Eine gute Konvention ist es, alle Variablen, die im ansiblen Tresor gespeichert sind, mit einem secret_Präfix zu benennen . Wann sehen Sie so etwas wie:

    postgres.yml:

    postgres_password: "{{ secret_postgres_password }}"
    

    Sie werden wissen, dass der Wert im ansiblen Tresor gespeichert ist.


Guter Punkt zum Speichern des Ansible Vault-Kennworts an einem sichereren Ort (HashiCorp Vault oder SaaS Vault wie AWS Secrets Manager). Es muss jedoch immer noch gedreht (geändert) werden, wenn jemand das Team verlässt, da er selbst kurzzeitig Zugriff darauf hatte. Dies kann möglicherweise durch die Verwendung separater Tresore (dev, test, production), dh durch die Geheimhaltung von Dateien in YAML, gemildert werden. Mit Ansible 2.4+ können Sie auch unterschiedliche Kennwörter für solche Dateien mithilfe einer 'Tresor-ID'
festlegen

Ansible 2.3 hat eine Funktion eingeführt, die nur die Werte in YAML-Dateien und nicht die gesamte Datei verschlüsselt. Diese Funktion ist einfacher zu verwalten als die ältere Konvention, die Sie in Punkt 3 am Ende dieser Antwort erwähnt haben.
RichVel

6

Wir planen, in unserem Projekt einen anonymen Tresor zu verwenden, um zu verhindern, dass Passwörter oder Schlüssel in git verloren gehen.

Da Sie noch nichts implementiert haben, überdenken Sie dies möglicherweise erneut. Die Verwendung eines Systems wie Ansible Vault hat eine Reihe von Sicherheitsmängeln:

  • Es gibt keinen Prüfpfad darüber, wer darauf zugegriffen hat
  • Wenn ein Mitarbeiter das Unternehmen verlässt, ist es für ihn einfach, den geheimen Laden mitzunehmen
  • Wenn ein Mitarbeiter das Unternehmen verlässt, bedeutet das Entfernen seines Zugriffs, dass das Kennwort geändert und an alle anderen Personen weitergegeben wird
  • Ein kompromittiertes Ansible-Tresorkennwort kann für immer in einer alten Version des Tresors verwendet werden, die in der Versionskontrolle gespeichert ist
  • Geheimnisse müssen statisch sein

Ein potenziell viel sichereres, wenn auch komplexeres System, das diese Nachteile nicht aufweist, ist die Verwendung von Hashicorp Vault zum Speichern Ihrer Geheimnisse. Mit https://github.com/jhaals/ansible-vault können Sie dann fast genauso einfach Werte daraus abrufen wie aus Ansible Vault .

Sie müssen dann die Authentifizierung für Hashicorp Vault verwalten, und das ist die Turtle-Frage . Für Menschen ist es meiner Meinung nach die beste Lösung, regelmäßig nach einem Passwort zu fragen und das Token nach kurzer Zeit ungültig zu machen. für Maschinen, um das AWS-Authentifizierungs-Backend oder ähnliches zu verwenden. Sie können das Erfordernis der Authentifizierung an einem Ort nie ganz beseitigen, aber Sie können es einem Angreifer erschweren, Zugriff darauf zu erhalten.

Wenn Ihnen das Einrichten und Verwalten eines geheimen Servers zu viel ist, können Sie mit Sicherheit nur Ansible Vault verwenden. Warum sollte das Passwort überhaupt auf den einzelnen Rechnern gespeichert werden? Für die interaktive Verwendung müssen Sie nur das Kennwort eingeben, und die Benutzer können es in dem Kennwortmanager ihrer Wahl speichern. iTerm unter OS X verfügt über einen Kennwort-Manager, der in Keychain.app integriert ist, was dies dort besonders einfach macht.


1
Der beste Weg, ansible Vault zu verwenden, ist, es nicht zu verwenden. Vielen Dank, dass Sie darauf hingewiesen haben!
Sturm

Für kleine bis mittlere Unternehmen würde ich empfehlen, sich einen Cloud-basierten Secrets Manager wie AWS Secrets Manager anzusehen. Dies ist weitaus weniger arbeitsaufwendig als das Ausführen eines hochverfügbaren Clusters für HashiCorp Vault, aber eine große Verbesserung der Sicherheit, die Sie mit Ansible erhalten Tresor, einschließlich Überwachung und granulare Zugriffskontrolle. Natürlich sind Sie am Ende von diesem Dienst abhängig, aber das kann mit etwas App-Codierung und Ansible-Arbeit gekapselt werden. Der Hauptvorteil ist, dass einige Geheimnisse überhaupt nicht von Ansible verwaltet werden müssen, z. B. DB-Passwörter. Lassen Sie die App einfach vor dem Geheimnisse-Manager geheim.
RichVel

3

Dies hängt weitgehend mit den internen Richtlinien zum Umgang mit vertraulichen Daten zusammen.

Ich möchte Ihnen meinen Ansatz dazu erläutern und erklären, was ich als Vor- und Nachteile sehe. Ich behalte das Ansible Vault-Kennwort in einer Datei auf dem Steuerungscomputer und habe eine Umgebungsvariable, die darauf verweist:

export ANSIBLE_VAULT_PASSWORD_FILE=/deep/dark/place

Ich habe das auf meiner Workstation (da ich Playbooks testen und entwickeln muss), einige Kollegen haben es auch, und natürlich haben wir es auf der Ansible-Hauptsteuerungsmaschine.

Vorteile:

  • nicht in einem freigegebenen Speicherort / Repository (es ist eine nicht versionierte Datei, wie Sie sagen)
  • Man muss das Ansible-Tresorkennwort nicht kennen, um ein Spiel zu starten.

Nachteile:

  • nicht einfach, das Passwort zu drehen
  • Jeder, der an Ihren Playbooks arbeitet, muss diese auf seiner Workstation haben

Die Nachteile haben Milderungen, aber es liegt wieder an den Richtlinien und Regeln, die Sie in Ihrem täglichen Betrieb übernommen haben.


1
Schöne Kombination .. überprüfen Sie die andere Antwort, obwohl es für Sie von Interesse sein kann.
Sturm

0

Schauen Sie sich dieses Projekt an, um Ihre Passwörter für die ansible Vault-Verschlüsselung zu verwalten: https://github.com/Smile-SA/ansible-vault-manager

Es können mehrere Schlüsselbundspeicherplattformen mit Plug-ins verwaltet werden (derzeit nur AWS SSM implementiert). Die Integration in ein aktuelles Ansible-Projekt ist sehr einfach ...


Es wäre hilfreich, wenn Sie das Einfachere konkreter machen, anstatt etwas Allgemeines hinzuzufügen. Ich habe die README-Datei der Github-Seite gelesen, aber können Sie die Antwort so ändern, dass sie ein klares Beispiel enthält? Ich würde es gerne probieren.
030
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.