Frage Wie kann ich Ansible mit Passwörtern pro Host sicher implementieren?


Ich würde gerne verwenden ansible um eine Gruppe bestehender Server zu verwalten. Ich habe eine erstellt ansible_hosts Datei, und erfolgreich getestet (mit der -K Option) mit Befehlen, die nur auf einen einzelnen Host abzielen

ansible -i ansible_hosts host1 --sudo -K # + commands ...

Mein Problem ist jetzt, dass die Benutzerpasswörter auf jedem Host unterschiedlich sind, aber ich kann keinen Weg finden, dies in Ansible zu handhaben.

Verwenden -KIch werde nur zur Eingabe eines einzelnen sudo-Passworts aufgefordert, das dann für alle nachfolgenden Hosts ohne Aufforderung auszuprobieren scheint:

host1 | ...
host2 | FAILED => Incorrect sudo password
host3 | FAILED => Incorrect sudo password
host4 | FAILED => Incorrect sudo password
host5 | FAILED => Incorrect sudo password

Bisherige Forschung:

  • ein StackOverflow-Frage mit einer falschen Antwort ("benutzen -K") und eine Antwort des Autors, die sagte:" Ich habe herausgefunden, dass ich Passwortless Sudo brauchte "

  • die Ansible-Dokumente, die sagen: "Die Verwendung von passwordless sudo macht es einfacher zu automatisieren, aber es ist nicht erforderlich. "(Hervorhebung von mir)

  • Diese Sicherheitsfrage für StackExchange was liest man so NOPASSWD Wird benötigt

  • Artikel "Skalierbare und verständliche Bereitstellung ..." was sagt:

    "Das Ausführen von sudo erfordert möglicherweise die Eingabe eines Passworts. Dies ist eine sichere Methode, um Ansible für immer zu blockieren. Eine einfache Lösung besteht darin, visudo auf dem Zielhost auszuführen und sicherzustellen, dass der Benutzer Ansible zum Anmelden verwendet und kein Passwort eingeben muss."

  • Artikel "Einfache Ansible Playbooks", was sagt

    "Ansible konnte sich als root am Zielserver anmelden und die Notwendigkeit von sudo vermeiden, oder dem ansiblen Benutzer sudo ohne Passwort erlauben, aber der Gedanke, dies zu tun, lässt meine Milz drohen, meinen Schlund hochzuspringen und meine Luftröhre zu blockieren, also ich nicht "

    Meine Gedanken genau, aber dann wie man sich über einen einzelnen Server hinaus erstreckt?

  • ansible Ausgabe # 1227"Ansible sollte nach sudo Passwort für alle Benutzer in einem Playbook fragen", das vor einem Jahr von mpdehaan mit dem Kommentar geschlossen wurde. "Habe nicht viel Nachfrage dafür gesehen. Ich glaube, die meisten Leute sudoing von nur einem Benutzerkonto oder verwenden Schlüssel die meiste Zeit. "

Also ... wie benutzen Leute Ansible in solchen Situationen? Rahmen NOPASSWD im /etc/sudoersdie Wiederverwendung des Passworts über Hosts oder die Aktivierung des Root-SSH-Logins scheinen allesamt drastische Sicherheitseinbußen zu verursachen.


97
2017-12-09 11:49


Ursprung


Gibt es einen Grund, warum Sie keine SSH-Schlüssel verwenden? - Trondh
Ich verwende bereits SSH-Schlüssel; sie beeinflussen nicht sudo (was immer noch ein Passwort erfordern sollte). - supervacuo
Dies ist vielleicht nicht genau das, wonach Sie suchen, aber auf Ubuntu-Boxen benutze ich immer noch Schlüssel, d. H. Setze meinen öffentlichen Schlüssel in / root / authorized_keys, um direkt als root einzusteigen. Offensichtlicher Nachteil ist erlaubt Root-Logins über SSH ... Ich verbieten auch Passwort Logins über SSH und fail2ban für zusätzliche Sicherheit. - senorsmile
@senorsmile danke für die Antwort! Würde es Ihnen etwas ausmachen, stattdessen eine Antwort zu geben, damit ich Sie ablehnen kann, weil ich die Frage nicht gelesen habe? - supervacuo
d.h. das ansible_ssh_password Einstellung gilt nur für das SSH-Passwort (der Hinweis ist im Namen ...). & Ich verwende bereits eine schlüsselbasierte SSH-Anmeldung. - supervacuo


