Frage Puppet Security und Netzwerktopologien


Hintergrund:

Ich nehme mir endlich etwas Zeit, um dem 21. Jahrhundert beizutreten und Puppet zu betrachten.

Wie es heute aussieht, kontrollieren wir alle Serverkonfigurationen in einem Repository, das intern im Büro gehalten wird. Wenn ein Update durchgeführt werden muss, werden die Änderungen in die Repos zurücküberprüft und manuell auf den betreffenden Computer übertragen. Dies bedeutet in der Regel, dass SFTP auf dem Remotecomputer ausgeführt wird und dann Dateien mit den entsprechenden Berechtigungen von einer Shell an den richtigen Ort verschoben werden.

Ich hoffe also, dass Puppet eine einfache, aber erstaunliche Erweiterung dessen ist, was wir bereits haben.

Jetzt betrachte ich den Prozess, den wir derzeit einigermaßen sicher haben müssen. In der Annahme, dass unser internes Netzwerk immer relativ sicherer ist als die öffentlichen Netzwerke in unseren Rechenzentren.

  • Der Prozess ist immer ein Weg. Änderungen gehen von einer sicheren Umgebung in eine unsichere um und niemals umgekehrt.

  • Der Meisterladen ist am sichersten Ort. Das Risiko von Kompromittierungen, sei es durch das Stehlen von Konfigurationen oder das Senden böswilliger Änderungen, wird erheblich reduziert.

Frage:

Was ich vom Puppet-Server / Client-Modell verstehe, ist, dass die Clients aktuelle Updates direkt vom Server abrufen und abrufen. Der Datenverkehr ist SSL-verschlüsselt und kann daher nicht abgefangen oder gefälscht werden. Aber es unterscheidet sich von dem, was wir derzeit tun, weil der Puppet-Server [s] an einem öffentlichen Ort gehostet werden müsste. Entweder zentral oder für jede Datencenter-Site, die wir verwalten.

Ich frage mich also:

  • Bin ich unnötigerweise paranoid gegenüber dem Wechsel von Push zu Pull?

  • Bin ich unnötig paranoid darüber, all diese Informationen zentral in einem öffentlichen Netzwerk zu speichern?

  • Wie erhalten andere mehrere Netzwerke - separate Server für jede Site?


Update 30/07/09:

Ich denke, das ist einer meiner anderen groß Bedenken müssen gestellt werden, also muss man sich auf eine einzige Maschine verlassen. Der (die) Puppenmeister (innen) wären feuergewehrt, gesichert und so. Aber trotzdem hat jede öffentliche Maschine mit Hördiensten eine Angriffsfläche von bestimmter Größe.

Vermutlich, wenn der Master die Erlaubnis hat, irgendeine Datei auf einem der Marionetten-Clients zu aktualisieren, würde seine Kompromittierung letztendlich zur Kompromittierung aller seiner Clients führen. Die "Könige zum Königreich" sozusagen.

  • Ist diese Hypothese richtig?

  • Gibt es eine Möglichkeit, dass es gemildert werden kann?


26
2017-07-28 16:36


Ursprung


Deine Hypothesen sind korrekt; Kompromiss auf dem Puppetmaster ist Kompromiss auf allen Kunden. Es ist jedoch einfacher, sich in Bezug auf die Sicherheit einer einzelnen Maschine wohl zu fühlen, auf deren Sicherheit Sie sich konzentrieren können, als ein ganzes Netzwerk von Maschinen, oder? Die Schadensbegrenzung hängt von Ihrer Umgebung ab, aber die Marionette ist so angelegt, dass es sich um eine Klempnerei handelt. Es gibt eine Reihe von "Haken", an denen Sie bei Bedarf Auditing oder zusätzliche Prüfungen hinzufügen können. - Paul Lathrop
@Paul - Eine Art "Alle Eier in einen Korb legen, nachdem Sie sichergehen, dass Sie einen sehr guten Korb haben" -Ansatz? - Matt Simmons


Antworten:


