La tua app Docker riuscirà a scrivere i dati? Checklist dei permessi dei volumi

Perché un container in esecuzione potrebbe non riuscire a scrivere

Un container può avviarsi normalmente mentre l’applicazione non riesce a creare, aggiornare o rimuovere file in una directory dei dati montata. L’avvio del container dimostra che il processo può essere eseguito, ma non che disponga dell’accesso necessario all’applicazione.

Perché una scrittura riesca, l’identità effettiva del processo dell’applicazione deve avere accesso adeguato al percorso montato. Anche un mount in sola lettura, una directory principale non accessibile, un’ACL, una policy SELinux o una mappatura degli user namespace possono bloccare l’accesso. Prima di modificare i permessi, individua il percorso e l’operazione specifici.

• Annota il messaggio di errore dell’applicazione e il file o la directory esatti interessati.
• Stabilisci se il problema riguarda una sola operazione, come la creazione di un file, oppure tutti gli accessi alla directory dei dati.
• Evita di modificare ricorsivamente i permessi finché non sai quale identità e quale regola di accesso causano il problema.

Individua l’identità del processo e il percorso montato

Per prima cosa, controlla la configurazione del container e i mount segnalati da Docker. Per un container chiamato myapp, esegui:

docker inspect --format '{{json .Mounts}}' myapp

Esamina l’origine, la destinazione, il tipo e l’impostazione di lettura/scrittura del mount. Un bind mount punta a un percorso dell’host; un volume nominato ha un’origine gestita da Docker. Verifica che la destinazione corrisponda al percorso che l’applicazione sta effettivamente cercando di usare.

Poi controlla l’identità del container con docker exec myapp id. Considerala un indizio, non una prova definitiva dell’identità del processo dell’applicazione: un entrypoint può avviarsi con una certa identità e poi ridurre i privilegi prima di lanciare l’applicazione. Consulta la documentazione dell’immagine o dell’applicazione relativa all’utente di esecuzione e, se possibile, verifica il processo effettivamente in esecuzione.

Confronta gli ID numerici di utente e gruppo, non solo i nomi utente. In un bind mount Linux convenzionale senza rimappatura degli utenti, la proprietà è numerica sia sull’host sia nel container. Un nome utente identico in due immagini può corrispondere a ID numerici diversi.

• Conferma il nome del container, la destinazione del mount e il percorso sorgente sull’host o il nome del volume.
• Individua l’utente effettivo e i gruppi usati dal processo dell’applicazione, tenendo conto di eventuali riduzioni dei privilegi dopo l’avvio.
• Annota gli ID numerici. I soli nomi utente non consentono un confronto affidabile della proprietà.

Controlla la proprietà, i bit dei permessi e i controlli dell’host

Su un host Linux, esamina l’origine del bind mount verificando la proprietà numerica e i permessi. Sostituisci /srv/myapp/data con il percorso host effettivo:

ls -ln /srv/myapp/data

stat -c '%u:%g %a %n' /srv/myapp/data

Controlla la directory e tutte le directory principali. Un processo deve poter accedere adeguatamente a ogni livello del percorso: non basta che la directory finale sembri scrivibile se non è possibile attraversare una directory principale. Se disponibile, namei -l /srv/myapp/data può aiutare a visualizzare i permessi lungo il percorso.

Se le verifiche di base relative alla proprietà e ai bit dei permessi non spiegano il problema di accesso, controlla le ACL con getfacl e, sui sistemi che usano SELinux, esamina il contesto dei file con ls -Z. I controlli pertinenti sull’host e le mappature delle identità dipendono dalla configurazione. Docker rootless e la rimappatura degli user namespace possono far sì che gli ID sull’host differiscano da quelli visibili nel container.

• Confronta l’UID e i gruppi del processo con il proprietario, il gruppo e i bit dei permessi della directory.
• Controlla i permessi necessari per attraversare le directory principali oltre all’accesso alla directory finale.
• Se le normali verifiche della proprietà non chiariscono il risultato, controlla le ACL, il contesto SELinux e le mappature degli user namespace o della modalità rootless.

Verifica le operazioni di cui l’applicazione ha davvero bisogno

L’elenco dei permessi non sostituisce una prova di scrittura. Per prima cosa, verifica se Docker ha montato il percorso in sola lettura. Un mount in sola lettura può impedire intenzionalmente il salvataggio anche quando la directory sottostante sembra scrivibile.

Esegui la prova con l’identità effettiva dell’applicazione, nella destinazione montata, usando un nome temporaneo che non sovrascriva i dati dell’applicazione. Se l’immagine include una shell e l’applicazione viene eseguita con UID 1000 e GID 1000, un esempio di base è:

docker exec --user 1000:1000 myapp sh -c 'f=/data/.permission-test-$$; : > "$f" && rm "$f"'

Sostituisci gli ID e /data con i valori della tua configurazione. Questa prova verifica la creazione e la rimozione, ma non dimostra che tutte le operazioni dell’applicazione funzioneranno. Per esempio, aggiornare un file esistente, creare una sottodirectory o rinominare un file può richiedere permessi diversi. Inoltre, la prova potrebbe non riprodurre i gruppi supplementari o altri dettagli del processo dell’applicazione: interpreta il risultato insieme all’identità del processo e all’errore segnalato dall’applicazione.

Quando possibile, verifica l’operazione anche tramite l’applicazione. Una prova riuscita dalla shell è un’indicazione utile, ma l’applicazione potrebbe usare un percorso, un’identità o un’operazione diversi.