Antworten:


Sie haben sicherlich Ihre Forschung getan ...

Aus all meinen Erfahrungen mit Ansible, was Sie erreichen möchten, wird nicht unterstützt. Wie Sie erwähnt haben, gibt ansible an, dass es kein Passwortless-Sudo erfordert, und Sie haben Recht, es tut es nicht. Aber ich habe noch keine Methode gesehen, mehrere sudo-Passwörter in ansible zu verwenden, ohne natürlich mehrere configs auszuführen.

Also, ich kann nicht die genaue Lösung anbieten, nach der Sie suchen, aber Sie haben gefragt ...

"Also ... wie benutzen die Leute Ansible in solchen Situationen?   NOPASSWD in / etc / sudoers, Wiederverwendung des Passworts auf Hosts oder Aktivierung   root SSH Login alle scheinen eher drastische Sicherheitseinbußen. "

Ich kann Ihnen einen Überblick geben. Mein Anwendungsfall sind 1-k-Knoten in mehreren Datenzentren, die eine globale SaaS-Firma unterstützen, in der ich aufgrund der Art unseres Geschäfts einige wahnsinnig strenge Sicherheitskontrollen entwerfen / implementieren muss. Sicherheit ist immer Balanceakt, mehr Benutzerfreundlichkeit, weniger Sicherheit, dieser Prozess ist nicht anders, wenn Sie 10 Server oder 1.000 oder 100.000 laufen.

Sie sind absolut richtig, root-Logins nicht entweder über Passwort oder SSH-Schlüssel zu verwenden. In der Tat sollte die root-Anmeldung vollständig deaktiviert werden, wenn an die Server ein Netzwerkkabel angeschlossen ist.

Können wir in einem großen Unternehmen über die Wiederverwendung von Kennwörtern sprechen? Ist es sinnvoll, Systemadministratoren zu bitten, auf jedem Knoten unterschiedliche Kennwörter zu verwenden? für ein paar Knoten, vielleicht, aber meine Admins / Ingenieure würden meutern, wenn sie unterschiedliche Passwörter auf 1000 Knoten haben müssten. Die Implementierung wäre auch nahezu unmöglich, jeder Benutzer müsste irgendwo seine eigenen Passwörter speichern, hoffentlich ein Schlüsselpass, keine Tabellenkalkulation. Und jedes Mal, wenn Sie ein Passwort an einem Ort ablegen, an dem es im Klartext herausgezogen werden kann, haben Sie Ihre Sicherheit stark verringert. Ich würde viel lieber wissen, dass sie ein oder zwei wirklich starke Passwörter auswendig kennen, als jedes Mal, wenn sie sich auf einem Rechner anmelden oder Sudo aufrufen müssen, eine Schlüsselpassdatei konsultieren müssen.

Daher ist die Passwortwiederherstellung und Standardisierung selbst in einer sicheren Umgebung völlig akzeptabel und Standard. Andernfalls müssten ldap, keystone und andere Verzeichnisdienste nicht existieren.

Wenn wir uns zu automatisierten Benutzern bewegen, funktionieren SSH-Schlüssel sehr gut, um Sie einzubinden, aber Sie müssen immer noch durch Sudo kommen. Ihre Auswahlmöglichkeiten sind ein standardisiertes Passwort für den automatisierten Benutzer (was in vielen Fällen akzeptabel ist) oder um NOPASSWD zu aktivieren, wie Sie bereits erwähnt haben. Die meisten automatisierten Benutzer führen nur ein paar Befehle aus, daher ist es durchaus möglich und sicherlich wünschenswert, NOPASSWD zu aktivieren, aber nur für vorab genehmigte Befehle. Ich würde vorschlagen, Ihre Konfigurationsverwaltung (in diesem Fall möglich) zu verwenden, um Ihre sudoers-Datei zu verwalten, so dass Sie die Liste der kennwortlosen Befehle problemlos aktualisieren können.