Da ich manchmal Passwörter in Variablen in meinen Modulen speichern kann, um Anwendungen bereitstellen zu können, ohne die Konfiguration manuell abschließen zu müssen, bedeutet dies, dass ich mein Marionetten-Repo nicht anständig auf einen öffentlichen Server stellen kann. Dies würde bedeuten, dass ein Angriff auf den Puppetmaster es erlauben würde, auf allen unseren Servern einige App- oder Db-Passwörter aller unserer verschiedenen Anwendungen zu erhalten.

Also ist mein Puppetmaster in unserem privaten Netzwerk und ich betreibe keinen puppetd Daemon auf den Servern. Wenn ich bereitstellen muss, verwende ich ssh vom privaten Netz zu den Servern, einen Tunnel bildend und remote puppetd anrufend.
Der Trick besteht darin, den Remote-Tunnel und den Marionetten-Client nicht so zu konfigurieren, dass er sich mit dem Puppetmaster verbindet, sondern mit einem Proxy, der akzeptiert http verbinden und kann den Puppetmaster-Server im privaten Netzwerk erreichen. Andernfalls wird sich die Marionette weigern, wegen eines Hostnamenskonflikts mit Zertifikaten zu ziehen

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

Es funktioniert für mich, hofft es hilft dir


10
2017-12-10 06:59



Brillant! Aber brauchst du eine einmalige Zeit auf der Puppe? Andernfalls bricht der Tunnel nach der Ausführung des Befehls nicht zusammen, aber puppetd wird standardmäßig als Server ausgeführt. - Purfideas
Die Puppe, die gestartet wird, ist nicht dämonisch. Ich bevorzuge die Option --test anstelle des Paares --ontime --no-daemonize. So wird puppetd im Vordergrund ausgeführt, und ssh erzwingt ein Terminal (Option -t). Es hat auch den Vorteil, dass Sie mit der laufenden Puppe interagieren können (zB ctrl ^ c für einen sauberen Puppenabbruch). Sobald puppetd beendet wird, wird die ssh-Sitzung beendet und der Tunnel geschlossen. - Alex F
Ich stellte fest, dass dies immer noch Probleme verursachte und so endete die Konfiguration eines OpenVPN-Servers auf dem Firewall-Computer, so dass das Netzwerk mit dem Marionetten-Server von den entfernten Maschinen aus kontaktiert werden kann ... - David Gardner


Wir haben zwei Standorte, unser Büro und unser Colo. Jede Seite hat ihren eigenen Puppenmeister. Wir haben ein svn-Repository mit folgender Struktur eingerichtet:

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

Das Modulverzeichnis unter jeder Site ist ein svn: externals-Verzeichnis, das zurück in das Verzeichnis der obersten Modulebenen führt. Dies bedeutet, dass sie genau das gleiche Modulverzeichnis verwenden. Wir stellen dann sicher, dass die große Mehrheit der Klassen, die wir schreiben, unter dem Modulverzeichnis stehen und von beiden Seiten verwendet werden. Dies hat den Vorteil, dass wir generisch denken und keine Klasse an eine bestimmte Site binden.

Sicherheitshalber hosten wir unseren Puppetmaster (und den Rest unseres Netzwerks) hinter unserer Firewall, weshalb es uns nicht so wichtig ist, die Konfiguration zentral zu speichern. Der Puppetmaster sendet die Config nur an Hosts, denen er vertraut. Offensichtlich müssen Sie diesen Server sicher halten.


4
2017-07-28 17:37



Vielen Dank. Der Tipp von svn: externals ist eine nette Geste. Alles wird in Brand gesetzt. Aber, weißt du, irgendetwas wird einem Hörservice inhärent eine größere Angriffsfläche haben. - Dan Carley


Ich kann nicht beurteilen, wie notwendig Ihre Paranoia ist, es hängt stark von Ihrer Umgebung ab. Ich kann jedoch mit Zuversicht sagen, dass die zwei Hauptpunkte Ihrer bestehenden Konfiguration noch immer zutreffen können. Sie können den Wechsel von einer sicheren Umgebung (das Repository in Ihrem Büro) zu einer weniger sicheren Umgebung sicherstellen, unabhängig davon, wo sich Ihr Puppenspieler befindet. Du änderst den Prozess von SFTP zu einer Reihe von Servern und stellst Dateien manuell an SFTP zu deinem Puppetmaster und lässt Puppet die Dateien verteilen und an den richtigen Platz setzen. Ihr Master Store ist immer noch das Repository und Ihre Risiken werden gemindert.

