Gestione sicura delle variabili d'ambiente nelle unità di servizio Systemd

Gestione Sicura delle Variabili d'Ambiente nelle Unità di Servizio Systemd

Systemd, in quanto gestore primario di sistema e servizi per le moderne distribuzioni Linux, si basa su file di unità di servizio (.service) per definire come le applicazioni vengono avviate, arrestate e mantenute. Un aspetto critico della configurazione di qualsiasi applicazione moderna è l'iniezione di impostazioni di configurazione, percorsi e, cosa più importante, segreti sensibili come chiavi API o credenziali di database.

Una gestione impropria di queste variabili d'ambiente può portare a vulnerabilità di sicurezza, difficoltà nel debug e configurazioni non portabili. Questa guida illustra le direttive Systemd appropriate—Environment e EnvironmentFile—e dimostra l'uso sicuro dei file di configurazione drop-in per gestire dati sensibili, garantendo la separazione delle responsabilità e solide pratiche di sicurezza.

Il Ruolo delle Variabili d'Ambiente in Systemd

Le variabili d'ambiente forniscono un meccanismo semplice per configurare un servizio senza modificarne il binario o il codice. Quando Systemd avvia un servizio, costruisce un ambiente completo (incluso PATH, variabili utente/gruppo, ecc.) e inietta tutte le variabili definite nel file di unità prima di eseguire il comando ExecStart.

Systemd fornisce due direttive principali all'interno della sezione [Service] di un file di unità per la gestione di queste variabili.

1. Definizione Diretta: La Direttiva `Environment`

Questo metodo consente di definire le variabili direttamente all'interno del file di unità Systemd. È adatto per parametri di configurazione non sensibili che cambiano raramente.

Utilizzo e Sintassi

La direttiva Environment accetta un elenco di assegnazioni di variabili separate da spazi nel formato "CHIAVE=VALORE".

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

[Unit]
Description=Servizio della Mia Applicazione

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

# Definisce le variabili direttamente nel file di unità
Environment="APP_PORT=8080" "NODE_ENV=production"

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

[Install]
WantedBy=multi-user.target

Limitazioni e Sicurezza

Sebbene conveniente, la direttiva Environment non deve mai essere utilizzata per informazioni sensibili (segreti, password, chiavi API). I file di unità sono spesso archiviati in sistemi di gestione della configurazione o si trovano in directory accessibili a vari utenti (anche se di sola lettura, potrebbero essere visualizzabili da utenti non root a seconda della configurazione). Codificare segreti direttamente compromette i principi di sicurezza.

2. Configurazione Esterna: La Direttiva `EnvironmentFile`

Per configurazioni complesse, variabili dinamiche o dati sensibili, caricare le variabili da un file esterno è il metodo preferito. Ciò consente di gestire i permessi del file delle variabili indipendentemente dal file di unità principale.

Utilizzo e Sintassi

La direttiva EnvironmentFile accetta un percorso assoluto a un file di configurazione. Systemd legge questo file riga per riga, trattando ogni riga come una potenziale assegnazione CHIAVE=VALORE.

[Service]
# Carica le variabili da un file esterno
EnvironmentFile=/etc/config/my-app-settings.conf

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

Formato del File di Ambiente

Il file esterno deve aderire a un semplice formato simile a quello di shell:

Le righe che iniziano con # sono trattate come commenti.
Le righe che iniziano con un'assegnazione di variabile vuota (VAR=) cancelleranno la variabile se precedentemente impostata.
Le variabili sono definite come CHIAVE=VALORE.
L'uso delle virgolette per il valore (CHIAVE="VALORE CON SPAZI") è supportato.

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

# Variabili non sensibili
MAX_WORKERS=4
LOG_LEVEL=INFO

# Variabile sensibile (richiede permessi file rigorosi)
DB_PASSWORD=SecureRandomString12345

Gestione dei File Mancanti

Per impostazione predefinita, se il file specificato da EnvironmentFile non esiste, Systemd causerà un errore nell'avvio del servizio. Se il file di ambiente è opzionale, è possibile anteporre al percorso del file un trattino (-):

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

