Table of Contents

I contenitori Docker hanno rivoluzionato la distribuzione moderna delle applicazioni fornendo ambienti leggeri, portatili ed efficienti per l'esecuzione del software. Le organizzazioni adottano sempre più la containerizzazione per ottimizzare i flussi di lavoro di sviluppo e di distribuzione, la sicurezza di questi contenitori è diventata una preoccupazione critica. I contenitori Misconfigured e le immagini esposte sono tra le principali cause di violazioni dei dati cloud e Docker semplifica lo sviluppo e lo spiegamento, amplia anche la superficie di attacco.

Comprendere i principi fondamentali di sicurezza del contenitore Docker

Docker ha una propria serie di sfide di sicurezza, e garantire la sicurezza dei contenitori Docker non è solo una questione di fortificare l'applicazione, ma comporta un approccio completo che comprende l'intero ecosistema. Prima di implementare specifiche misure di sicurezza, è essenziale capire il modello di sicurezza di Docker e come differisce dagli approcci di virtualizzazione tradizionali.

Architettura di sicurezza di Docker

L'approccio di Docker alla sicurezza è distinto dai metodi di virtualizzazione tradizionali, principalmente per la sua dipendenza dal kernel OS host. Docker sfrutta i namespace del kernel per l'isolamento del processo.

I contenitori Docker sono leggeri e portatili, ma condividono il kernel del sistema operativo host, creando sfide di sicurezza uniche. Capire questo modello di kernel condiviso è fondamentale perché le vulnerabilità del kernel host possono influenzare tutti i contenitori che funzionano su quel sistema.

Ogni contenitore ottiene anche la propria pila di rete, il che significa che un contenitore non ottiene l'accesso privilegiato alle prese o interfacce di un altro contenitore. Naturalmente, se il sistema host è configurato di conseguenza, i contenitori possono interagire tra loro attraverso le rispettive interfacce di rete - proprio come possono interagire con gli host esterni.

Il modello di responsabilità condivisa

La sicurezza di Docker comporta l'offerta di funzionalità come Docker Compose, namespaces e Docker Content Trust (DCT) per migliorare la sicurezza, utilizzando configurazioni sicure per il tempo di esecuzione dei container, reti e storage, la scansione regolare delle immagini dei container e l'affrontare le vulnerabilità note, e il monitoraggio delle attività di runtime e l'implementazione dei controlli di accesso basati sul ruolo (RBAC) per limitare l'accesso non autorizzato.

Gli utenti che non riescono a indurire i loro ambienti o mantenere i loro componenti aggiornati sono particolarmente a rischio di sfruttamento. Le organizzazioni devono capire che Docker fornisce gli strumenti e la piattaforma, ma l'attuazione delle misure di sicurezza è la responsabilità dei team di sviluppo e di gestione.

Migliori pratiche essenziali per il deposito dei contenitori Docker

La sicurezza del contenitore non è un singolo strumento o un controllo di una volta sola. È un insieme di pratiche stratificato attraverso l'intero pipeline — dal Dockerfile che scrivi, al CI che lo costruisce, al runtime che lo esegue.

Utilizzare immagini di base mini e affidabili

Le immagini ufficiali e indurite sono punti di partenza più sicuri. La scelta dell'immagine di base influisce significativamente sulla posizione di sicurezza del vostro contenitore. Le immagini più grandi contengono più pacchetti, librerie e potenziali vulnerabilità che gli attaccanti potrebbero sfruttare.

Alpine contiene meno pacchetti, che riducono i CVE e migliora i risultati di scansione. Considerate l'utilizzo di immagini distroless o Alpine Linux come immagini di base per minimizzare la superficie di attacco. Le immagini distroless contengono solo la vostra applicazione e le sue dipendenze runtime, escludendo i gestori di pacchetti, le conchiglie e altre utilità che non sono necessarie per la produzione.

Utilizzando le immagini ufficiali Docker è fondamentale per mantenere la sicurezza, in quanto queste immagini sono regolarmente aggiornate e patchate da entità affidabili. Questo approccio riduce significativamente il rischio di distribuire contenitori con vulnerabilità esistenti o codice dannoso.

Pin Image Versioni ed evitare gli ultimi Tags

L'utilizzo di più recenti rende le build imprevedibili. Può tirare una versione aggiornata che introduce le modifiche o le vulnerabilità di rottura senza preavviso. Invece di utilizzare il latest] tag, sempre pin versioni specifiche di immagini di base utilizzando i loro tag digeribili o versione.

Quando si specifica una versione esatta o digerisce, si garantisce che le proprie costruzioni utilizzeranno ogni volta la stessa immagine di base, rendendo più facile tracciare le vulnerabilità e gestire gli aggiornamenti sistematicamente.

# Bad practice
FROM node:latest

# Good practice - pin specific version
FROM node:18.16.0-alpine

# Best practice - use digest for immutability
FROM node:18.16.0-alpine@sha256:a1e4e58...

Eseguire i contenitori come utenti non-rot

È una pratica migliore Dockerfile per evitare di eseguire contenitori come root (UID 0). Ci sono pochissimi casi di utilizzo in cui il contenitore deve eseguire come root, quindi non dimenticare di includere l'istruzione USER per cambiare l'UID efficace di default.

