Crea una pipeline per immagini di container rinforzate utilizzando Image EC2 Builder e Terraform - Prontuario AWS
RiepilogoPrerequisiti e limitazioniArchitetturaStrumentiEpicheRisoluzione dei problemiRisorse correlate

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

Crea una pipeline per immagini di container rinforzate utilizzando Image EC2 Builder e Terraform

Creato da Mike Saintcross () e Andrew Ranes () AWS AWS

Archivio di codice: Terraform Image EC2 Builder Container Hardening Pipeline

Ambiente: produzione

Fonte: Packer, Chef o Pure Ansible

Obiettivo: EC2 Image Builder

Tipo R: Re-architect

Carico di lavoro: open source

Tecnologie: sicurezza, identità, conformità; DevOps

AWSservizi: Amazon EC2 Container Registry; EC2 Image Builder

Riepilogo

Questo modello crea una pipeline di Image Builder che produce un'EC2immagine del contenitore di base Amazon Linux 2 rinforzata. Terraform viene utilizzato come strumento Infrastructure as Code (IaC) per configurare e fornire l'infrastruttura utilizzata per creare immagini di container rinforzate. La ricetta ti aiuta a distribuire un'immagine di container Amazon Linux 2 basata su Docker che è stata rafforzata secondo Red Hat Enterprise Linux RHEL () STIG 7 Version 3 Release 7 ‒ Medium. (Vedi STIG-Build-Linux-Medium versione 2022.2.1 nella sezione Componenti Linux della documentazione STIG di Image Builder.) EC2 Questa è chiamata immagine dorata del contenitore.

La build include due EventBridge regole Amazon. Una regola avvia la pipeline di immagini del contenitore quando il risultato di Amazon Inspector è alto o critico, in modo che le immagini non sicure vengano sostituite. Questa regola richiede l'abilitazione della scansione avanzata di Amazon Inspector e Amazon Elastic Container Registry ECR (Amazon). L'altra regola invia notifiche a una coda di Amazon Simple Queue Service (AmazonSQS) dopo che un'immagine è stata inviata con successo al ECR repository Amazon, per aiutarti a utilizzare le immagini più recenti dei container.

Nota: Amazon Linux 2 sta per terminare il supporto. Per ulteriori informazioni, consulta Amazon Linux 2 FAQs.

Prerequisiti e limitazioni

Prerequisiti

Limitazioni

Versioni del prodotto

  • Amazon Linux 2

  • AWSCLIversione 1.1 o successiva

Architettura

stack tecnologico Target

Questo modello crea 43 risorse, tra cui:

  • Due bucket Amazon Simple Storage Service (Amazon S3): uno per i file dei componenti della pipeline e uno per l'accesso al server e i log di flusso di Amazon VPC

  • Un ECRrepository Amazon

  • Un cloud privato virtuale (VPC) che contiene una sottorete pubblica, una sottorete privata, tabelle di routing, un NAT gateway e un gateway Internet

  • Una pipeline, una ricetta e componenti di EC2 Image Builder

  • Un'immagine del contenitore

  • Una AWS chiave Key Management Service (AWSKMS) per la crittografia delle immagini

  • Una coda SQS

  • Tre ruoli: uno per eseguire la pipeline di EC2 Image Builder, un profilo di istanza per EC2 Image Builder e uno per le regole EventBridge

  • Due regole EventBridge

Struttura del modulo Terraform

Per il codice sorgente, vedere il GitHub repository Terraform Image EC2 Builder Container Hardening Pipeline.

├── components.tf
├── config.tf
├── dist-config.tf
├── files
│   └──assumption-policy.json
├── hardening-pipeline.tfvars
├── image.tf
├── infr-config.tf
├── infra-network-config.tf
├── kms-key.tf
├── main.tf
├── outputs.tf
├── pipeline.tf
├── recipes.tf
├── roles.tf
├── sec-groups.tf
├── trigger-build.tf
└── variables.tf

Dettagli del modulo

  • components.tfcontiene una risorsa di caricamento Amazon S3 per caricare il contenuto della /files directory. Qui puoi anche aggiungere in modo modulare YAML file di componenti personalizzati.

  • /filescontiene i .yml file che definiscono i componenti utilizzati incomponents.tf.

  • image.tfcontiene le definizioni per il sistema operativo con immagine di base. Qui è possibile modificare le definizioni per una diversa pipeline di immagini di base.

  • infr-config.tfe dist-config.tf contengono le risorse per l'AWSinfrastruttura minima necessaria per avviare e distribuire l'immagine.

  • infra-network-config.tfcontiene l'VPCinfrastruttura minima in cui distribuire l'immagine del contenitore.

  • hardening-pipeline.tfvarscontiene le variabili Terraform da utilizzare al momento dell'applicazione.

  • pipeline.tfcrea e gestisce una pipeline EC2 Image Builder in Terraform.

  • recipes.tfè dove puoi specificare diverse miscele di componenti per creare ricette di contenitori.

  • roles.tfcontiene le definizioni delle policy di AWS Identity and Access Management (IAM) per il profilo dell'istanza Amazon Elastic Compute Cloud (AmazonEC2) e il ruolo di distribuzione della pipeline.

  • trigger-build.tfcontiene EventBridge le regole e le risorse di SQS coda.