Se al percorso del file viene anteposto -, Systemd ignorerà gli errori causati dal file non presente.

Best Practice: Utilizzo delle Unità Drop-in per Dati Sensibili

Modificare il file di unità principale (ad esempio, /usr/lib/systemd/system/my-app.service) è generalmente sconsigliato, specialmente se il file è gestito da un gestore di pacchetti. Utilizzare invece i file di unità drop-in per applicare override o aggiunte alla configurazione.

Questa pratica è cruciale quando si ha a che fare con variabili d'ambiente sensibili, poiché consente di separare la configurazione standard del servizio dai percorsi locali dei file di segreti.

Configurazione Drop-in Passo Dopo Passo

1. Individuare/Creare la Directory Drop-in

Per un servizio denominato my-app.service, la directory drop-in deve essere denominata my-app.service.d/ e risiedere nella gerarchia /etc/systemd/system/.

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

2. Creare l'Override di Configurazione

Creare un file all'interno della directory drop-in (ad esempio, secrets.conf). Questo file necessita solo della sezione [Service] e delle direttive specifiche che si desidera sovrascrivere o aggiungere.

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

[Service]
# Carica il file delle credenziali sicuro
EnvironmentFile=/etc/secrets/my-app-credentials.env

3. Proteggere il File di Ambiente Esterno

Questo è il passaggio di sicurezza più critico. Assicurarsi che il file esterno contenente i segreti abbia permessi restrittivi. Idealmente, dovrebbe essere di proprietà di root:root e leggibile solo dall'utente root o dall'utente del servizio stesso.

# Crea il file dei segreti
sudo touch /etc/secrets/my-app-credentials.env

# Popola il file con i segreti
sudo sh -c 'echo "DB_PASS=S3cr3tP@ssw0rd" >> /etc/secrets/my-app-credentials.env'

# Imposta permessi restrittivi (root sola lettura)
sudo chmod 600 /etc/secrets/my-app-credentials.env

⚠️ Avviso di Sicurezza: Permessi del File

Se il file referenziato da EnvironmentFile contiene credenziali, i permessi devono essere impostati su 0600 o più restrittivi. Se il file è leggibile da altri utenti, i segreti saranno esposti durante l'avvio del servizio o l'ispezione manuale.

Risoluzione dei Problemi e Verifica

Dopo aver apportato modifiche ai file di unità o ai drop-in, è necessario ricaricare la configurazione del gestore Systemd.

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

Per verificare quali variabili d'ambiente sono state caricate con successo da Systemd per un servizio in esecuzione, utilizzare il comando systemctl show e interrogare specificamente la proprietà Environment:

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

Output di Esempio (mostra le variabili caricate):

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

Se il servizio non si avvia, controllare i log del servizio usando journalctl -xeu my-app.service. Le ragioni comuni di fallimento relative alle variabili d'ambiente includono:

Percorso del file errato in EnvironmentFile.
File mancante (e al percorso non è stato anteposto -).
Sintassi errata della variabile nel file di ambiente esterno (ad esempio, spazi attorno al segno =).

Riepilogo delle Best Practice

Scenario	Direttiva da Usare	Best Practice per la Posizione	Considerazioni sulla Sicurezza
Configurazione Statica, Non Sensibile	`Environment`	File di unità diretto o drop-in	Rischio di sicurezza basso.
Credenziali Sensibili (Segreti)	`EnvironmentFile`	File esterno, referenziato tramite un drop-in (`*.service.d/`)	CRITICO: Il file di ambiente deve avere permessi `0600`.
Modularità e Override	`EnvironmentFile`	File di unità drop-in	Separa la configurazione dai valori predefiniti del fornitore.

Sfruttando la direttiva EnvironmentFile all'interno di un'unità drop-in dedicata e assicurando permessi di file rigorosi, gli amministratori possono gestire le configurazioni di servizio in modo sicuro e flessibile, aderendo ai principi del privilegio minimo e della separazione delle responsabilità.