Auf unseren Maschinen werden verschiedene Dienste ausgeführt, z. B. Cassandra, Datadog usw.
Gelegentlich müssen wir die Konfiguration ändern und möchten die Verbreitung der Konfigurationsdateien und Neustarts automatisieren.
Wir verwenden Jenkins, um den Workflow für unsere Anwendungssoftware zu automatisieren, und haben darüber nachgedacht, dies auch für Dienste zu verwenden. Wir möchten nicht, dass der Server, auf dem Jenkins läuft, Remote-Root-Zugriff (oder sogar Sudo-Zugriff) auf den Hostserver hat.
Ich habe mich gefragt, ob wir den Besitzer von /etc/cassandra sicher in cassandra, /etc/datadog in dd-agent usw. ändern könnten, da uns das bei der Automatisierung helfen würde. (Wird es eigentlich empfohlen, dass solche Ordner/Dateiensollendem entsprechenden Benutzer gehören muss und dass es falsch ist, root als Besitzer anzugeben?)
Antwort1
Die Idee dieses Verzeichnisses war, dass das /etcVerzeichnis allesystemweitKonfiguration - im Gegensatz zur Konfiguration jedes einzelnen Benutzers, die sich in den meisten Fällen $HOME/.configirgendwo weiter unten befindet. Da die systemweite Konfiguration alle Benutzer betrifft, ist es richtig, dass diese Dateien root gehören.
Nun, ich kenne Ihr System nicht, aber Sie führen Cassandra usw. wahrscheinlich einmal pro System aus und benötigen daher wahrscheinlich keine individuelle Benutzerkonfigurationsdatei. Ich sehe keine Fallstricke darin, den Besitz dieser Dateien/Unterverzeichnisse zu ändern, außer dass dies der beabsichtigten Vorgehensweise widerspricht. (Solange Sie den Besitz des Hauptverzeichnisses nicht ändern /etc!)
Ich persönlich würde ein Instanzverzeichnis einrichten (wahrscheinlich in ihrem Home-Ordner) und die dort gespeicherte Konfiguration verwenden – aber das bleibt Ihnen überlassen.
Antwort2
Root sollte nicht Eigentümer von etc.-Konfigurationsdateien sein, die sich auf Anwendungen beziehen. Die elegante Lösung wäre etwa so: Die Datadog-Anwendung wird vom Benutzer datadog ausgeführt und die Konfigurationsdateien gehören datadog und der Gruppe datadog. Aber jetzt kommt Jenkins und muss einige Dateien in /etc/datadog suchen/bearbeiten, aber vielleicht nicht alle.
Also erstellen wir eine neue Gruppe namens „datadogjenkins“ und machen sowohl datadog als auch jenkins zu Mitgliedern dieser Gruppe. Dann ändern wir die OwnerGROUP für die Dateien/Ordner, die Jenkins lesen/schreiben/ausführen muss, in unsere neue Gruppe.
Jetzt können sowohl Datadog als auch Jenkins auf diese Assets zugreifen. Und keiner von beiden muss seine Rechte auf Root erhöhen. Und wir können Jenkins von dem fernhalten, was es nicht sehen muss, falls Jenkins kompromittiert werden sollte.
Hoffe, das erklärt es gut genug.