Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Best practice per la sicurezza di attività e container di Amazon ECS

L'immagine di container deve essere considerata la prima linea di difesa contro un attacco. Un'immagine non sicura e mal costruita può consentire a un utente malintenzionato di sfuggire ai limiti del container e accedere all'host. Per ridurre questo rischio, effettua le seguenti operazioni.

Quando configuri le attività e i container, tieni in considerazione i suggerimenti elencati di seguito.

Creazione di immagini di base o uso di immagini distroless

Inizia rimuovendo tutti i file binari estranei dall'immagine di container. Se stai utilizzando un'immagine sconosciuta tratta da Amazon ECR Public Gallery, ispezionala per fare riferimento al contenuto di ciascuno dei livelli del container. A tale scopo, puoi utilizzare un'applicazione come Dive.

In alternativa, puoi utilizzare immagini distroless che includono solo l'applicazione e le relative dipendenze di runtime. Non contengono gestori di pacchetti o shell (interprete di comandi). Le immagini distroless migliorano il "rapporto segnale/rumore degli scanner e riducono l'onere di stabilire la provenienza in base alle proprie esigenze". Per ulteriori informazioni, consulta la GitHub documentazione su distroless.

Docker dispone di un meccanismo per creare immagini a partire da un'immagine di base e riservata, nota come scratch. Per ulteriori informazioni, consulta Creazione di una semplice immagine genitore con scratch nella documentazione di Docker. Con linguaggi come Go, puoi creare un file binario collegato statico e farvi riferimento nel Dockerfile. L'esempio seguente mostra come si può ottenere questo risultato.

############################
# STEP 1 build executable binary
############################
FROM golang:alpine AS builder
# Install git.
# Git is required for fetching the dependencies.
RUN apk update && apk add --no-cache git
WORKDIR $GOPATH/src/mypackage/myapp/
COPY . .
# Fetch dependencies.
# Using go get.
RUN go get -d -v
# Build the binary.
RUN go build -o /go/bin/hello
############################
# STEP 2 build a small image
############################
FROM scratch
# Copy our static executable.
COPY --from=builder /go/bin/hello /go/bin/hello
# Run the hello binary.
ENTRYPOINT ["/go/bin/hello"]
This creates a container image that consists of your application and nothing else, making it extremely secure.

L'esempio precedente illustra inoltre una build a più fasi. Questi tipi di build sono interessanti dal punto di vista della sicurezza, perché puoi utilizzarli per ridurre al minimo le dimensioni dell'immagine finale inviata al registro di container. Le immagini di container prive di strumenti di compilazione e altri file binari estranei migliorano il livello di sicurezza, riducendo la superficie di attacco dell'immagine. Per ulteriori informazioni sulle build in più fasi, consulta la sezione Compilazioni in più fasi nel Docker documentazione.

Scansione delle immagini per individuare eventuali vulnerabilità

Analogamente alle loro controparti per macchine virtuali, le immagini di container possono contenere file binari e librerie di applicazioni con vulnerabilità oppure sviluppare vulnerabilità nel corso del tempo. Il modo migliore per proteggersi dagli attacchi è quello di analizzare regolarmente le immagini con uno scanner di immagini.

Le immagini archiviate in Amazon ECR possono essere analizzate mediante invio oppure on demand (una volta ogni 24 ore). La scansione di base di Amazon ECR utilizza Clair, una soluzione di scansione immagini open source. La scansione avanzata di Amazon ECR utilizza Amazon Inspector. Dopo la scansione di un'immagine, i risultati vengono registrati nel flusso di eventi Amazon ECR in Amazon. EventBridge Puoi anche visualizzare i risultati di una scansione dalla console Amazon ECR o chiamando l'DescribeImageScanFindingsAPI. Le immagini con una vulnerabilità HIGH o CRITICAL devono essere eliminate o ricreate. Un'immagine implementata che sviluppa una vulnerabilità deve essere sostituita il prima possibile.

Docker Desktop Edge versione 2.3.6.0 o successiva può effettuare la scansione delle immagini locali. Le scansioni sono gestite da Snyk, un servizio di sicurezza per applicazioni. Quando vengono individuate vulnerabilità, Snyk identifica i livelli e le dipendenze con la vulnerabilità nel Dockerfile. Suggerisce inoltre alternative sicure, come l'uso di un'immagine di base più snella con meno vulnerabilità o l'aggiornamento di un particolare pacchetto a una versione più recente. Utilizzando la scansione di Docker, gli sviluppatori possono risolvere potenziali problemi di sicurezza prima di inviare le immagini al registro.

Rimozione delle autorizzazioni speciali dalle immagini

I flag dei diritti di accesso setuid e setgid consentono l'esecuzione di un file eseguibile con le autorizzazioni del proprietario o del gruppo del file eseguibile. Rimuovi tutti i file binari con tali diritti di accesso dall'immagine, in quanto possono essere utilizzati per eseguire l'escalation dei privilegi. Valuta la possibilità di rimuovere tutti gli shell (interpreti di comandi) e le utilità come nc e curl che possono essere utilizzati per scopi nocivi. Puoi trovare i file con diritti di accesso setuid e setgid utilizzando il comando seguente.

find / -perm /6000 -type f -exec ls -ld {} \;

Per rimuovere le autorizzazioni speciali da tali file, aggiungi la direttiva seguente all'immagine di container.

RUN find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true

Creazione di un set di immagini curate

Invece di consentire agli sviluppatori di creare le proprie immagini, crea un set di immagini controllate per i diversi stack di applicazioni della tua organizzazione. In tal modo, gli sviluppatori possono fare a meno di imparare a comporre Dockerfile e concentrarsi piuttosto sulla scrittura di codice. Man mano che le modifiche vengono incorporate nella base di codice, una pipeline CI/CD può compilare in automatico l'asset e quindi archiviarlo in un repository di artefatti. Infine, copia l'artefatto nell'immagine appropriata prima di inviarlo a un registro Docker come Amazon ECR. Come minimo, dovresti creare un set di immagini di base da cui gli sviluppatori possano creare i propri Dockerfile. È sconsigliabile estrarre immagini da Docker Hub. Non sempre sai che cosa c'è nell'immagine e circa un quinto delle 1.000 immagini principali presenta vulnerabilità. Un elenco di tali immagini e delle relative vulnerabilità è disponibile all'indirizzo https://vulnerablecontainers.org/.

Scansione dei pacchetti e delle librerie di applicazioni per individuare eventuali vulnerabilità

L'uso di librerie open source è ormai comune. Come per i sistemi operativi e i pacchetti OS, le librerie possono presentare vulnerabilità. Nell'ambito del ciclo di vita dello sviluppo, è necessario analizzare e aggiornare queste librerie quando vengono rilevate vulnerabilità critiche.

Docker Desktop esegue scansioni locali utilizzando Snyk. Può anche essere utilizzato per trovare vulnerabilità e potenziali problemi di licenza nelle librerie open source. Grazie alla possibilità di integrarlo direttamente nei flussi di lavoro degli sviluppatori, permette di mitigare i rischi posti dalle librerie open source. Per ulteriori informazioni, consulta i seguenti argomenti:

Esecuzione dell'analisi statica del codice

È consigliabile eseguire l'analisi statica del codice prima di creare un'immagine di container. Viene eseguita sul codice di origine e consente di identificare errori di codifica e codice che potrebbero essere sfruttati da un malintenzionato, come le iniezioni di errori. Puoi usare Amazon Inspector. Per ulteriori informazioni, consulta Scansione delle immagini dei container Amazon ECR con Amazon Inspector nella Amazon Inspector User Guide.

Esecuzione di container come utente non root

È consigliabile eseguire i container come utente non root. Per impostazione predefinita, i container vengono eseguiti come utente root a meno che nel Dockerfile sia inclusa la direttiva USER. Le funzionalità Linux predefinite assegnate da Docker limitano le operazioni che possono essere eseguite come root, ma solo in misura marginale. Ad esempio, un container in esecuzione come root non può comunque accedere ai dispositivi.

