Come bloccare UID/GID dei container e la proprietà dei volumi prima degli aggiornamenti delle app self-hosted

Gli aggiornamenti delle app self-hosted hanno meno probabilità di creare file di proprietà di root quando il deployment fissa un’identità numerica dell’utente e convalida la proprietà dei volumi prima di sostituire il container.

L’attività preventiva consiste nel non considerare il nome utente interno dell’immagine come un’identità di archiviazione stabile. Registra l’UID e il GID effettivi che scrivono i dati persistenti, assoc li alle directory host o ai volumi denominati, conserva le impostazioni PUID/PGID o dello user namespace e testa la nuova immagine su un piccolo percorso scrivibile prima del rollout completo. In questo modo, un aggiornamento dell’immagine non potrà modificare silenziosamente il proprietario numerico di configurazioni, caricamenti, database o metadati multimediali.

Registra l’UID e il GID numerici prima dell’aggiornamento

Acquisisci l’utente del processo in esecuzione, il gruppo primario, i gruppi supplementari e la proprietà numerica di file rappresentativi in ogni mount scrivibile. Salva il digest o la versione dell’immagine accanto a questa baseline della proprietà.

La guida di Docker sulla creazione delle immagini afferma che gli ID espliciti evitano variazioni tra le build, perché agli utenti delle immagini assegnati automaticamente possono essere attribuiti ID numerici diversi tra una build e l’altra.

Registra i numeri, non solo nomi come app o media. Una nuova immagine può riutilizzare lo stesso nome utente cambiandone l’UID, mentre i file host memorizzano la proprietà numerica.

Fissa l’utente runtime nel contratto di deployment

Quando l’immagine supporta l’esecuzione diretta con un account non root, specifica esplicitamente l’utente e il gruppo desiderati in Compose o nella configurazione runtime. Se l’immagine richiede una fase di inizializzazione con root, documenta quale processo successivo scrive effettivamente i dati persistenti.

La specifica Open Container per le immagini definisce User come valore predefinito runtime, il che significa che un’immagine modificata può alterare l’identità runtime se il deployment non la sovrascrive o convalida intenzionalmente.

Non imporre un UID non root arbitrario alle immagini che richiedono un modello di inizializzazione supportato. Il contratto dovrebbe seguire la progettazione documentata dell’applicazione, mantenendo prevedibile il proprietario risultante dei file persistenti.

Mantieni PUID e PGID allineati alla proprietà host

Per le immagini che espongono le variabili PUID e PGID, fissa questi valori nella configurazione Compose o ambientale sottoposta a controllo versione e assicurati che le directory dei volumi sul lato host siano di proprietà dell’account di servizio corrispondente.

LinuxServer spiega che PUID associa le scritture del container, così i file creati nei volumi associati restano gestibili al di fuori del container.

Prima dell’aggiornamento, confronta gli ID configurati con l’output di id sull’host e con la proprietà dei file esistenti. Non copiare alla cieca un valore di esempio come 1000 su un server in cui quell’ID appartiene a un’altra persona o a un altro servizio.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Tieni conto degli user namespace e della mappatura rootless

Docker o Podman rootless possono far apparire un processo come root all’interno del container, mappandolo però a un UID non root sull’host. Registra la modalità del namespace e la configurazione degli UID/GID subordinati prima di interpretare le variazioni di proprietà.

Le opzioni runtime di Podman mostrano che keep-id conserva la mappatura dell’utente quando un container deve accedere in modo prevedibile ai file montati dall’host.

Non “correggere” un proprietario che appare come root all’interno del container prima di aver verificato l’ID numerico sul lato host. Root nel namespace e root sull’host non rappresentano sempre la stessa identità.

Esegui il preflight della nuova immagine su un volume di test

Prima di sostituire il container di produzione, esegui la nuova immagine con l’UID/GID desiderato e una directory temporanea che rispecchi i permessi di produzione. Lascia che l’inizializzazione all’avvio crei un file e una directory, quindi controllane la proprietà sul lato host.

La guida di Red Hat per il debug dei volumi rootless dimostra che la proprietà sull’host segue la mappatura UID, invece di poter considerare il nome utente mostrato nel container una prova sufficiente.

Se il canary crea file inattesi di proprietà di root o rimappati, interrompi il rollout e confronta utente dell’immagine, entrypoint, namespace e impostazioni dei mount. È molto più sicuro che scoprire la modifica dopo che una migrazione ricorsiva all’avvio ha interessato un intero albero di foto o database.

Verifica i gruppi supplementari e i percorsi scrivibili

Alcune app richiedono un UID di servizio primario oltre all’accesso tramite un gruppo condiviso per contenuti multimediali, download o dispositivi. Registra gli ID di questi gruppi e testa tutti i percorsi scrivibili, non solo la directory di configurazione.

Kubernetes utilizza controlli espliciti runAsUser e runAsGroup, illustrando lo stesso principio di proprietà Linux anche al di fuori di un semplice deployment Docker Compose.

La policy di aggiornamento è completa quando la nuova immagine crea file con la proprietà host prevista in ogni percorso persistente e supera la ricreazione di un container. L’articolo correlato di ZimaSpace sui file di proprietà di root dopo gli aggiornamenti delle immagini rappresenta il percorso di recupero se un rollout ha già prodotto dati di proprietà di root.