Umgebungsvariablen sicher in Systemd Service Units verwalten

Sicheres Verwalten von Umgebungsvariablen in Systemd-Service-Units

Systemd, als primärer System- und Dienstmanager für moderne Linux-Distributionen, stützt sich auf Service-Unit-Dateien (.service), um zu definieren, wie Anwendungen gestartet, gestoppt und gewartet werden. Ein kritischer Aspekt bei der Konfiguration jeder modernen Anwendung ist das Einbinden von Konfigurationseinstellungen, Pfaden und, was am wichtigsten ist, sensiblen Geheimnissen wie API-Schlüsseln oder Datenbankanmeldeinformationen.

Eine unsachgemäße Verwaltung dieser Umgebungsvariablen kann zu Sicherheitslücken, Debugging-Schwierigkeiten und nicht portablen Konfigurationen führen. Dieser Leitfaden beschreibt die geeigneten Systemd-Direktiven – Environment und EnvironmentFile – und demonstriert die sichere Verwendung von Drop-in-Konfigurationsdateien zur Handhabung sensibler Daten, wodurch die Trennung der Verantwortlichkeiten und robuste Sicherheitspraktiken gewährleistet werden.

---

Die Rolle von Umgebungsvariablen in Systemd

Umgebungsvariablen bieten einen unkomplizierten Mechanismus zur Konfiguration eines Dienstes, ohne dessen Binärdatei oder Code ändern zu müssen. Wenn Systemd einen Dienst startet, erstellt es eine vollständige Umgebung (einschließlich des notwendigen PATH, Benutzer-/Gruppenvariablen usw.) und injiziert alle im Unit-File definierten Variablen, bevor der ExecStart-Befehl ausgeführt wird.

Systemd stellt im Abschnitt [Service] einer Unit-Datei zwei Hauptdirektiven zur Verwaltung dieser Variablen bereit.

1. Direkte Definition: Die Direktive Environment

Diese Methode ermöglicht es Ihnen, Variablen direkt in der Systemd-Unit-Datei zu definieren. Dies eignet sich für nicht sensible Konfigurationsparameter, die sich selten ändern.

Verwendung und Syntax

Die Direktive Environment akzeptiert eine durch Leerzeichen getrennte Liste von Variablendefinitionen im Format "SCHLÜSSEL=WERT".

# /etc/systemd/system/my-app.service

[Unit]
Description=Mein Anwendungsservice

[Service]
User=myuser
WorkingDirectory=/opt/my-app

# Variablen direkt in der Unit-Datei definieren
Environment="APP_PORT=8080" "NODE_ENV=production"

ExecStart=/usr/local/bin/my-app --start

[Install]
WantedBy=multi-user.target

Einschränkungen und Sicherheit

Obwohl praktisch, sollte die Direktive Environment niemals für sensible Informationen (Geheimnisse, Passwörter, API-Schlüssel) verwendet werden. Unit-Dateien werden häufig in Konfigurationsmanagementsystemen gespeichert oder in Verzeichnissen abgelegt, auf die verschiedene Benutzer zugreifen können (selbst wenn sie nur lesbar sind, können sie je nach Konfiguration von Nicht-Root-Benutzern eingesehen werden). Das direkte Festkodieren von Geheimnissen untergräbt Sicherheitsprinzipien.

2. Externe Konfiguration: Die Direktive EnvironmentFile

Für komplexe Konfigurationen, dynamische Variablen oder sensible Daten ist das Laden von Variablen aus einer externen Datei die bevorzugte Methode. Dies ermöglicht es Ihnen, die Berechtigungen der Variablendatei unabhängig von der Haupt-Unit-Datei zu verwalten.

Verwendung und Syntax

Die Direktive EnvironmentFile benötigt einen absoluten Pfad zu einer Konfigurationsdatei. Systemd liest diese Datei Zeile für Zeile und behandelt jede Zeile als eine potenzielle SCHLÜSSEL=WERT-Zuweisung.

[Service]
# Variablen aus einer externen Datei laden
EnvironmentFile=/etc/config/my-app-settings.conf

ExecStart=/usr/local/bin/my-app --start

Format der Umgebungsvariablendatei

Die externe Datei muss einem einfachen Shell-ähnlichen Format entsprechen:

• Zeilen, die mit # beginnen, werden als Kommentare behandelt.
• Zeilen, die mit einer leeren Variablendefinition (VAR=) beginnen, löschen die Variable, falls sie zuvor gesetzt wurde.
• Variablen werden als SCHLÜSSEL=WERT definiert.
• Das Setzen von Anführungszeichen um den Wert (SCHLÜSSEL="WERT MIT LEERZEICHEN") wird unterstützt.

# /etc/config/my-app-settings.conf

# Nicht-sensible Variablen
MAX_WORKERS=4
LOG_LEVEL=INFO

# Sensible Variable (erfordert strenge Dateiberechtigungen)
DB_PASSWORD=SecureRandomString12345

Umgang mit fehlenden Dateien

Standardmäßig schlägt Systemd den Dienststart fehl, wenn die durch EnvironmentFile angegebene Datei nicht existiert. Wenn die Umgebungsvariablendatei optional ist, können Sie dem Dateipfad ein Bindestrich (-) voranstellen:

EnvironmentFile=-/etc/config/optional-settings.conf

Wenn der Datei ein - vorangestellt wird, ignoriert Systemd Fehler, die dadurch entstehen, dass die Datei nicht vorhanden ist.

Best Practice: Verwendung von Drop-in-Units für sensible Daten

Das Ändern der eigentlichen Unit-Datei (z. B. /usr/lib/systemd/system/my-app.service) wird im Allgemeinen abgeraten, insbesondere wenn die Datei von einem Paketmanager verwaltet wird. Verwenden Sie stattdessen Drop-in-Unit-Dateien, um Konfigurationsüberschreibungen oder Ergänzungen anzuwenden.

Diese Vorgehensweise ist entscheidend beim Umgang mit sensiblen Umgebungsvariablen, da sie es Ihnen ermöglicht, die Standard-Servicekonfiguration von den lokalen Pfaden der Geheimnisdateien zu trennen.

Schritt-für-Schritt-Drop-in-Konfiguration

1. Drop-in-Verzeichnis finden/erstellen

Für einen Dienst namens my-app.service muss das Drop-in-Verzeichnis my-app.service.d/ heißen und sich in der Hierarchie /etc/systemd/system/ befinden.

sudo mkdir -p /etc/systemd/system/my-app.service.d/

2. Die Konfigurationsüberschreibung erstellen

Erstellen Sie eine Datei im Drop-in-Verzeichnis (z. B. secrets.conf). Diese Datei benötigt nur den Abschnitt [Service] und die spezifischen Direktiven, die Sie überschreiben oder hinzufügen möchten.

# /etc/systemd/system/my-app.service.d/secrets.conf

[Service]
# Die sichere Anmeldedatei laden
EnvironmentFile=/etc/secrets/my-app-credentials.env

3. Die externe Umgebungsvariablendatei absichern

Dies ist der wichtigste Sicherheitsschritt. Stellen Sie sicher, dass die externe Datei, die die Geheimnisse enthält, restriktive Berechtigungen hat. Idealerweise sollte sie root:root gehören und nur für den Root-Benutzer oder den Dienstbenutzer selbst lesbar sein.

# Die Geheimnisdatei erstellen
sudo touch /etc/secrets/my-app-credentials.env

# Die Datei mit Geheimnissen füllen
sudo sh -c 'echo "DB_PASS=S3cr3tP@ssw0rd" >> /etc/secrets/my-app-credentials.env'

# Restriktive Berechtigungen festlegen (Root nur Lesezugriff)
sudo chmod 600 /etc/secrets/my-app-credentials.env

⚠️ Sicherheitshinweis: Dateiberechtigungen

Wenn die von EnvironmentFile referenzierte Datei Anmeldeinformationen enthält, müssen die Berechtigungen auf 0600 oder strenger gesetzt werden. Wenn die Datei für andere Benutzer lesbar ist, werden die Geheimnisse beim Start des Dienstes oder bei manueller Überprüfung preisgegeben.

Fehlerbehebung und Überprüfung

Nachdem Sie Änderungen an Unit-Dateien oder Drop-ins vorgenommen haben, müssen Sie die Systemd-Manager-Konfiguration neu laden.

sudo systemctl daemon-reload
sudo systemctl restart my-app.service

Um zu überprüfen, welche Umgebungsvariablen von Systemd für einen laufenden Dienst erfolgreich geladen wurden, verwenden Sie den Befehl systemctl show und fragen Sie gezielt die Eigenschaft Environment ab:

systemctl show my-app.service --property=Environment

Beispielausgabe (zeigt geladene Variablen):

Environment=APP_PORT=8080 NODE_ENV=production DB_PASS=S3cr3tP@ssw0rd

Wenn der Dienst fehlschlägt, überprüfen Sie die Dienstprotokolle mit journalctl -xeu my-app.service. Häufige Gründe für Fehler im Zusammenhang mit Umgebungsvariablen sind:

1. Falscher Dateipfad in EnvironmentFile.
2. Fehlende Datei (und der Pfad wurde nicht mit - präfixiert).
3. Falsche Variablensyntax in der externen Umgebungsvariablendatei (z. B. Leerzeichen um das = Zeichen).

Zusammenfassung der Best Practices

Szenario	Zu verwendende Direktive	Empfohlener Speicherort	Sicherheitsaspekte
Statische, nicht-sensible Konfiguration	Environment	Direkte Unit-Datei oder Drop-in	Geringes Sicherheitsrisiko.
Sensible Anmeldeinformationen (Geheimnisse)	EnvironmentFile	Externe Datei, referenziert über ein Drop-in (*.service.d/)	KRITISCH: Die Umgebungsvariablendatei muss Berechtigungen 0600 haben.
Modularität & Überschreibungen	EnvironmentFile	Drop-in Unit-Datei	Trennt die Konfiguration von Herstellerstandards.

Durch die Nutzung der Direktive EnvironmentFile innerhalb einer dedizierten Drop-in-Unit und die Sicherstellung strenger Dateiberechtigungen können Administratoren Servicekonfigurationen sicher und flexibel verwalten und dabei die Prinzipien der geringsten Rechte und der Verantwortungsseparation einhalten.