Architettura di Target

Architettura e flusso di lavoro per la creazione di una pipeline per immagini di container rinforzate

Il diagramma illustra il seguente flusso di lavoro:

  1. EC2Image Builder crea un'immagine del contenitore utilizzando la ricetta definita, che installa gli aggiornamenti del sistema operativo e applica Medium RHEL STIG all'immagine di base di Amazon Linux 2.

  2. L'immagine protetta viene pubblicata su un ECR registro Amazon privato e una EventBridge regola invia un messaggio a una SQS coda quando l'immagine è stata pubblicata con successo.

  3. Se Amazon Inspector è configurato per una scansione avanzata, esegue la scansione del registro Amazon. ECR

  4. Se Amazon Inspector genera un risultato di gravità critica o elevata per l'immagine, una EventBridge regola attiva la pipeline di Image Builder per riavviare la pipeline di EC2 Image Builder e pubblicare un'immagine appena protetta.

Automazione e scalabilità

  • Questo modello descrive come effettuare il provisioning dell'infrastruttura e creare la pipeline sul computer. Tuttavia, è destinato a essere utilizzato su larga scala. Invece di distribuire i moduli Terraform localmente, puoi utilizzarli in un ambiente multi-account, come un AWSControl Tower con Account Factory for Terraform. In tal caso, è necessario utilizzare un bucket S3 con stato di backend per gestire i file di stato Terraform anziché gestire lo stato di configurazione localmente.

  • Per un utilizzo scalabile, distribuisci la soluzione su un account centrale, ad esempio un account Shared Services o Common Services, da un modello di account Control Tower o landing zone e concedi agli account dei consumatori l'autorizzazione ad accedere all'ECRarchivio e alla chiave Amazon. AWS KMS Per ulteriori informazioni sulla configurazione, consulta l'articolo Re:post Come posso consentire a un account secondario di inviare o caricare immagini nel mio archivio di ECR immagini Amazon? Ad esempio, in un distributore automatico di account o Account Factory for Terraform, aggiungi le autorizzazioni a ogni linea di base dell'account o alla baseline di personalizzazione dell'account per fornire l'accesso a quel repository Amazon e alla chiave di crittografia. ECR

  • Dopo aver distribuito la pipeline di immagini del contenitore, puoi modificarla utilizzando le funzionalità di Image EC2 Builder come i componenti, che ti aiutano a impacchettare più componenti nella build Docker.

  • La AWS KMS chiave utilizzata per crittografare l'immagine del contenitore deve essere condivisa tra gli account in cui è destinata l'immagine.

  • Puoi aggiungere il supporto per altre immagini duplicando l'intero modulo Terraform e modificando i seguenti attributi: recipes.tf

    • Modifica su un altro parent_image = "amazonlinux:latest" tipo di immagine.

    • Modifica repository_name in modo che punti a un ECR repository Amazon esistente. Questo crea un'altra pipeline che distribuisce un tipo di immagine principale diverso nel tuo repository Amazon ECR esistente.

Strumenti

Strumenti

  • Terraform (fornitura IaC)

  • Git (se si effettua il provisioning locale)

  • AWSCLIversione 1 o versione 2 (se il provisioning viene effettuato localmente)

Codice

Il codice per questo pattern si trova nel GitHub repository Terraform Image EC2 Builder Container Hardening Pipeline. Per utilizzare il codice di esempio, segui le istruzioni nella sezione successiva.

Epiche

AttivitàDescrizioneCompetenze richieste

Imposta le credenziali locali.

Configura le tue credenziali AWS temporanee.

  1. Verifica se AWS CLI è installato:

    $ aws --version
aws-cli/1.16.249 Python/3.6.8...

    • AWSCLIla versione deve essere 1.1 o successiva.

    • Se il comando non viene trovato, installa il AWS CLI.

  2. Esegui aws configure e fornisci i seguenti valori:

    $ aws configure
AWS Access Key ID [*************xxxx]: <Your AWS access key ID>
AWS Secret Access Key [**************xxxx]: <Your AWS secret access key>
Default region name: [us-east-1]: <Your desired Region for deployment>
Default output format [None]: <Your desired output format>
AWS DevOps

Clonare il repository.

  1. Clona il repository fornito con questo modello. Puoi usare HTTPS o Secure Shell ()SSH.

    HTTPS:

    git clone https://github.com/aws-samples/terraform-ec2-image-builder-container-hardening-pipeline

    SSH:

    git clone git@github.com:aws-samples/terraform-ec2-image-builder-container-hardening-pipeline.git

  2. Passate alla directory locale che contiene questa soluzione:

    cd terraform-ec2-image-builder-container-hardening-pipeline
AWS DevOps

Aggiorna le variabili.

Aggiorna le variabili nel hardening-pipeline.tfvars file in modo che corrispondano all'ambiente e alla configurazione desiderata. È necessario fornire il proprioaccount_id. Tuttavia, è necessario modificare anche il resto delle variabili per adattarle alla distribuzione desiderata. Tutte le variabili sono obbligatorie.

