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

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 utilizzi un'immagine sconosciuta di Amazon ECR Public Gallery, ispeziona l'immagine per fare riferimento al contenuto di ciascuno dei livelli del contenitore. 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 a più fasi, consulta Creazione di build a più fasi.

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 scansionate in modalità push o su richiesta (una volta ogni 24 ore). La scansione ECR di base di Amazon utilizza Clair, una soluzione di scansione di immagini open source. La scansione ECR avanzata di Amazon utilizza Amazon Inspector. Dopo la scansione di un'immagine, i risultati vengono registrati nel flusso di ECR eventi Amazon in Amazon. EventBridge Puoi anche visualizzare i risultati di una scansione dalla ECR console Amazon o chiamando il 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.

• Automatizzazione della conformità delle immagini con Amazon ECR e AWS Security Hub spiega come ottenere informazioni sulle vulnerabilità da Amazon ECR AWS Security Hub e automatizzare la correzione bloccando l'accesso alle immagini vulnerabili.

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:

• Strumenti di sicurezza delle applicazioni open source include un elenco di strumenti per rilevare le vulnerabilità nelle applicazioni.

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 ECR container Amazon 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:

• DockerFile-LINT è uno strumento open source RedHat che può essere utilizzato per verificare se il file è conforme alle migliori pratiche.

• Hadolint è un altro strumento per creare immagini Docker conformi alle best practice.

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.

Nota

Disporre di un file system root di sola lettura può causare problemi con alcuni pacchetti OS che si aspettano la possibilità di scrivere sul file system. Se hai intenzione di utilizzare file system root di sola lettura, esegui prima un test approfondito.

Configura le attività con CPU e limiti di memoria (AmazonEC2)

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

Nota

Amazon ECS on AWS Fargate Tasks richiede che tu specifichi CPU dei limiti di memoria perché utilizza questi valori per scopi di fatturazione. Un'attività che occupa tutte le risorse di sistema non è un problema per Amazon ECS Fargate, perché ogni attività viene eseguita su una propria istanza dedicata. Se non specifichi un limite di memoria, Amazon ECS assegna un minimo di 4 MB a ciascun contenitore. Allo stesso modo, se non è impostato alcun CPU limite per l'attività, l'agente Amazon ECS Container ne assegna almeno 2CPUs.

Usa tag immutabili con Amazon ECR

Con AmazonECR, puoi e dovresti usare 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 (AmazonEC2)

È 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. Ti consigliamo di impostare la variabile di ambiente Amazon ECS Container Agent ECS_DISABLE_PRIVILEGED true per evitare che i container vengano eseguiti come privileged su host particolari se privileged non è necessaria. In alternativa, puoi usarla AWS Lambda per scansionare le definizioni delle tue attività per verificare l'utilizzo del privileged parametro.

Nota

L'esecuzione di un container privileged non è supportata su Amazon ECS su AWS Fargate.

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:

• Installa il pacchetto OS libcap-ng ed esegui l'utilità pscap per elencare le funzionalità utilizzate da ciascun processo.

• Puoi inoltre adoperare capsh per decifrare le funzionalità che un processo utilizza.

Usa una chiave gestita dal cliente (CMK) per crittografare le immagini inviate ad Amazon ECR

È necessario 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 inutilizzate con una chiave gestita AWS Key Management Service (AWS KMS). Se preferisci utilizzare la tua chiave, Amazon ECR ora supporta la AWS KMS crittografia con chiavi gestite dal cliente (CMK). Prima di abilitare la crittografia lato server con aCMK, consulta le considerazioni elencate nella documentazione sulla crittografia a riposo.