Le applicazioni containerizzate devono essere configurabili senza ricostruire l'immagine — utilizzando variabili di ambiente, file di configurazione e gestione appropriata dei segreti. Gestire correttamente la configurazione e i segreti è importante per la sicurezza e per eseguire la stessa immagine in ambienti diversi.
docker run -e DATABASE_URL=postgres://... -e NODE_ENV=production myapp
docker run --env-file . myapp
# in docker-compose.yml
services:
app:
image: myapp
environment:
- DATABASE_URL=postgres://db:5432/app
env_file: .env
Seguendo i principi twelve-factor, la configurazione proviene dall'ambiente (variabili di ambiente) al runtime — così la STESSA immagine viene eseguita in dev, staging e produzione con config diversa, senza mai ricostruire per ambiente.
⚠️ NEVER put secrets (passwords, API keys, tokens) in the Dockerfile or image layers:
→ image layers are inspectable → secrets can be EXTRACTED (even if "removed" later,
they remain in earlier layers)
→ anyone with the image gets the secrets
→ This is a serious, common security mistake.
✓ RUNTIME environment variables (better than image, but visible in inspect/env)
✓ DOCKER SECRETS (Swarm) / Kubernetes Secrets — mounted securely at runtime
✓ Secrets MANAGERS — HashiCorp Vault, AWS Secrets Manager, etc. (fetch at runtime)
✓ BuildKit build secrets (--secret) — for build-time secrets without baking into layers
✓ Keep .env files OUT of version control (.gitignore) and out of the image (.dockerignore)
Gestire correttamente la configurazione e i segreti in Docker è importante sia per la sicurezza che per la flessibilità operativa, quindi è una conoscenza pratica preziosa.
Il principio di configurazione — fornire la config tramite variabili di ambiente al runtime piuttosto che incorporarla nell'immagine (seguendo i principi twelve-factor) — è importante perché consente alla stessa immagine di essere eseguita in tutti gli ambienti (dev, staging, produzione) con configurazioni diverse, senza mai ricostruire per ambiente, il che è fondamentale per deployment riproducibili, portabili e una pratica containerizzazione core.
Più criticamente, la gestione dei segreti è una questione di sicurezza seria: la regola fondamentale — non incorporare mai segreti (password, chiavi API, token) nelle immagini — è essenziale perché i layer dell'immagine sono ispezionabili e i segreti incorporati in essi possono essere estratti (e rimangono nei layer precedenti anche se "rimossi" dopo), quindi chiunque abbia l'immagine ottiene i segreti; questo è un errore comune e pericoloso che causa fughe di credenziali reali.
Comprendere la gestione appropriata dei segreti — variabili di ambiente al runtime (migliore, anche se visibili in inspect), meccanismi di segreti dedicati (Docker/Kubernetes Secrets montati in modo sicuro, gestori di segreti come Vault o AWS Secrets Manager recuperati al runtime, segreti di build di BuildKit per esigenze di build-time), e mantenere i file .env fuori dal version control e dalle immagini — è necessario per gestire i segreti in modo sicuro.
Poiché eseguire la stessa immagine in ambienti diversi (tramite config basata su env) e proteggere i segreti (non incorporarli nelle immagini) sono entrambi importanti per deployment containerizzati sicuri e flessibili, e poiché la cattiva gestione dei segreti è un fallimento di sicurezza serio e comune, comprendere la gestione della configurazione e dei segreti in Docker — configurazione basata su ambiente e gestione appropriata dei segreti — è una conoscenza preziosa, praticamente importante per distribuire container in modo sicuro e flessibile, con l'aspetto dei segreti in particolare che è una conoscenza di sicurezza critica che previene l'esposizione reale di credenziali.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona