Sicurezza delle immagini - Amazon EKS
RaccomandazioniStrumenti e risorse

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à.

Sicurezza delle immagini

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. Una volta sull'host, un malintenzionato può accedere a informazioni sensibili o spostarsi lateralmente all'interno del cluster o con il tuo account AWS. Le seguenti best practice aiuteranno a mitigare il rischio che ciò accada.

Raccomandazioni

Crea immagini minime

Inizia rimuovendo tutti i file binari estranei dall'immagine di container. Se stai usando un'immagine sconosciuta di Dockerhub, ispeziona l'immagine usando un'applicazione come Dive che può mostrarti il contenuto di ciascuno dei livelli del contenitore. Rimuovi tutti i file binari con i bit SETUID e SETGID in quanto possono essere usati per aumentare i privilegi e valuta la possibilità di rimuovere tutte le shell e le utilità come nc e curl che possono essere utilizzate per scopi malvagi. Puoi trovare i file con bit SETUID e SETGID con il seguente comando:

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

Per rimuovere i permessi speciali da questi file, aggiungi la seguente direttiva all'immagine del contenitore:

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

Colloquialmente, questa operazione è nota come snaturamento dell'immagine.

Usa build in più fasi

L'utilizzo di build in più fasi è un modo per creare immagini minime. Spesso, le build in più fasi vengono utilizzate per automatizzare parti del ciclo di integrazione continua. Ad esempio, è possibile utilizzare build in più fasi per linkare il codice sorgente o eseguire analisi statiche del codice. Ciò offre agli sviluppatori l'opportunità di ottenere un feedback quasi immediato invece di attendere l'esecuzione di una pipeline. Le build in più fasi sono interessanti dal punto di vista della sicurezza perché consentono di ridurre al minimo le dimensioni dell'immagine finale inserita nel registro dei contenitori. 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 documentazione delle build in più fasi di Docker.

Crea Software Bill of Materials () SBOMs per l'immagine del tuo contenitore

Una «lista dei materiali del software» (SBOM) è un inventario annidato degli artefatti software che compongono l'immagine del contenitore. La SBOM è un elemento fondamentale nella sicurezza del software e nella gestione del rischio della catena di fornitura del software. La generazione, l'archiviazione degli SBOM in un archivio centrale e la scansione delle vulnerabilità aiutano a risolvere SBOMs i seguenti problemi:

  • Visibilità: scopri quali componenti costituiscono l'immagine del tuo contenitore. L'archiviazione in un repository centrale consente di SBOMs essere controllati e scansionati in qualsiasi momento, anche dopo l'implementazione, per rilevare e rispondere a nuove vulnerabilità, come le vulnerabilità zero-day.

  • Verifica della provenienza: garanzia che le ipotesi esistenti sulla provenienza e sulla provenienza di un artefatto siano vere e che l'artefatto o i relativi metadati non siano stati manomessi durante i processi di costruzione o consegna.

  • Affidabilità: garanzia che un determinato artefatto e il suo contenuto facciano ciò che si presume facciano, ossia siano adatti a uno scopo. Ciò implica valutare se il codice è sicuro da eseguire e prendere decisioni informate sui rischi associati all'esecuzione del codice. L'affidabilità è garantita dalla creazione di un rapporto di esecuzione della pipeline attestato insieme al rapporto SBOM attestato e al rapporto di scansione CVE attestato, per assicurare ai consumatori dell'immagine che l'immagine è effettivamente creata con mezzi sicuri (pipeline) con componenti sicuri.

  • Verifica della fiducia delle dipendenze: controllo ricorsivo dell'albero delle dipendenze di un artefatto per verificarne l'affidabilità e la provenienza degli artefatti utilizzati. Il drift in SBOMs può aiutare a rilevare attività dannose, tra cui dipendenze non autorizzate e non attendibili e tentativi di infiltrazione.

I seguenti strumenti possono essere utilizzati per generare SBOM:

  • Amazon Inspector può essere utilizzato per creare ed esportare. SBOMs

  • Syft di Anchore può essere utilizzato anche per la generazione di SBOM. Per scansioni di vulnerabilità più rapide, l'SBOM generato per un'immagine del contenitore può essere utilizzato come input per la scansione. L'SBOM e il rapporto di scansione vengono quindi attestati e allegati all'immagine prima di inviarla a un repository OCI centrale come Amazon ECR per scopi di revisione e controllo.

Scopri di più su come proteggere la tua catena di fornitura del software consultando la guida CNCF Software Supply Chain Best Practices.

Scansiona regolarmente le immagini per individuare eventuali vulnerabilità

Analogamente alle macchine virtuali, le immagini dei container possono contenere file binari e librerie di applicazioni con vulnerabilità o sviluppare vulnerabilità nel 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 nell'arco di 24 ore). Attualmente ECR supporta due tipi di scansione: Basic e Enhanced. La scansione di base sfrutta Clair, una soluzione di scansione di immagini open source gratuita. La scansione avanzata utilizza Amazon Inspector per fornire scansioni automatiche continue a costi aggiuntivi. Dopo la scansione di un'immagine, i risultati vengono registrati nel flusso di eventi per l'accesso ECR. EventBridge È inoltre possibile visualizzare i risultati di una scansione dall'interno della console ECR. Le immagini con una vulnerabilità ALTA o CRITICA devono essere eliminate o ricostruite. Un'immagine implementata che sviluppa una vulnerabilità deve essere sostituita il prima possibile.

Sapere dove sono state distribuite le immagini con vulnerabilità è essenziale per proteggere l'ambiente. Sebbene sia possibile creare autonomamente una soluzione di tracciamento delle immagini, esistono già diverse offerte commerciali che forniscono questa e altre funzionalità avanzate pronte all'uso, tra cui:

Un webhook di convalida Kubernetes potrebbe essere utilizzato anche per verificare che le immagini siano prive di vulnerabilità critiche. I webhook di convalida vengono richiamati prima dell'API Kubernetes. In genere vengono utilizzati per rifiutare le richieste che non soddisfano i criteri di convalida definiti nel webhook. Questo è un esempio di webhook serverless che richiama l'API ECR describeImageScan Findings per determinare se un pod sta estraendo un'immagine con vulnerabilità critiche. Se vengono rilevate vulnerabilità, il pod viene rifiutato e un messaggio con un elenco di CVEs viene restituito come evento.

Usa gli attestati per convalidare l'integrità degli artefatti

Un attestato è una «dichiarazione» firmata crittograficamente che afferma che qualcosa, ad esempio un «predicato», ad esempio l'esecuzione di una pipeline o lo SBOM o il rapporto di scansione delle vulnerabilità, riguarda un'altra cosa: un «soggetto», ovvero l'immagine del contenitore.

Gli attestati aiutano gli utenti a verificare che un artefatto provenga da una fonte attendibile nella catena di fornitura del software. Ad esempio, possiamo utilizzare l'immagine di un contenitore senza conoscere tutti i componenti software o le dipendenze inclusi in tale immagine. Tuttavia, se ci fidiamo di ciò che il produttore dell'immagine del contenitore dice sul software presente, possiamo utilizzare l'attestato del produttore per fare affidamento su quell'artefatto. Ciò significa che possiamo procedere a utilizzare l'artefatto in modo sicuro nel nostro flusso di lavoro anziché eseguire l'analisi da soli.

Crea politiche IAM per i repository ECR

Al giorno d'oggi, non è raro che un'organizzazione abbia più team di sviluppo che operano in modo indipendente all'interno di un account AWS condiviso. Se questi team non hanno bisogno di condividere le risorse, potresti voler creare una serie di policy IAM che limitino l'accesso ai repository con cui ogni team può interagire. Un buon modo per implementarlo è utilizzare i namespace ECR. I namespace sono un modo per raggruppare repository simili. Ad esempio, tutti i registri per il team A possono essere preceduti dal prefisso team-a/ mentre quelli per il team B possono utilizzare il prefisso team-b/. La politica per limitare l'accesso potrebbe essere simile alla seguente:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPushPull",
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability",
        "ecr:PutImage",
        "ecr:InitiateLayerUpload",
        "ecr:UploadLayerPart",
        "ecr:CompleteLayerUpload"
      ],
      "Resource": [
        "arn:aws:ecr:<region>:<account_id>:repository/team-a/*"
      ]
    }
  ]
}

Prendi in considerazione l'utilizzo di endpoint privati ECR

L'API ECR ha un endpoint pubblico. Di conseguenza, è possibile accedere ai registri ECR da Internet purché la richiesta sia stata autenticata e autorizzata da IAM. Per coloro che devono operare in un ambiente sandbox in cui il VPC del cluster non dispone di un Internet Gateway (IGW), è possibile configurare un endpoint privato per ECR. La creazione di un endpoint privato consente di accedere in modo privato all'API ECR tramite un indirizzo IP privato anziché indirizzare il traffico su Internet. Per ulteriori informazioni su questo argomento, consulta Endpoint VPC con interfaccia Amazon ECR.

Implementa politiche sugli endpoint per ECR

La policy predefinita per gli endpoint consente l'accesso a tutti gli archivi ECR all'interno di una regione. Ciò potrebbe consentire attacker/insider a un utente di esfiltrare i dati impacchettandoli come immagine di un contenitore e inviandoli a un registro in un altro account AWS. Per mitigare questo rischio è necessario creare una policy sugli endpoint che limiti l'accesso delle API ai repository ECR. Ad esempio, la seguente policy consente a tutti i principi AWS del tuo account di eseguire tutte le azioni sui tuoi e solo sui tuoi repository ECR:

{
  "Statement": [
    {
      "Sid": "LimitECRAccess",
      "Principal": "*",
      "Action": "*",
      "Effect": "Allow",
      "Resource": "arn:aws:ecr:<region>:<account_id>:repository/*"
    }
  ]
}

Puoi migliorarlo ulteriormente impostando una condizione che utilizzi il nuovo PrincipalOrgID attributo che impedirà la creazione pushing/pulling di immagini in base a un principio IAM che non fa parte della tua AWS Organization. Vedi, aws: PrincipalOrg ID per ulteriori dettagli. Consigliamo di applicare la medesima policy sia agli endpoint com.amazonaws.<region>.ecr.dkr che agli endpoint com.amazonaws.<region>.ecr.api. Poiché EKS estrae le immagini per kube-proxy, coredns e aws-node da ECR, sarà necessario aggiungere l'ID dell'account del registro, ad esempio 602401143452.dkr.ecr.us-west-2.amazonaws.com/ all'elenco delle risorse nella policy degli endpoint, o modificare la politica per consentire l'estrazione e limitare i push all'ID dell'account. La tabella seguente mostra la mappatura tra gli account AWS da cui vengono vendute le immagini EKS e la regione del cluster.

Numero account Regione

602401143452

Tutte le regioni commerciali ad eccezione di quelle elencate di seguito

—

—

800184023465

ap-east-1 - Asia Pacifico (Hong Kong)

558608220178

me-south-1 - Medio Oriente (Bahrein)

918309763551

cn-north-1 - Cina (Pechino)

961992271922

cn-northwest-1 - Cina (Ningxia)

Per ulteriori informazioni sull'utilizzo delle policy degli endpoint, consulta Utilizzo delle policy degli endpoint VPC per controllare l'accesso ad Amazon ECR.

Implementa le politiche del ciclo di vita per ECR