Eseguire come non-root potrebbe richiedere un paio di passi aggiuntivi nel Dockerfile, come ora è necessario assicurarsi che l'utente specificato nell'istruzione USER esiste all'interno del contenitore e fornire autorizzazioni di file system appropriate nelle posizioni in cui il processo sarà la lettura o la scrittura.

FROM alpine:3.18

# Create a non-root user
RUN addgroup -g 1000 appgroup &&
 adduser -D -u 1000 -G appgroup appuser

# Set ownership of application directories
RUN chown -R appuser:appgroup /app

# Switch to non-root user
USER appuser

WORKDIR /app
COPY --chown=appuser:appgroup . .

CMD ["./myapp"]

Inoltre, il vostro ambiente di esecuzione potrebbe bloccare i contenitori in esecuzione come root per impostazione predefinita (cioè, Openshift richiede ulteriori vincoli di contesto di sicurezza).

Implementa solo i sistemi di file

Eseguire con filesystem root di sola lettura in cui --read-only rende l'intero filesystem del contenitore in sola lettura e --tmpfs fornisce directory in-memory writable per esigenze di runtime.

Ricorda quando fai un contenitore solo per la lettura, l'app non può più scrivere su disco. Se l'app deve scrivere file temporanei (come log o cache), è necessario montare un volume temporaneo.

docker run -d
 --read-only
 --tmpfs /tmp:rw,noexec,nosuid,size=64m
 --tmpfs /var/run:rw,noexec,nosuid,size=32m
 nginx:alpine

Per applicazioni che richiedono un'archiviazione persistente, utilizzare i volumi denominati per directory specifiche mantenendo il filesystem root in sola lettura.

Goccia Capacità di Linux non necessarie

Le capacità di trasformare la dicotomia binaria "root/non-root" in un sistema di controllo dell'accesso a grana fine. I processi (come i server web) che devono solo legare su una porta inferiore al 1024 non hanno bisogno di eseguire come root: possono essere concessi invece alla capacità net bind service. E ci sono molte altre capacità, per quasi tutte le aree specifiche in cui i privilegi root sono di solito necessari.

La migliore pratica per gli utenti sarebbe quella di rimuovere tutte le funzionalità tranne quelle esplicitamente richieste per i loro processi. Le funzionalità Linux sono autorizzazioni in grana fine che sostituiscono il vecchio root/non-root binario. Docker dà ai contenitori un set predefinito che la maggior parte delle applicazioni non hanno bisogno.

docker run -d
 --cap-drop=ALL
 --cap-add=NET_BIND_SERVICE
 --security-opt=no-new-privileges:true
 myapp:latest

La bandiera non-nuove-privilegi[[]] impedisce ai processi di ottenere privilegi aggiuntivi attraverso binari setuidi o setgidi, aggiungendo un altro strato di protezione contro gli attacchi di escalation privilegi.

Strategie di progettazione di sicurezza avanzate

Gran parte di questo overhead può essere impedito spostando la sicurezza sinistra, affrontando i potenziali problemi il prima possibile nel flusso di lavoro di sviluppo.

Scansione immagine del contenitore di implementazione

In un condotto sicuro, la scansione di vulnerabilità Docker dovrebbe essere un passo obbligatorio del processo CI/CD e qualsiasi immagine dovrebbe essere scansionata e approvata prima di entrare mai nello stato "Running" nei cluster di produzione.