Jetzt gibt es einige Schritte, die Sie ergreifen können, sobald Sie mit der Skalierung beginnen, um das Risiko weiter zu isolieren. Während wir etwa 1000 Knoten haben, sind nicht alle "Produktions" -Server, einige sind Testumgebungen usw. Nicht alle Administratoren können auf Produktionsserver zugreifen, obwohl sie denselben SSO-Benutzer / Passwort verwenden können wie an anderer Stelle . Aber automatisierte Benutzer sind ein bisschen sicherer, zum Beispiel ein automatisiertes Tool, auf das nicht-produktive Administratoren zugreifen können, hat einen Benutzer und Anmeldeinformationen, die nicht in der Produktion verwendet werden können. Wenn Sie Ansible auf allen Knoten starten möchten, müssen Sie dies in zwei Batches machen, einmal für Nicht-Produktion und einmal für Produktion.

Wir verwenden jedoch auch Marionetten, da es sich um ein durchsetzendes Konfigurationsmanagement-Tool handelt, sodass die meisten Änderungen an allen Umgebungen durch sie ersetzt werden.

Offensichtlich wird, wenn die von Ihnen angeführte Feature-Anfrage erneut geöffnet / abgeschlossen wird, das, was Sie tun möchten, vollständig unterstützt. Aber auch dann ist Sicherheit ein Prozess der Risikobewertung und des Kompromisses. Wenn Sie nur wenige Knoten haben, an denen Sie sich die Kennwörter merken können, ohne auf eine Post-it-Notiz zurückgreifen zu müssen, wären separate Kennwörter etwas sicherer. Aber für die meisten von uns ist es keine machbare Option.


52
2017-12-30 16:53



Danke, @Zeb - Ich hatte mir vorgestellt, dass Benutzer mit Dutzenden bis Tausenden von Servern verwenden würden NOPASSWD aus Gründen der Gesundheit sowieso (wahrscheinlich unterstützt durch strengere Firewall-Regeln usw.), aber es ist gut, Ihren Anwendungsfall und Ihre Gedanken zum Bedrohungsmodell zu lesen. - supervacuo
Ein Kommentar zu Ihrem Vorschlag zur Beschränkung auf "vorab genehmigt" sudo Befehle (die mir einfielen, als ich das entdeckte NOPASSWD ist ziemlich viel verlangt). Leider scheint das so zu sein vollständig nicht unterstützt - ansible macht keine Anrufe z.B.  chown oder mkdir Binärdateien direkt und muss in der Lage sein sudo /bin/sh damit die meisten Module funktionieren. - supervacuo
Ich erinnere mich, dass einer meiner Ingenieure sich vor einiger Zeit darüber beschwerte, das ist nervig. - Zeb


Ab Ansible 1.5 ist es möglich einen zu verwenden verschlüsselter Tresor für host_vars und andere Variablen. Damit können Sie zumindest einen pro Host (oder pro Gruppe) speichern ansible_sudo_passvariabel sicher. Unglücklicherweise, --ask-vault-pass fordert nur ein einziges Vault-Passwort pro anrufbaren Aufruf an, sodass Sie immer noch auf ein einziges Vault-Passwort für alle Hosts angewiesen sind, die Sie zusammen verwenden.

Für einige Anwendungen ist dies jedoch möglicherweise eine Verbesserung gegenüber einem einzelnen sudo-Passwort für mehrere Hosts, da ein Angreifer ohne Zugriff auf Ihre verschlüsselten host_vars immer noch ein separates sudo-Passwort für jede Maschine (oder Maschinengruppe) benötigt, die er angreift.