• Usa un file temporaneo nella directory effettivamente montata e rimuovilo al termine della prova.
• Verifica la creazione o la modifica di directory solo se sono operazioni necessarie all’applicazione.
• Se la prova riesce ma l’applicazione continua a non funzionare, ricontrolla il percorso effettivo, l’identità, i gruppi e l’errore dell’applicazione.

Risolvi le discrepanze tra UID e GID senza usare chmod 777

Quando la proprietà numerica non corrisponde all’identità dell’applicazione, scegli una soluzione coerente con il modello di accesso previsto. Non dare per scontato che sia sicuro assegnare tutti i file a un UID ipotizzato: prima conferma l’identità di esecuzione documentata dell’applicazione e verifica se altri servizi o amministratori devono avere accesso.

Per una directory da condividere, concorda un gruppo che includa le identità dei processi pertinenti e concedi solo l’accesso necessario a quel gruppo. Il bit setgid può aiutare le nuove voci a ereditare il gruppo della directory, ma il solo accesso in scrittura al gruppo sui file esistenti non garantisce che i file futuri restino accessibili al gruppo. L’umask dell’applicazione e le ACL predefinite possono influire sui nuovi file.

Un chmod 777 generalizzato concede un accesso ampio e non è una soluzione affidabile. Per esempio, non può risolvere un mount in sola lettura o una restrizione SELinux. Preferisci la modifica più limitata possibile della proprietà, del gruppo, delle ACL o del mount che risolva la causa verificata e conserva un backup prima di apportare modifiche estese alla proprietà.

• Se è errato solo il proprietario, conferma l’UID previsto e l’ambito della modifica prima di cambiare la proprietà.
• Se più processi necessitano di accesso, usa un gruppo concordato e controlla l’appartenenza ai gruppi, il funzionamento del bit setgid, l’umask e le ACL predefinite.
• Se il mount è in sola lettura, correggi la configurazione del mount solo se l’applicazione deve scrivere in quel percorso.
• Non usare chmod 777 come procedura generica di risoluzione dei problemi.

Ricontrolla i permessi quando cambiano immagini, host o modalità di distribuzione

Una distribuzione che funzionava prima può smettere di funzionare dopo una modifica all’immagine o all’host. La nuova immagine potrebbe eseguire l’applicazione con un’identità numerica diversa, anche se il nome dell’account sembra invariato. Anche il trasferimento su un altro host può modificare la proprietà della directory usata come bind mount o i controlli di accesso sull’host.

I volumi nominati richiedono considerazioni specifiche. Normalmente, quando un volume nominato vuoto viene montato sopra una directory dell’immagine, Docker lo popola a partire da quella directory, a meno che la copia iniziale sia disabilitata. Un volume esistente non viene riportato a ogni avvio alla proprietà della directory dell’immagine. I driver dei volumi e le opzioni di mount possono cambiare il comportamento: esamina quindi il mount effettivo anziché basarti su supposizioni sull’inizializzazione.

Se usi Docker rootless o la rimappatura degli user namespace, considera la mappatura delle identità quando confronti gli ID del container e dell’host. Non eseguire un chown sull’host basandoti solo sull’UID del container finché non hai compreso come viene mappato quell’UID.

• Prima di aggiornare un’immagine, controlla se sono cambiati l’utente di esecuzione dell’applicazione o i percorsi dei dati.
• Prima di migrare un host, annota il percorso sorgente, la proprietà numerica, le ACL, il contesto di sicurezza e la configurazione del mount.
• Per i volumi nominati, distingui un volume appena creato da uno esistente e verifica i contenuti e la proprietà attuali.
• Nelle configurazioni rootless o con rimappatura, verifica la mappatura prima di modificare la proprietà sull’host.

Documenta l’accesso previsto e verificalo dopo la migrazione

Conserva una breve registrazione del percorso dei dati, del tipo di volume, dell’UID e dei gruppi dell’applicazione, delle operazioni di lettura e scrittura necessarie e delle eventuali impostazioni ACL o di sicurezza dell’host configurate intenzionalmente. Indica se il mount è in sola lettura e se è attiva la rimappatura delle identità. Così sarà più facile verificare il funzionamento dopo il prossimo aggiornamento o la prossima migrazione.

Dopo una migrazione, un aggiornamento dell’immagine o una modifica della distribuzione, ripeti l’ispezione e la prova. Conferma che l’applicazione possa eseguire le operazioni da cui dipende, non soltanto che il container si avvii. Prima di modificare la proprietà o i controlli di accesso, conserva una copia recuperabile dei dati importanti.

Una distribuzione gestita può ridurre il lavoro infrastrutturale a carico di un team, ma non elimina la necessità di fare scelte consapevoli su dati, accessi e ripristino. Airbip offre la distribuzione gestita di applicazioni a catalogo eseguite come carichi di lavoro Docker sui server cloud Airbip, con gestione del ciclo di vita dei servizi e backup giornalieri, settimanali e mensili configurabili. Consulta il sito Airbip aggiornato per informazioni su piani e condizioni attuali e verifica che un approccio gestito sia adatto alle tue esigenze operative e relative ai dati.

• Documenta le identità numeriche, i dettagli del mount, le operazioni previste e tutti i controlli non predefiniti dell’host.
• Ripeti la prova di scrittura reale dopo una migrazione o un aggiornamento e indaga gli eventuali errori prima di fare affidamento sulla distribuzione.
• Chiarisci le responsabilità relative alla proprietà dei dati e al ripristino, sia che gestisca il server direttamente sia che utilizzi un hosting gestito.