Nell'ambito della pipeline CI/CD, è consigliabile eseguire il comando lint sui Dockerfile per cercare la direttiva USER e interrompere la build qualora mancasse. Per ulteriori informazioni, consulta i seguenti argomenti:

Uso di un file system root di sola lettura

È consigliabile utilizzare un file system root di sola lettura. Il file system root di un container è scrivibile per impostazione predefinita. Quando configuri un container con un file system root RO (di sola lettura), ti viene imposto di definire in modo esplicito dove possono essere conservati i dati. Ciò riduce la superficie di attacco, perché non è possibile scrivere sul file system del container a meno che non vengano concesse autorizzazioni specifiche.

Configura attività con limiti di CPU e memoria (Amazon EC2)

È consigliabile configurare attività con limiti di CPU e memoria per ridurre al minimo i seguenti rischi. I limiti di risorse di un'attività stabiliscono un limite massimo per la quantità di CPU e memoria che può essere riservata da tutti i container all'interno di un'attività. Se non vengono impostati limiti, le attività hanno accesso alla CPU e alla memoria dell'host. Ciò può causare problemi per cui le attività implementate su un host condiviso possono privare altre attività delle risorse di sistema.

Uso di tag immutabili con Amazon ECS

Con Amazon ECR, puoi e dovresti preferibilmente configurare immagini con tag immutabili. Ciò impedisce di inviare una versione alterata o aggiornata di un'immagine al tuo archivio di immagini con un tag identico. In questo modo si evita che un utente malintenzionato invii una versione compromessa di un'immagine sull'immagine con lo stesso tag. Utilizzando tag immutabili, ti costringi effettivamente a inviare una nuova immagine con un tag diverso per ogni modifica.

Evita di utilizzare i container come privilegiati (Amazon EC2)

È consigliabile evitare di eseguire i container come privilegiati. In background, i container vengono eseguiti come privileged vengono eseguiti con privilegi estesi sull'host. Ciò significa che il container eredita tutte le funzionalità di Linux assegnate a root sull'host. Il suo uso dovrebbe essere severamente limitato o vietato. Consigliamo di impostare la variabile di ambiente dell'agente di container Amazon ECS ECS_DISABLE_PRIVILEGED su true per evitare che i container vengano eseguiti come privileged su determinati host se l'opzione privileged non è necessaria. In alternativa è possibile utilizzare AWS Lambda per scansionare le definizioni delle attività per verificare l'utilizzo del privileged parametro.

Rimozione delle funzionalità di Linux non necessarie dal container

Di seguito è riportato un elenco delle funzionalità di Linux predefinite assegnate ai container Docker. Per ulteriori informazioni su ciascuna funzionalità, consulta Panoramica delle funzionalità di Linux.

CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL,
CAP_SETGID, CAP_SETUID, CAP_SETPCAP, CAP_NET_BIND_SERVICE, 
CAP_NET_RAW, CAP_SYS_CHROOT, CAP_MKNOD, CAP_AUDIT_WRITE, 
CAP_SETFCAP

Se un container non richiede tutte le funzionalità del kernel Docker elencate sopra, valuta la possibilità di eliminarle dal container. Per ulteriori informazioni su ciascuna funzionalità del kernel Docker, consulta. KernelCapabilities Puoi scoprire quali funzionalità sono in uso completando la procedura seguente:

Uso di una chiave gestita dal cliente (CMK) per la crittografia delle immagini inviate ad Amazon ECR

È consigliabile utilizzare una chiave gestita dal cliente (CMK) per crittografare le immagini inviate ad Amazon ECR. Le immagini inviate ad Amazon ECR vengono automaticamente crittografate quando sono inattive con una chiave gestita AWS Key Management Service (AWS KMS). Se preferisci usare la tua chiave, Amazon ECR ora supporta la AWS KMS crittografia con chiavi gestite dai clienti (CMK). Prima di abilitare la crittografia lato server con una CMK, consulta le considerazioni elencate nella documentazione sulla crittografia a riposo.