36
2018-05-10 20:32



Das ansible_sudo_pass Option scheint auch neu zu sein - und scheint zu tun, wonach ich gefragt habe. Ein einziges Tresor-Passwort ist ebenfalls ideal für meine Zwecke. Vielen Dank! - supervacuo
Gibt es eine Möglichkeit, Verschlüsselung zu vermeiden? alles  host_vars Verwenden Sie diese Methode? (eine mögliche Einschränkung von Alex Dupuy bemerkt) - supervacuo
@supervacuo - Um die Verschlüsselung aller Host-Variablen zu vermeiden, verwenden Sie einfach ein Host-Var-Verzeichnis, das main.yml (unverschlüsselt) und secret.yml (verschlüsselt) enthält - siehe letzten Teil von Dieser Dokumentabschnitt wo es um die "raleigh" -Gruppe geht - die gleiche Technik funktioniert auch für Host Vars und Group Vars. Ich benutze dies sehr, die einzige Variante ist, dass, wenn ein Geheimnis nur für einige Spielbücher benötigt wird, es nützlich sein kann, es vollständig in einem anderen Baum zu speichern und über einen Pfad einzuschließen, der den Host- oder Variablennamen enthält. - RichVel
Wenn ich den Wert 'ansible_ssh_pass' im Tresor verschlüsselt habe, muss ich auch den Wert 'ansible_sudo_pass' duplizieren. Gibt es eine Möglichkeit, dass der zweite sudo_pass-Wert den ersten 'ssh_pass'-Wert referenziert? - emeraldjava


Mit Ansible 1.5 ist es möglich, den ansible_sudo_pass Variable mit lookup('password', …):

ansible_sudo_pass: "{{ lookup('password', 'passwords/' + inventory_hostname) }}"

Ich finde das bequemer als Dateien in host_vars/ aus verschiedenen Gründen:

  • Ich benutze es tatsächlich with_password: "passwords/{{ inventory_hostname}} encrypt=sha256_crypt" die Passwörter für die bereitstellen entfernter Benutzer (der dann für Sudo), Sie sind also bereits in den Dateien vorhanden (Obwohl das Ausführen dieser Klartext-Suchvorgänge den Salzwert verliert in der Datei gespeichert, wenn der Hashwert generiert wird).

  • Dies hält nur die Passwörter in der Datei (Nr ansible_sudo_pass: bekannter Klartext) für einige Epsilon Erhöhung der kryptografischen Sicherheit. Bedeutsamer ist, dass Sie nicht alle anderen hostspezifischen Variablen verschlüsseln, damit sie ohne das Passwort des Tresors gelesen werden können.

  • Wenn Sie die Kennwörter in einem separaten Verzeichnis speichern, ist es einfacher, die Dateien von der Quellcodeverwaltung fernzuhalten oder ein Tool zu verwenden Git-Krypta um sie in verschlüsselter Form zu speichern (Sie können dies mit früheren Ansible verwenden, denen die Tresor-Funktion fehlt). Ich benutze git-crypt und da ich das Repository nur in entschlüsselter Form auf verschlüsselten Dateisystemen auschecke, kümmere ich mich nicht um den Tresor und muss daher kein Tresor-Passwort eingeben. (Beides wäre natürlich sicherer.)

Sie können auch die Sieh nach oben Funktion mit ansible_ssh_pass; Dies ist möglicherweise sogar mit früheren Versionen von Ansible möglich, die nicht vorhanden sind ansible_sudo_pass.


22
2018-05-26 19:33



ich endlich bin dazu gekommen, es auszuprobieren (danke!), kann aber nicht sehen, wie es ohne funktionieren würde git-crypt; soweit ich das beurteilen kann. Es scheint wie Ansible hat noch keine Unterstützung zum Benutzen lookup in einem verschlüsselten Tresor. Das password Moduldokumente sagen, dass es eine noch nicht dokumentierte Unterstützung für verschlüsselten Speicher gibt, aber ich muss noch Details finden. Irgendwelche Hinweise? - supervacuo


Verwenden bestehen ist eine einfache Methode, um sudo-Passwörter zur Verfügung zu stellen. Pass speichert ein Passwort pro Datei, was es einfach macht, Passwörter über Git oder andere Methoden zu teilen. Es ist auch sicher (mit GnuPG) und wenn Sie gpg-agent verwenden, können Sie ansible verwenden, ohne bei jeder Verwendung ein Passwort einzugeben.

Um das Passwort als gespeichert zu geben servers/foo für Server foo zu verwenden, verwenden Sie es in einer Inventardatei wie folgt:

[servers]
foo ansible_sudo=True \
    ansible_sudo_pass="{{ lookup('pipe', 'pass servers/foo') }}"

Vorausgesetzt, dass Sie den Schlüssel für gpg-agent früher entsperrt haben, wird dies möglich, ohne dass ein Passwort eingegeben werden muss.


17
2018-01-19 19:51



Solch eine ausgezeichnete Lösung - danke! - Leng


Dies ist jedoch ein recht alter Thread:

  • Wir verwenden zwei verschiedene Authentifizierungssysteme intern, die Verwaltung der Maschinen erfolgt von lokalen Arbeitsplätzen in meinem Team.
  • Ich schrieb ein vars_plugin für Ansible (eine ziemlich vollständige Implementierung finden Sie unter https://gist.github.com/mfriedenhagen/e488235d732b7becda81), die mehrere Authentifizierungssysteme unterscheidet:
  • Der Name des Authentifizierungssystems ist gruppenspezifisch.
  • Der verwendete Benutzer login / sudo ist gruppen- und adminspezifisch.
  • Also ziehe ich den Benutzer aus der Admin-Umgebung und das entsprechende Passwort über die Python-Keyring-Bibliothek aus einem Passwort-Safe (wir verwenden den Mac OS X-Schlüsselbund, aber aus der Dokumentation kwallet Gnome und _win_crypto werden ebenfalls unterstützt).
  • Ich habe Berechtigungen für die Kennwörter im Schlüsselbund von Mac OS X eingerichtet, um mich über die Tatsache zu informieren, dass die Sicherheit des Befehlszeilenprogramms den Zugriff auf ein Kennwort für jedes von ihm verwendete Authentifizierungssystem anfordert Die Hosts, also ich "ansible -s all -m ping" ausführen und zwei Aufforderungen (eine für jedes Authentifizierungssystem), wo ich die Leertaste drücken und ansible nimmt die Kennwörter.

3
2018-03-03 17:33



Das sieht sehr ordentlich aus, danke - mir gefällt die Idee, Passwörter nicht an zwei Stellen speichern zu müssen. Im Moment stecke ich mit KeepassX fest (weil der GNOME Schlüsselring nicht sehr portabel erscheint), aber vielleicht kann ich das machen python-keepass Arbeit? - supervacuo
Soweit ich weiß, ist Python-Schlüsselring eine Abstraktion dafür, also können Ihre Kollegen andere Betriebssysteme verwenden. Oder speichern Sie Ihre keepassx db auf einem USB-Stick und müssen von Arbeitsplätzen mit unterschiedlichen Betriebssystemen verwalten? - Mirko Friedenhagen
verstanden; Ich meinte, dass ich KeepassX bereits verwenden muss, um Zugriff auf Passwörter auf Nicht-GNOME-Systemen zu haben, und speichere sie dort gnome-keyring würde bedeuten, doppelte Aufzeichnungen zu führen. Immer noch schöner als zu benutzen NOPASSWDobwohl ... - supervacuo


Eine Möglichkeit, dies zu tun, ist die Verwendung von Umgebungsvariablen.

z.B.

pass1=foo pass2=bar ansible-playbook -i production servers.xml

Dann können Sie in den Spielen das sudo-Passwort nachschlagen:

lookup('env', 'pass1') 
lookup('env', 'pass2') 

0
2017-07-21 08:57