La NIST Application Container Security Guide mette in guardia dal rischio di «immagini obsolete nei registri», osservando che nel tempo le vecchie immagini con pacchetti out-of-date software vulnerabili dovrebbero essere rimosse per evitare la distribuzione e l'esposizione accidentali. Ogni repository ECR può avere una politica del ciclo di vita che stabilisce regole per la scadenza delle immagini. La documentazione ufficiale di AWS descrive come configurare le regole di test, valutarle e quindi applicarle. Nei documenti ufficiali sono disponibili diversi esempi di politiche relative al ciclo di vita che mostrano diversi modi di filtrare le immagini in un repository:

  • Filtraggio per età o numero di immagini

  • Filtraggio per immagini con o senza tag

  • Filtraggio per tag di immagine, in più regole o in un'unica regola

??? + avviso Se l'immagine per un'applicazione a esecuzione prolungata viene eliminata da ECR, può causare errori di estrazione dell'immagine quando l'applicazione viene ridistribuita o ridimensionata orizzontalmente. Quando utilizzate le policy relative al ciclo di vita delle immagini, assicuratevi di CI/CD adottare delle buone pratiche per mantenere aggiornate le distribuzioni e le immagini a cui fanno riferimento e create sempre regole di scadenza [dell'immagine] che tengano conto della frequenza con cui eseguite rilasci/distribuzioni.

Creazione di un set di immagini curate

Piuttosto che consentire agli sviluppatori di creare le proprie immagini, prendete in considerazione la possibilità di creare una serie di immagini controllate per i diversi stack di applicazioni dell'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 unite in Master, una CI/CD pipeline può compilare automaticamente l'asset, archiviarlo in un repository di artefatti e copiare l'elemento nell'immagine appropriata prima di inviarlo a un registro Docker come ECR. Per lo meno dovresti creare un set di immagini di base da cui gli sviluppatori possano creare i propri Dockerfile. Idealmente, dovresti evitare di estrarre immagini da Dockerhub perché 1/ non sempre sai cosa c'è nell'immagine e 2/ circa un quinto delle prime 1000 immagini presenta delle vulnerabilità. Un elenco di queste immagini e delle relative vulnerabilità è disponibile qui.

Aggiungi la direttiva USER ai tuoi Dockerfiles per eseguirli come utente non root

Come accennato nella sezione sulla sicurezza dei pod, dovresti evitare di eseguire container come root. Sebbene sia possibile configurarlo come parte di PodSpec, è una buona abitudine utilizzare la USER direttiva sui Dockerfile. La USER direttiva imposta l'UID da utilizzare durante l'esecuzione RUN o l'CMDistruzione che appare dopo la direttiva USER. ENTRYPOINT

Lint i tuoi Dockerfile

Linting può essere utilizzato per verificare che i Dockerfile aderiscano a una serie di linee guida predefinite, ad esempio l'inclusione della USER direttiva o il requisito che tutte le immagini siano etichettate. dockerfile_lint è un progetto open source RedHat che verifica le migliori pratiche comuni e include un motore di regole che puoi utilizzare per creare le tue regole per il linting dei Dockerfile. Può essere incorporato in una pipeline CI, in quanto le build con Dockerfile che violano una regola falliranno automaticamente.

Crea immagini partendo da zero

Ridurre la superficie di attacco delle immagini dei container dovrebbe essere l'obiettivo principale nella creazione di immagini. Il modo ideale per farlo è creare immagini minime prive di file binari che possano essere utilizzate per sfruttare le vulnerabilità. Fortunatamente, Docker ha un meccanismo da cui creare immagini. scratch Con linguaggi come Go, puoi creare un binario collegato statico e farvi riferimento nel tuo Dockerfile come in questo esempio:

############################
# 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 gitWORKDIR $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"]

Questo crea un'immagine del contenitore composta dalla tua applicazione e nient'altro, rendendolo estremamente sicuro.

Usa tag immutabili con ECR

I tag immutabili ti obbligano ad aggiornare il tag dell'immagine ad ogni invio al repository di immagini. Ciò può impedire a un utente malintenzionato di sovrascrivere un'immagine con una versione dannosa senza modificare i tag dell'immagine. Inoltre, consente di identificare un'immagine in modo semplice e univoco.

Firma le tue immagini SBOMs, le esecuzioni della pipeline e i report sulle vulnerabilità

Quando Docker è stato introdotto per la prima volta, non esisteva un modello crittografico per la verifica delle immagini dei container. Con la v2, Docker ha aggiunto dei digest al manifesto dell'immagine. Ciò ha consentito di eseguire l'hashing della configurazione di un'immagine e di utilizzare l'hash per generare un ID per l'immagine. Quando la firma delle immagini è abilitata, il motore Docker verifica la firma del manifesto, assicurando che il contenuto sia stato prodotto da una fonte attendibile e che non si siano verificate manomissioni. Dopo aver scaricato ogni layer, il motore verifica il digest del layer, assicurando che il contenuto corrisponda al contenuto specificato nel manifesto. La firma delle immagini consente in modo efficace di creare una catena di approvvigionamento sicura, attraverso la verifica delle firme digitali associate all'immagine.

Possiamo usare AWS Signer o Sigstore Cosign per firmare immagini di container, creare attestazioni, report di scansione delle vulnerabilità e report di SBOMs esecuzione della pipeline. Queste attestazioni assicurano l'affidabilità e l'integrità dell'immagine, che è effettivamente creata dalla pipeline affidabile senza alcuna interferenza o manomissione e che contiene solo i componenti software documentati (nello SBOM), verificati e considerati attendibili dall'editore dell'immagine. Queste attestazioni possono essere allegate all'immagine del contenitore e inviate al repository.

Nella prossima sezione vedremo come utilizzare gli artefatti attestati per gli audit e la verifica dei controllori di ammissione.

Verifica dell'integrità delle immagini tramite il controller di ammissione Kubernetes

Possiamo verificare le firme delle immagini e gli artefatti attestati in modo automatizzato prima di distribuire l'immagine sul cluster Kubernetes di destinazione utilizzando un controller di ammissione dinamico e ammettere le distribuzioni solo quando i metadati di sicurezza degli artefatti sono conformi alle politiche del controller di ammissione.

Ad esempio, possiamo scrivere una politica che verifichi crittograficamente la firma di un'immagine, un SBOM attestato, un rapporto di esecuzione della pipeline attestato o un rapporto di scansione CVE attestato. Possiamo scrivere condizioni nella policy per controllare i dati nel report, ad esempio una scansione CVE non dovrebbe presentare alcuna criticità. CVEs La distribuzione è consentita solo per le immagini che soddisfano queste condizioni e tutte le altre implementazioni verranno rifiutate dal responsabile delle ammissioni.

Alcuni esempi di controller di ammissione includono:

Aggiorna i pacchetti nelle immagini del contenitore

Dovresti includere RUN apt-get update && apt-get upgrade nei tuoi Dockerfile per aggiornare i pacchetti nelle tue immagini. Sebbene l'aggiornamento richieda l'esecuzione come root, ciò avviene durante la fase di creazione dell'immagine. L'applicazione non deve essere eseguita come root. È possibile installare gli aggiornamenti e quindi passare a un altro utente con la direttiva USER. Se l'immagine di base viene eseguita come utente non root, passa a root e viceversa; non affidarti esclusivamente ai manutentori dell'immagine di base per installare gli ultimi aggiornamenti di sicurezza.

Esegui apt-get clean per eliminare i file di installazione da. /var/cache/apt/archives/ È possibile eseguire l'operazione anche rm -rf /var/lib/apt/lists/* dopo aver installato i pacchetti. Ciò rimuove i file di indice o gli elenchi di pacchetti disponibili per l'installazione. Tieni presente che questi comandi possono essere diversi per ogni gestore di pacchetti. Per esempio:

RUN apt-get update && apt-get install -y \
    curl \
    git \
    libsqlite3-dev \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

Strumenti e risorse