account_id     = "<DEPLOYMENT-ACCOUNT-ID>"
aws_region     = "us-east-1"
vpc_name       = "example-hardening-pipeline-vpc"
kms_key_alias = "image-builder-container-key"
ec2_iam_role_name = "example-hardening-instance-role"
hardening_pipeline_role_name = "example-hardening-pipeline-role"
aws_s3_ami_resources_bucket = "example-hardening-ami-resources-bucket-0123"
image_name = "example-hardening-al2-container-image"
ecr_name = "example-hardening-container-repo"
recipe_version = "1.0.0" 
ebs_root_vol_size = 10

Ecco una descrizione di ogni variabile:

  • account_id‒ Il numero di AWS account in cui si desidera implementare la soluzione.

  • aws_region‒ La AWS regione in cui si desidera distribuire la soluzione.

  • vpc_name‒ Il nome dell'VPCinfrastruttura.

  • kms_key_alias‒ Il nome della AWS KMS chiave da utilizzare per la configurazione dell'infrastruttura EC2 Image Builder.

  • ec2_iam_role_name‒ Il nome del ruolo che verrà utilizzato come profilo dell'EC2istanza.

  • hardening_pipeline_role_name‒ Il nome del ruolo che verrà utilizzato per implementare la pipeline di rafforzamento.

  • aws_s3_ami_resources_bucket‒ Il nome di un bucket S3 che ospiterà tutti i file necessari per creare le immagini della pipeline e del contenitore.

  • image_name‒ Il nome dell'immagine del contenitore. Questo valore deve essere compreso tra 3 e 50 caratteri e deve contenere solo caratteri alfanumerici e trattini.

  • ecr_name‒ Il nome del ECR registro Amazon in cui archiviare le immagini del contenitore.

  • recipe_version‒ La versione della ricetta dell'immagine. Il valore predefinito è 1.0.0.

  • ebs_root_vol_size‒ La dimensione (in gigabyte) del volume root di Amazon Elastic Block Store (AmazonEBS). Il valore predefinito è 10 gigabyte.

AWS DevOps

Inizializza Terraform.

Dopo aver aggiornato i valori delle variabili, puoi inizializzare la directory di configurazione Terraform. L'inizializzazione di una directory di configurazione scarica e installa il AWS provider, che è definito nella configurazione.

terraform init

Dovresti vedere un messaggio che dice che Terraform è stato inizializzato con successo e identifica la versione del provider che è stata installata.

AWS DevOps

Implementa l'infrastruttura e crea un'immagine del contenitore.

Usa il seguente comando per inizializzare, convalidare e applicare i moduli Terraform all'ambiente utilizzando le variabili definite nel file: .tfvars

terraform init && terraform validate && terraform apply -var-file *.tfvars -auto-approve
AWS DevOps

Personalizza il contenitore.

È possibile creare una nuova versione di una ricetta contenitore dopo che EC2 Image Builder ha distribuito la pipeline e la ricetta iniziale.

È possibile aggiungere uno qualsiasi degli oltre 31 componenti disponibili in EC2 Image Builder per personalizzare la build del contenitore. Per ulteriori informazioni, vedere la sezione Componenti di Creare una nuova versione di una ricetta contenitore nella documentazione di EC2 Image Builder.

AWSamministratore
AttivitàDescrizioneCompetenze richieste

Convalida del provisioning AWS dell'infrastruttura.

Dopo aver completato con successo il primo apply comando Terraform, se stai effettuando il provisioning localmente, dovresti vedere questo frammento nel terminale del tuo computer locale:

Apply complete! Resources: 43 added, 0 changed, 0 destroyed.
AWS DevOps

Convalida le singole risorse dell'infrastruttura. AWS

Per convalidare le singole risorse che sono state distribuite, se esegui il provisioning a livello locale, puoi eseguire il comando seguente:

terraform state list

Questo comando restituisce un elenco di 43 risorse.

AWS DevOps
AttivitàDescrizioneCompetenze richieste

Rimuovi l'infrastruttura e l'immagine del contenitore.

Quando hai finito di lavorare con la configurazione di Terraform, puoi eseguire il seguente comando per rimuovere le risorse:

terraform init && terraform validate && terraform destroy -var-file *.tfvars -auto-approve
AWS DevOps

Risoluzione dei problemi

ProblemaSoluzione

Errore durante la convalida delle credenziali del provider

Quando esegui Terraform apply o il destroy comando dal tuo computer locale, potresti riscontrare un errore simile al seguente:

Error: configuring Terraform AWS Provider: error validating provider 
credentials: error calling sts:GetCallerIdentity: operation error STS: 
GetCallerIdentity, https response error StatusCode: 403, RequestID: 
123456a9-fbc1-40ed-b8d8-513d0133ba7f, api error InvalidClientTokenId: 
The security token included in the request is invalid.

Questo errore è causato dalla scadenza del token di sicurezza per le credenziali utilizzate nella configurazione del computer locale.

Per risolvere l'errore, consulta Impostare e visualizzare le impostazioni di configurazione nella AWS CLI documentazione.

Risorse correlate