Diversi potenti strumenti sono disponibili per la scansione Immagini Docker:

  • Trivy: Uno scanner di vulnerabilità all-in-one per immagini dei container, filesystem e repository Git. È popolare per la sua semplicità, velocità e larghezza di copertura, incluso il supporto per la scansione Infrastructure come modelli di codice (IaC) e dipendenze delle applicazioni.
  • Docker Scout[]: Integrato nel Docker Desktop e nel Docker CLI. Fornisce informazioni sulle vulnerabilità, sintesi CVE e link diretti alla guida di risanamento.
  • Anchore Engine[: Uno strumento di scansione delle immagini Docker open source che ispeziona le immagini dei container per vulnerabilità, problemi di configurazione e violazioni delle policy.
  • Snyk Container[]: Uno scanner di vulnerabilità che si integra con le tubazioni CI/CD per rilevare e correggere automaticamente le vulnerabilità.
  • Clair[]: Scansiona le immagini dei container per le vulnerabilità note elencate in database come le vulnerabilità comuni e le esposizioni (CVE) database.

Prima di spingere le immagini, si dovrebbe sempre scansionarle per le vulnerabilità. Strumenti come Trivy rendono questo semplice.

# Scan an image with Trivy
trivy image myapp:latest

# Scan and fail on high/critical vulnerabilities
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latest

Generare e mantenere le fatture di software dei materiali (SBOM)

Una SBOM ti fornisce un inventario completo di tutto ciò che hai dentro il tuo contenitore. Quando il prossimo giorno zero scende, puoi controllare immediatamente se sei interessato. L'EU Cyber Resilience Act (settembre 2026) invierà la generazione SBOM per tutti i software venduti nel mercato UE - questo non è più un bel-essere.

SBOM Generation crea una Software Bill of Materials (SBOM) per ogni immagine, dettagliando tutti i componenti, le librerie e le dipendenze per la trasparenza e la gestione delle vulnerabilità.

Grype supporta le fatture software di scansione dei materiali (SBOMs). Un SBOM fornisce un database di tutti i metadati, componenti, librerie e pacchetti che compongono un contenitore.

Abilitare la fiducia dei contenuti e la firma di immagini

Docker Engine può essere configurato solo per eseguire immagini firmate. La funzione di verifica della firma del Docker Content Trust è integrata direttamente nel binario dockerd. Questo assicura che le immagini non siano state manomesse e provengano da fonti attendibili.

Cosign v3 (current: v3.0.5) predefinisce la verifica senza chiave attraverso il registro di certificazione e trasparenza di Sigstore. Questo è più semplice e più sicuro di gestire le chiavi di firma da soli.

# Enable Docker Content Trust
export DOCKER_CONTENT_TRUST=1

# Sign an image with Cosign
cosign sign myregistry.io/myapp:v1.0.0

# Verify a signed image
cosign verify myregistry.io/myapp:v1.0.0

La firma dell'immagine fornisce la prova crittografica dell'autenticità e dell'integrità, proteggendo dagli attacchi della catena di fornitura, dove gli attori dannosi potrebbero iniettare immagini compromesse nel registro.

Segmentazione e isolamento della rete di attuazione

La segmentazione di rete è una strategia critica di difesa-in-profondità che limita il raggio di esplosione di potenziali violazioni di sicurezza. isolando i contenitori in reti separate in base alla loro funzione e al livello di fiducia, è possibile prevenire il movimento laterale da parte degli aggressori.

Creare reti Docker personalizzate per diversi livelli di applicazione:

# Create isolated networks
docker network create --driver bridge frontend-net
docker network create --driver bridge backend-net
docker network create --driver bridge database-net

# Run containers on specific networks
docker run -d --name web --network frontend-net nginx:alpine
docker run -d --name api --network backend-net myapi:latest
docker run -d --name db --network database-net postgres:14

# Connect API to both frontend and backend networks
docker network connect frontend-net api

Docker Engine 28 ha affrontato un problema relativo: le porte dei container non pubblicate sono bloccate dall'accesso alla rete per impostazione predefinita, evitando l'esposizione accidentale di servizi che non dovrebbero essere accessibili dalla rete.

Utilizzare le politiche di rete negli ambienti Kubernetes per limitare ulteriormente il traffico tra i pods. Definire le regole di ingresso e di egresso che consentono esplicitamente solo i percorsi di comunicazione necessari.

Applicare i profili di sicurezza Runtime

I profili di sicurezza Runtime forniscono ulteriori livelli di protezione limitando ciò che i contenitori possono fare durante l'esecuzione.

Profili Seccomp

Seccomp (Secure Computing Mode) filtra le chiamate di sistema che i contenitori possono fare al kernel. Limitando le chiamate di sistema disponibili, si riduce la superficie di attacco in modo significativo.

# Run container with custom seccomp profile
docker run --security-opt seccomp=/path/to/seccomp-profile.json myapp:latest

Profili per AppArmor

Caricare il profilo AppArmor e gestire il contenitore con il profilo AppArmor. AppArmor fornisce il controllo obbligatorio dell'accesso limitando le funzionalità dei programmi con profili per-programma.

# Load AppArmor profile
sudo apparmor_parser -r /etc/apparmor.d/docker-webapp

# Run container with AppArmor
docker run --security-opt apparmor=docker-webapp myapp:latest

Integrazione SELinux

SELinux Integration fornisce un ulteriore livello di sicurezza, rafforzando i controlli obbligatori di accesso sui container e le loro interazioni con il sistema host.

Gestione dei segreti e protezione dei dati sensibili

I segreti di codifica rigidi nelle immagini o nelle variabili ambientali sono uno degli errori più comuni che gli sviluppatori fanno. Dobbiamo memorizzare e iniettare segreti in modo sicuro. La corretta gestione dei segreti è fondamentale per mantenere la sicurezza delle applicazioni containerizzate.

Non incorporare mai i segreti nelle immagini

Le password, le chiavi API e i gettoni non devono mai essere memorizzati all'interno dell'immagine, all'interno delle variabili ambientali esposte nei registri o nei repository Git. Invece, assicurarle come segreti Docker, segreti Kubernetes o volte esterne (AWS Secrets Manager, HashiCorp Vault) devono essere utilizzati.

Errori comuni da evitare:

  • credenziali di Hardcoding in Dockerfiles
  • Commettere file .env con segreti per il controllo della versione
  • Passare segreti come argomenti di costruzione (mangono nella storia dell'immagine)
  • Esponere segreti nelle variabili ambientali visibili nei log

Utilizzare i segreti Docker per la modalità Swarm

Docker Swarm include la gestione dei segreti nativi che crittografa i segreti a riposo e in transito.

# Create a secret
echo "my-db-password" | docker secret create db_password -

# Use secret in service
docker service create
 --name myapp
 --secret db_password
 myapp:latest

All'interno del contenitore, i segreti vengono montati come file in [/run/secrets/[], rendendoli accessibili solo al processo del contenitore senza esporre in variabili ambientali o log.

Integrare le soluzioni di gestione dei segreti esterni

Hashicorp Vault: Uno strumento di gestione dei segreti centralizzato che può essere utilizzato per memorizzare e gestire in modo sicuro i segreti negli ambienti dei container.

Le opzioni più richieste includono:

  • HashiCorp Vault[[]: Fornisce segreti dinamici, crittografia come servizio e registri di audit dettagliati
  • AWS Secrets Manager[]: Integrazione nativa con i servizi AWS e rotazione automatica
  • Azure Key Vault[: Gestione centralizzata dei segreti per i carichi di lavoro Azure
  • Google Secret Manager[]: archiviazione sicura per le chiavi API, password e certificati in GCP

Mentre Docker Secrets generalmente fornisce un modo sicuro per gestire i dati sensibili negli ambienti Docker, questo approccio non è raccomandato per Kubernetes, dove i segreti vengono memorizzati in chiaro di default.

Sicurezza e manutenzione del sistema host

Per proteggere dalle vulnerabilità note di fuga dei container come Leaky Vessels, che tipicamente portano all'attaccante che ottiene l'accesso root all'host, è vitale mantenere sia l'host che Docker fino ad oggi.

Tenere i sistemi aggiornati e patch

Se il kernel dell'host è vulnerabile, i contenitori sono anche vulnerabili. Ad esempio, il kernel sfrutta l'escalation del privilegio del kernel, Dirty COW, eseguito all'interno di un contenitore ben isolato, potrebbe ancora causare l'accesso root a un host vulnerabile.

I motori di runtime del contenitore come Docker aggiornano frequentemente il loro software con correzioni e caratteristiche. È possibile mitigare le vulnerabilità applicando gli ultimi aggiornamenti.

Eseguire docker tirare una volta e dimenticare su di esso significa di spedizione immagini con vulnerabilità mesi-vecchi. Automatizzare gli aggiornamenti con Renovate Bot immagine contenitore datasource - crea PR quando le immagini di base hanno aggiornamenti, coppie con il vostro CI scansione pipeline per la riparazione automatica.

Accesso e autenticazione host sicuri

Tutte le autenticazione direttamente al sistema operativo devono essere verificate e registrate. È necessario concedere l'accesso agli utenti appropriati e utilizzare i tasti per i login remoti. E si dovrebbe implementare i firewall e consentire l'accesso solo su reti di fiducia.

Le migliori pratiche per la sicurezza degli host includono:

  • Disattivare l'autenticazione password per SSH, utilizzare l'autenticazione basata su chiave
  • Autenticazione multifattore per accesso privilegiato
  • Utilizzare host di bastione o server di salto per l'accesso ai sistemi di produzione
  • Abilitare il log di audit per tutte le azioni amministrative
  • Limitare l'accesso di Presa Docker daemon agli utenti autorizzati solo

Non esporre mai il Docker Daemon Socket

Questa è una cattiva pratica che si dovrebbe evitare perché un aggressore sarebbe in grado di eseguire qualsiasi comando che il servizio Docker può eseguire e potenzialmente ottenere l'accesso all'intero sistema host perché il servizio Docker funziona come root.

Montare la presa Docker ([]/var/run/docker.sock[[]) all'interno di un contenitore dà a quel contenitore il pieno controllo sul daemon Docker, garantendo efficacemente l'accesso root all'host.

  • Usando Docker-in-Docker (DinD) con un corretto isolamento
  • Attuazione della modalità Docker senza radice
  • Utilizzo di API di runtime container con autorizzazioni limitate
  • Sfruttando Kubernetes CRI invece di accedere direttamente a Docker

Eseguire Docker in modalità senza radici

Rootless Docker consente di eseguire il demone Docker e i contenitori come utente non root, riducendo significativamente l'impatto delle potenziali vulnerabilità di rottura dei container.

# Install rootless Docker
dockerd-rootless-setuptool.sh install

# Run Docker commands as non-root user
docker run -d nginx:alpine

Mentre la modalità rootless fornisce una maggiore sicurezza, ha alcune limitazioni, come le capacità di rete limitate e le considerazioni sulle prestazioni.

Monitoraggio e rilevamento della sicurezza runtime

La sicurezza statica cattura i problemi prima dell'implementazione. La sicurezza Runtime cattura ciò che accade dopo. Anche se le immagini sono sicure, i contenitori possono ancora essere attaccati a runtime. L'implementazione del monitoraggio della sicurezza runtime è essenziale per rilevare e rispondere alle minacce in ambienti di produzione.

Strumenti di sicurezza di runtime di distribuzione

Falco 0.43.0 (gennaio 2026) — Rileva le siscall anomale, l'accesso ai file e le connessioni di rete. La nuova iniziativa drop-enter ha rimosso syscall entrare eventi dal gasdotto, migliorando notevolmente le prestazioni. La sonda eBPF legacy è deprecata a favore del driver eBPF moderno.

Falco è uno strumento di sicurezza open source runtime che utilizza eBPF per monitorare il comportamento dei container e rilevare attività sospette.

  • Esecuzione di processo inaspettata
  • Modifiche non autorizzate dei file
  • Connessioni di rete sontuose
  • Privilege escalation tentativi
  • Depilazione di conchiglia in contenitori
# Example Falco rule for detecting shell in container
- rule: Shell Spawned in Container
 desc: Detect shell process started in container
 condition: >
 spawned_process and
 container and
 proc.name in (bash, sh, zsh)
 output: >
 Shell spawned in container (user=%user.name container=%container.name
 shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
 priority: WARNING

Implementazione Registrazione e Monitoraggio completi

Gli eventi Docker forniscono un flusso di audit nativo per il ciclo di vita dei container, Prometheus + cAdvisor tracciano il tracciamento delle risorse per il contenitore.

Stabilire una strategia di registrazione completa che cattura:

  • Container logs[: Emissione di applicazioni e messaggi di errore
  • log diemon del docker[: eventi del ciclo di vita del contenitore e operazioni di demonio
  • Host system logs[: messaggi di Kernel ed eventi di sistema
  • log audio[]: eventi rilevanti per la sicurezza e tentativi di accesso

Centralizzare i log utilizzando strumenti come lo stack ELK (Elasticsearch, Logstash, Kibana), Loki con Grafana, o soluzioni cloud-native come AWS CloudWatch o Azure Monitor.

# Configure Docker to use JSON file logging driver with rotation
{
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "10m",
 "max-file": "3",
 "labels": "production_status",
 "env": "os,customer"
 }
}

Impostare i limiti delle risorse per prevenire attacchi DoS

Senza vincoli di risorse, un contenitore compromesso o ingannevole potrebbe consumare tutte le risorse disponibili, che interessano altri contenitori e l'host.

# Docker Compose with resource limits
version: "3.9"
services:
 app:
 image: myapp:latest
 deploy:
 resources:
 limits:
 cpus: "2.0"
 memory: 512M
 pids: 100
 reservations:
 cpus: "0.5"
 memory: 256M
 ulimits:
 nofile:
 soft: 65536
 hard: 65536
 nproc:
 soft: 100
 hard: 200

I limiti delle risorse devono essere fissati in base ai requisiti applicativi e alla pianificazione delle capacità. Monitorare l'utilizzo effettivo delle risorse per sintonizzare tali limiti in modo appropriato, assicurando che i contenitori dispongano di risorse sufficienti, evitando gli attacchi di esaurimento delle risorse.

Integrazione di sicurezza CI/CD Pipeline

Le tubazioni CI/CD sono una parte cruciale del ciclo di vita dello sviluppo software e dovrebbero includere vari controlli di sicurezza come i controlli lint, l'analisi del codice statico e la scansione dei container. Molti problemi possono essere evitati seguendo alcune best practice quando si scrive il Dockerfile. Tuttavia, l'aggiunta di un linter di sicurezza come un passo nella pipeline di costruzione può andare molto lontano per evitare ulteriori mal di testa.

Implement Dockerfile Linting

Dockerfile linters analizza i tuoi Dockerfile per errori comuni, problemi di sicurezza e migliori violazioni di pratica prima che le immagini siano costruite.

# Run Hadolint on Dockerfile
docker run --rm -i hadolint/hadolint < Dockerfile

# Example output showing issues
DL3008: Pin versions in apt get install
DL3009: Delete the apt-get lists after installing
DL3015: Avoid additional packages by specifying --no-install-recommends

Automatizzare la scansione di sicurezza in CI/CD

Gli strumenti di scansione del contenitore sono particolarmente importanti come parte di una strategia di sicurezza di successo. Possono rilevare vulnerabilità note, segreti e disconfigurazioni nelle immagini dei container e fornire un rapporto dei risultati con raccomandazioni su come risolverli.

Integrando Docker Scout nel vostro canale CI/CD, vi permette di verificare automaticamente che le immagini realizzate da Docker Hardened Images rimangano libere dalle vulnerabilità note durante il processo di costruzione.

# GitHub Actions workflow example
name: Container Security Scan

on:
 push:
 branches: [ main ]
 pull_request:
 branches: [ main ]

jobs:
 security-scan:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3

 - name: Build image
 run: docker build -t myapp:${{ github.sha }} .

 - name: Run Trivy vulnerability scanner
 uses: aquasecurity/trivy-action@master
 with:
 image-ref: myapp:${{ github.sha }}
 format: 'sarif'
 output: 'trivy-results.sarif'
 severity: 'CRITICAL,HIGH'
 exit-code: '1'

 - name: Upload Trivy results to GitHub Security
 uses: github/codeql-action/upload-sarif@v2
 if: always()
 with:
 sarif_file: 'trivy-results.sarif'

 - name: Push image if scan passes
 if: success()
 run: |
 docker tag myapp:${{ github.sha }} myregistry.io/myapp:latest
 docker push myregistry.io/myapp:latest

Politica di attuazione

L'applicazione delle policy garantisce che solo le immagini conformi siano distribuite alla produzione. Strumenti come Open Policy Agent (OPA) e Kyverno possono applicare automaticamente le politiche organizzative.

Le politiche comuni per far rispettare includono:

  • Le immagini devono essere scansionate e non hanno vulnerabilità critiche
  • Le immagini devono essere firmate dalle autorità di fiducia
  • I container devono essere gestiti come utenti non root
  • I contenitori non devono usare la modalità privilegiata
  • I limiti di risorse devono essere definiti
  • Le immagini devono provenire da registri approvati

Considerazioni di sicurezza specifiche

La sicurezza dei Kubernetes diventa vitale quando si gestisce i cluster. I controlli di accesso basati sul ruolo (RBAC) o le dashboard esposte aumentano il rischio.

Implement Pod Standard di sicurezza

Kubernetes Pod Security Standards definisce tre livelli di politiche di sicurezza: Privileged, Baseline e Restricted. La politica Restricted applica i requisiti di sicurezza più rigorosi e dovrebbe essere utilizzato per i carichi di lavoro di produzione ogni volta che possibile.

apiVersion: v1
kind: Pod
metadata:
 name: secure-app
 labels:
 app: myapp
spec:
 securityContext:
 runAsNonRoot: true
 runAsUser: 1000
 fsGroup: 1000
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: app
 image: myapp:latest
 securityContext:
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 capabilities:
 drop:
 - ALL
 runAsNonRoot: true
 runAsUser: 1000
 resources:
 limits:
 cpu: "1"
 memory: "512Mi"
 requests:
 cpu: "100m"
 memory: "128Mi"
 volumeMounts:
 - name: tmp
 mountPath: /tmp
 volumes:
 - name: tmp
 emptyDir: {}

Configurare le policy di rete

Le politiche di rete Kubernetes forniscono un controllo accurato sulla comunicazione pod-to-pod. Per impostazione predefinita, tutti i pod possono comunicare tra loro, che viola il principio di minimo privilegio.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: api-network-policy
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: api
 policyTypes:
 - Ingress
 - Egress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 app: frontend
 ports:
 - protocol: TCP
 port: 8080
 egress:
 - to:
 - podSelector:
 matchLabels:
 app: database
 ports:
 - protocol: TCP
 port: 5432

Utilizzare i controller di ammissione

I controller di ammissione intercettano le richieste al server API Kubernetes prima che gli oggetti siano perseverati, permettendoti di applicare le policy e convalidare le configurazioni.

Esempio di politiche da attuare:

  • Richiedere tutte le immagini per venire da registri approvati
  • Limiti di risorse su tutti i contenitori
  • Evitare che i contenitori privilegiati vengano creati
  • Richiedere etichette specifiche su tutte le risorse
  • Convalidare i contesti di sicurezza soddisfano i requisiti minimi

Considerazioni di conformità e regolamentazione

Le organizzazioni operanti nelle industrie regolamentate devono garantire che le loro distribuzioni dei container soddisfino requisiti specifici di conformità.

  • CIS Docker Benchmark[[]: fornisce una guida prescrittiva per stabilire una posizione di configurazione sicura per Docker
  • CIS Kubernetes Benchmark[[: Raccomandazioni di sicurezza per le implementazioni Kubernetes
  • PCI DSS[]: Requisiti per le organizzazioni che gestiscono i dati della carta di pagamento
  • HIPAA[]: Standard per la protezione delle informazioni sensibili sulla salute dei pazienti
  • SOC 2[]: Quadro per la gestione dei dati dei clienti basato su cinque principi del servizio di fiducia
  • GDPR[]: Prescrizioni sulla protezione dei dati e sulla privacy per i residenti dell'UE

Strumenti come Docker Bench per la sicurezza e kube-bench possono valutare automaticamente il vostro ambiente contro questi benchmark e fornire una guida di bonifica.

# Run Docker Bench for Security
docker run --rm --net host --pid host --userns host --cap-add audit_control
 -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST
 -v /var/lib:/var/lib
 -v /var/run/docker.sock:/var/run/docker.sock
 -v /usr/lib/systemd:/usr/lib/systemd
 -v /etc:/etc --label docker_bench_security
 docker/docker-bench-security

# Run kube-bench for Kubernetes
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Contenitore di sicurezza

I registri dei container sono componenti critici della catena di approvvigionamento dei container. La gestione dei registri impedisce l'accesso non autorizzato alle immagini e protegge dagli attacchi della supply chain.

Utilizzare Registe private

Mentre i registri pubblici come Docker Hub sono convenienti, i carichi di lavoro di produzione dovrebbero utilizzare i registri privati con i controlli di accesso adeguati.

  • Harbor[]: Registro di sistema open source con scansione delle vulnerabilità, firma delle immagini e RBAC
  • Cfr[]]: Registro di sistema integrato con i servizi AWS
  • Registro dei contenitori di Azure[]: Registro di sistema gestito per i carichi di lavoro di Azure
  • Google Container Registry[]: Registro di sistema GCP gestito
  • JFrog Artifactory[: Repositore universale per artefatti con funzionalità di sicurezza avanzate

Controllo di accesso del Registro di implementazione

Configurare l'autenticazione e l'autorizzazione per l'accesso al registro:

  • Utilizzare account di servizio con autorizzazioni minime per le tubazioni CI/CD
  • Controllo di accesso basato sul ruolo di implementazione (RBAC) per diverse squadre
  • Abilita il log di audit per tutte le operazioni del Registro di sistema
  • Utilizzare gettoni di breve durata invece di credenziali a lungo termine
  • Implementa l'IP whitelisting per l'accesso al registro

Abilitare la scansione automatica della vulnerabilità

Docker Hub consente di eseguire sia la scansione di vulnerabilità statica point-in-time o l'analisi di immagini sempre aggiornata utilizzando Docker Scout. Dopo aver acceso l'analisi delle immagini Docker Scout, Docker Scout analizza automaticamente le immagini nel repository Docker Hub.

La maggior parte dei registri moderni offrono una scansione integrata delle vulnerabilità che esegue la scansione automatica delle immagini quando vengono spinte.

  • Scansione di tutte le immagini automaticamente su spinta
  • Immagini in continuo recupero per vulnerabilità appena scoperte
  • Bloccare l'implementazione delle immagini con vulnerabilità critiche
  • Invia notifiche quando vengono rilevate vulnerabilità
  • Fornire una guida di bonifica per i problemi identificati

Risposta e recupero incidenti

Nonostante l'attuazione di misure di sicurezza complete, possono ancora verificarsi incidenti. Avere un piano di risposta incidente ben definito è fondamentale per ridurre i danni e recuperare rapidamente.

Sviluppare un piano di risposta incidente

Il piano di risposta degli incidenti dovrebbe includere:

  • Detection: Meccanismi per l'identificazione degli incidenti di sicurezza attraverso il monitoraggio e l'avviso
  • Containment]: Procedure per isolare i contenitori colpiti e prevenire la diffusione
  • Indagine[]: passi per analizzare l'incidente e determinare la causa principale
  • Eradication[]: Processi per la rimozione delle minacce e la chiusura delle vulnerabilità
  • Recupero[]: Procedure per il ripristino dei servizi e la convalida della sicurezza
  • Rivista attuale[]: Analisi di ciò che è successo e come prevenire la ricorrenza

Capacità di forensi del contenitore di implementazione

La forense del contenitore può essere impegnativa a causa della natura effimera dei contenitori.

  • Conservare lo stato del contenitore creando istantanee prima della terminazione
  • Mantenere registri completi con periodi di conservazione sufficienti
  • Utilizzare infrastrutture immutabili per prevenire la manomissione delle prove
  • Implementa il log per tutte le operazioni di container
  • Mantenere la provenienza dell'immagine e costruire la storia

Pratica Disaster Recovery

Testare regolarmente le procedure di recupero disastri:

  • Condurre esercizi da tavolo simulando incidenti di sicurezza
  • Test di backup e ripristino delle procedure per i dati dei container
  • Convalida che è possibile ricostruire gli ambienti da zero
  • Assicurare la documentazione è attuale e accessibile
  • I membri del team di treno sulle procedure di risposta agli incidenti

Lista di controllo di sicurezza per i dislocamenti di produzione

Inizia con gli elementi ad alto impatto: immagini minimali, utenti non root, scansione CI e digerisci pinning.Stimolazione in runtime, segmentazione di rete e gestione dei segreti. Utilizzare questa lista di controllo completa per garantire che i contenitori Docker soddisfino i requisiti di sicurezza prima dell'implementazione della produzione:

Sicurezza dell'immagine

  • Utilizzare immagini di base minime (Alpine, distroless)
  • Perno specifiche versioni di immagine utilizzando digestivi
  • Scansione delle immagini per vulnerabilità in CI/CD pipeline
  • Firma immagini con Docker Content Trust o Cosign
  • Generare e mantenere SBOM per tutte le immagini
  • Rimuovere pacchetti e file non necessari
  • Utilizzare le costruzioni multistadio per ridurre al minimo le dimensioni dell'immagine finale
  • Non includere mai segreti in immagini

Contenitore sicurezza Runtime

  • Eseguire contenitori come utenti non root
  • Utilizzare i filesystem root di sola lettura
  • Getta tutte le funzionalità e aggiungi solo quelle richieste
  • Abilitare la bandiera senza nuovi privilegi
  • Applicare profili a secco, AppArmor o SELinux
  • Impostare i limiti delle risorse (CPU, memoria, PID)
  • Segmentazione della rete di attuazione
  • Utilizzare reti private per la comunicazione intercontainer

Sicurezza host e infrastrutture

  • Tenere aggiornato il sistema operativo host e il kernel
  • Aggiornare Docker Engine regolarmente
  • Mai esporre Docker presa di demonio
  • Utilizzare Docker senza radici quando possibile
  • Implementare firewall basati su host
  • Attivare il loggging di audit
  • Limitare l'accesso SSH con l'autenticazione basata su chiave
  • Utilizzare i bastion host per l'accesso alla produzione

Gestione dei segreti e delle configurazioni

  • Utilizzare Docker Secrets o volte esterne
  • Non sono mai le credenziali di codice
  • Ruotare regolarmente i segreti
  • Utilizzare gettoni e credenziali di breve durata
  • Crittografia segreti a riposo e in transito
  • Accesso segreto Audit

Monitoraggio e registrazione

  • Monitoraggio della sicurezza a tempo di esecuzione dell'esecuzione (Falco)
  • Centralizzare i registri da tutti i contenitori
  • Abilita il montaggio di Docker daemon
  • Monitorare l'utilizzo delle risorse
  • Impostare avvisi per attività sospette
  • Mantenere la ritenzione di registro sufficiente
  • Percorsi di verifica per l'attuazione della conformità

Sicurezza CI/CD Pipeline

  • Lint Dockerfiles con Hadolint
  • Scansione delle immagini in CI pipeline
  • Fail si basa sulle vulnerabilità critiche
  • Applicazione delle politiche di attuazione
  • Utilizzare registri separati per dev/staging/prod
  • Automatizzare i test di sicurezza
  • Richiedere la revisione del codice per le modifiche Dockerfile

Kubernetes-Specific (se applicabile)

  • Implement Pod Standard di sicurezza
  • Configurare le policy di rete
  • Utilizzare i controller di ammissione per l'applicazione delle politiche
  • Abilitare RBAC con minimo privilegio
  • Proteggere il server API Kubernetes
  • Crittografia dati eccd a riposo
  • Eseguire CIS Kubernetes Benchmark controlli

Tendenze emergenti e considerazioni future

La sicurezza dei container continua ad evolversi con nuove tecnologie e approcci.

Sicurezza della catena di fornitura

Gli incidenti del 2025 — backdoored immagini di base di spedizione per mesi, migliaia di credenziali di produzione trapelate attraverso Dockerfiles — dimostrano che le basi ancora materia. Gli attacchi della catena di fornitura che mirano agli ecosistemi dei container stanno aumentando.

Architettura di Zero Trust

Applicare zero principi di fiducia agli ambienti dei container assumendo la violazione e verificando ogni richiesta. Tecnologie di rete di servizi di implementazione come Istio o Linkerd per fornire l'autenticazione TLS reciproca, l'autorizzazione a grana fine e l'osservanza per la comunicazione container-to-container.

sicurezza basata su eBPF

La tecnologia Extended Berkeley Packet Filter (eBPF) consente un monitoraggio della sicurezza con prestazioni minime in testa. Gli strumenti che sfruttano eBPF possono fornire una visibilità profonda nel comportamento dei container senza richiedere moduli del kernel o modifiche dei container.

Computing confidenziale

Le tecnologie di calcolo confidenziali proteggono i dati in uso eseguendo il calcolo in ambienti di esecuzione affidabili basati su hardware (TEEs), che possono proteggere carichi di lavoro sensibili anche da utenti privilegiati e sistemi host compromessi.

Strumenti e risorse consigliati

Costruire un programma completo di sicurezza dei container richiede di sfruttare gli strumenti giusti. Qui sono le risorse consigliate organizzate per categoria:

Scansione della vulnerabilità

  • Trivy (Apri sorgente): Rapido, completo scanner di vulnerabilità
  • Scopritore[]: Scansione integrata con Docker Desktop e CLI
  • Anchore Engine[] (Open Source): Controllo e conformità basati su criteri
  • Snyk Container: scansione focalizzata sugli sviluppatori con raccomandazioni corrette
  • Clair[] (Fonte aperto): Analisi statica delle vulnerabilità

Sicurezza di runtime

  • Falco (Fonte aperto): Rilevamento delle minacce Runtime tramite eBPF
  • Aqua Security]: piattaforma completa di sicurezza dei container
  • Sysdig Secure[: Sicurezza dei runtime e forense

Politica e conformità

  • Aprire l'agente di politica[] (Fonte aperto):
  • Kyverno[ (Fonte aperto): Gestione delle politiche di Kubernetes-native
  • Biocca per la sicurezza[ (Fonte aperto): Controlli CIS Docker Benchmark
  • kube-bench[ (Fonte aperto): CIS Kubernetes Benchmark controlli

Gestione dei segreti

  • HashiCorp Vault[: Gestione dei segreti aziendali
  • AWS Secrets Manager[]: Segreti nativi per AWS
  • Azure Key Vault[: Gestione dei segreti per Azure
  • Google Secret Manager[]: Gestione dei segreti per GCP

Risorse aggiuntive

Conclusioni

La sicurezza dei container è un processo continuo che copre diversi aspetti, tra cui la creazione di immagini, la gestione segreta, il comportamento di runtime e il monitoraggio continuo. La sicurezza è un processo continuo. Controlla regolarmente le configurazioni, aggiorna le immagini di base e rimane informato sulle nuove vulnerabilità. Lo sforzo che investi nella sicurezza dei container protegge oggi la vostra infrastruttura domani.

L'implementazione di contenitori sicuri Docker richiede un approccio completo e stratificato che affronta la sicurezza in ogni fase del ciclo di vita dei container. Dalla scelta di immagini di base minimali e in esecuzione come utenti non-root per implementare il monitoraggio dei runtime e mantenere la conformità, ogni misura di sicurezza contribuisce a una strategia di difesa-in-profondità robusta.

I contenitori Docker forniscono strumenti potenti per lo sviluppo moderno ma richiedono un'attenta supervisione per garantire che rimangano sicuri. Rivolgendosi ai rischi associati alle immagini Docker, ai privilegi dei container e ai sistemi host, le organizzazioni possono ridurre al minimo la probabilità di violazioni e massimizzare l'affidabilità dei loro ambienti containerizzati.

Automatizza i controlli di sicurezza nelle tubazioni CI/CD, monitora continuamente il comportamento dei runtime, aggiorna regolarmente i componenti e rimane informato sulle minacce emergenti e sulle best practice. Seguindo le strategie e le raccomandazioni delineate in questa guida, è possibile costruire e mantenere applicazioni containerizzate sicure che proteggono i beni della vostra organizzazione, consentendo al contempo l'agilità e l'efficienza che i container forniscono.

Mentre le piattaforme di orchestrazione Docker e container forniscono gli strumenti e le capacità, spetta ai team di sviluppo e di gestione implementare e mantenere costantemente le misure di sicurezza. Investi nell'addestramento del tuo team, stabilisci politiche di sicurezza chiare e adotti una cultura in cui la sicurezza è responsabilità di tutti. Con la giusta combinazione di strumenti, pratiche e vigilanza, puoi sfruttare la piena potenza della containerizzazione mantenendo una forte postura di sicurezza.