Ich glaube nicht, dass Push oder Pull von Natur aus sicherer sind als das andere Modell. Puppet leistet hervorragende Arbeit bei der Sicherung der Konfigurationen während der Übertragung sowie bei der Authentifizierung von Client und Server, um sicherzustellen, dass eine bidirektionale Vertrauensstellung besteht.

Was die multiplen Netzwerke betrifft - wir behandeln es mit einem zentralen "Master" Puppetmaster mit Satellitenpuppemastern an jedem Ort, der als Client für den zentralen Master fungiert.


2
2017-07-28 17:33



Der Satellitenansatz klingt interessant. Ist eine spezielle Konfiguration erforderlich? Könnten Sie mir in Richtung Dokumentation zeigen? - Dan Carley
Es ist nicht wirklich eine spezielle Konfiguration erforderlich. Sie laufen einfach auf den Satelliten. puppet.conf sollte die Server-Einstellung auf "Master" gesetzt haben, anstatt auf sich selbst zu zeigen (was eine typische Konfiguration ist) - Paul Lathrop


Ein Design-Ansatz besteht darin, einen Puppetmaster lokal für jeden Standort von Systemen zu haben und ein Implementierungswerkzeug zu verwenden, um Änderungen an den Puppetmastern vorzunehmen. (Die Verwendung von Git mit Git-Haken könnte auch funktionieren).

Dies würde Ihre Bedenken hinsichtlich des Abhörens von Diensten in einem öffentlichen Netzwerk erhalten, da der Marionetten-Netzwerkverkehr nur intern erfolgen würde.

Es ist auch möglich, die Manifeste an jeden Server zu senden und den Marionetten-Client die Manifeste analysieren zu lassen und die entsprechenden Konfigurationen anzuwenden.


1
2017-12-10 07:20





Obwohl du "external" sagst, bezweifle ich wirklich, dass sich willkürliche Leute mit deinem Puppenspieler verbinden müssen. Sie können immer ein VPN in den Mix werfen. Ein Freund von mir hat mich einmal gefragt "Müssen Sie sich wegen der Sicherheit des Protokolls Sorgen machen, wenn die Verbindung sicher ist?" Während ich mit dieser Einstellung nicht einverstanden bin, tut eine zusätzliche Schicht nie weh und wirkt auf meiner persönlichen Paranoia sicherlich Wunder. Außerdem macht es Spaß Tunnel zu tunneln.


0
2017-10-03 13:34





Mark Burgess, der Autor von cfengine und ein Universitätsprofessor (diese Puppe scheint ihr Erbe zu verdanken) hat viel über Push und Pull geschrieben. Er behauptet, Pull ist von Natur aus sicherer. Wenn Sie sich die Website von cfengine ansehen, hatten sie in 17 Jahren nur 1 Netzwerksicherheitsvorfall. Burgess behauptet, dass dies wegen der Pull-Design ist. Ich denke, ein einziger Punkt des Kompromisses ist unvermeidlich. Ich wäre mehr besorgt über die Angriffswege bis zu diesem Punkt.


0
2018-01-30 08:52





Sie können Marionette ohne einen zentralen Master ausführen, wenn Sie möchten. Eine Methode, die ich gesehen habe, ist die Verwendung eines Git-Repositorys und Skripten, die nur dann ein Update zusammenführen und bereitstellen, wenn das Tag von einer vorgegebenen Liste von GPG-Schlüsseln signiert wurde. Die Leute haben sogar herausgefunden, wie man gespeicherte Konfigurationen erhält (zB um ein Nagios-Monitoring auf einem zentralen Server von einer auf einem anderen Server verarbeiteten Ressource aus zu konfigurieren).

Wenn also der zentrale Git-Server kompromittiert wurde, würden die anderen Server keine weiteren Updates von diesem Server übernehmen. Die GPG-Schlüssel würden auf sys-Admin-Laptops oder etwas sein, zusammen mit einer Art, Schlüssel zu entziehen.

Lesen Sie mehr unter http://current.workingdirectory.net/posts/2011/puppet-without-master/


0
2018-05-25 13:44