Erstellen Sie mit EC2 Image Builder und Terraform eine Pipeline für gehärtete Container-Images - AWS Prescriptive Guidance
ÜbersichtVoraussetzungen und EinschränkungenArchitekturToolsEpenFehlerbehebungZugehörige Ressourcen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Erstellen Sie mit EC2 Image Builder und Terraform eine Pipeline für gehärtete Container-Images

Erstellt von Mike Saintcross (AWS) und Andrew Ranes () AWS

Quellcode-Repository: Terraform EC2 Image Builder Container Hardening Pipeline

Umgebung: Produktion

Quelle: Packer, Chef oder Pure Ansible

Ziel: EC2 Image Builder

R-Typ: Re-Architect

Arbeitsaufwand: Open Source

Technologien: Sicherheit, Identität, Einhaltung von Vorschriften; DevOps

AWSDienste: Amazon EC2 Container Registry; EC2 Image Builder

Übersicht

Dieses Muster erstellt eine EC2Image Builder Builder-Pipeline, die ein gehärtetes Amazon Linux 2-Basis-Container-Image erzeugt. Terraform wird als IaC-Tool (Infrastructure as Code) zur Konfiguration und Bereitstellung der Infrastruktur verwendet, die zur Erstellung gehärteter Container-Images verwendet wird. Das Rezept hilft Ihnen bei der Bereitstellung eines Docker-basierten Amazon Linux 2-Container-Images, das gemäß Red Hat Enterprise Linux (RHEL) 7 STIG Version 3 Release 7 ‒ Medium gehärtet wurde. (Weitere Informationen finden Sie unter STIG-Build-Linux-Medium Version 2022.2.1 im Abschnitt STIGLinux-Komponenten der Image Builder Builder-Dokumentation.) EC2 Dies wird als goldenes Container-Image bezeichnet.

Der Build beinhaltet zwei EventBridge Amazon-Regeln. Eine Regel startet die Container-Image-Pipeline, wenn das Ergebnis von Amazon Inspector „Hoch“ oder „Kritisch“ lautet, sodass unsichere Images ersetzt werden. Für diese Regel müssen sowohl das erweiterte Scannen von Amazon Inspector als auch das erweiterte Scannen von Amazon Elastic Container Registry (AmazonECR) aktiviert sein. Die andere Regel sendet nach einem erfolgreichen Image-Push an das ECR Amazon-Repository Benachrichtigungen an eine Amazon Simple Queue Service (AmazonSQS) -Warteschlange, um Ihnen bei der Verwendung der neuesten Container-Images zu helfen.

Hinweis: Amazon Linux 2 nähert sich dem Ende des Supports. Weitere Informationen finden Sie unter Amazon Linux FAQs 2.

Voraussetzungen und Einschränkungen

Voraussetzungen

  • Ein AWSKonto, in dem Sie die Infrastruktur bereitstellen können.

  • AWSDie Befehlszeilenschnittstelle (AWSCLI) ist installiert, um Ihre AWS Anmeldeinformationen für die lokale Bereitstellung festzulegen.

  • Terraform wurde heruntergeladen und eingerichtet, indem Sie den Anweisungen in der Terraform-Dokumentation folgen.

  • Git (wenn Sie von einem lokalen Computer aus bereitstellen).

  • Eine Rolle innerhalb des AWS Kontos, mit der Sie AWS Ressourcen erstellen können.

  • Alle in der Datei .tfvars definierten Variablen.  Oder Sie können alle Variablen definieren, wenn Sie die Terraform-Konfiguration anwenden.

Einschränkungen

Produktversionen

  • Amazon Linux 2

  • AWSCLIVersion 1.1 oder höher

Architektur

Zieltechnologie-Stack

Dieses Muster erzeugt 43 Ressourcen, darunter:

  • Zwei Amazon Simple Storage Service (Amazon S3) -Buckets: einer für die Pipeline-Komponentendateien und einer für Serverzugriff und Amazon VPC Flow-Logs

  • Ein ECRAmazon-Repository

  • Eine virtuelle private Cloud (VPC), die ein öffentliches Subnetz, ein privates Subnetz, Routing-Tabellen, ein NAT Gateway und ein Internet-Gateway enthält

  • Eine EC2 Image Builder Builder-Pipeline, ein Rezept und Komponenten

  • Ein Container-Image

  • Ein AWS Key Management Service (AWSKMS) -Schlüssel für die Bildverschlüsselung

  • Eine SQS-Warteschlange

  • Drei Rollen: eine für die Ausführung der EC2 Image Builder-Pipeline, ein Instanzprofil für EC2 Image Builder und eine für EventBridge Regeln

  • Zwei EventBridge Regeln

Struktur des Terraform-Moduls

Den Quellcode finden Sie im GitHub Repository Terraform EC2 Image 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

Einzelheiten zum Modul

  • components.tfenthält eine Amazon S3 S3-Upload-Ressource, um den Inhalt des /files Verzeichnisses hochzuladen. Sie können hier auch modular benutzerdefinierte YAML Komponentendateien hinzufügen.

  • /filesenthält die .yml Dateien, die die in components.tf verwendeten Komponenten definieren.

  • image.tfenthält die Definitionen für das Basis-Image-Betriebssystem. Hier können Sie die Definitionen für eine andere Basis-Image-Pipeline ändern.

  • infr-config.tfund dist-config.tf enthalten die Ressourcen für die AWS Mindestinfrastruktur, die für die Einrichtung und Verteilung des Images erforderlich ist.

  • infra-network-config.tfenthält die VPC Mindestinfrastruktur für die Bereitstellung des Container-Images.

  • hardening-pipeline.tfvarsenthält die Terraform-Variablen, die zum Zeitpunkt der Anwendung verwendet werden sollen.

  • pipeline.tferstellt und verwaltet eine EC2 Image Builder Builder-Pipeline in Terraform.

  • recipes.tfHier können Sie verschiedene Mischungen von Komponenten angeben, um Container-Rezepte zu erstellen.

  • roles.tfenthält die AWS Identity and Access Management (IAM) -Richtliniendefinitionen für das Amazon Elastic Compute Cloud (AmazonEC2) -Instance-Profil und die Pipeline-Bereitstellungsrolle.

  • trigger-build.tfenthält die EventBridge Regeln und SQS Warteschlangenressourcen.

Zielarchitektur

Architektur und Arbeitsablauf für den Aufbau einer Pipeline für gehärtete Container-Images

Das Diagramm veranschaulicht den folgenden Arbeitsablauf:

  1. EC2Image Builder erstellt mithilfe des definierten Rezepts ein Container-Image, das Betriebssystemupdates installiert und das RHEL Medium STIG auf das Amazon Linux 2-Basis-Image anwendet.

  2. Das gehärtete Image wird in einer privaten ECR Amazon-Registry veröffentlicht, und eine EventBridge Regel sendet eine Nachricht an eine SQS Warteschlange, wenn das Image erfolgreich veröffentlicht wurde.

  3. Wenn Amazon Inspector für erweitertes Scannen konfiguriert ist, scannt er die ECR Amazon-Registrierung.

  4. Wenn Amazon Inspector den Schweregrad Kritisch oder Hoch für das Image generiert, veranlasst eine EventBridge Regel, dass die EC2 Image Builder Builder-Pipeline erneut ausgeführt und ein neu gehärtetes Image veröffentlicht wird.

Automatisierung und Skalierung

  • Dieses Muster beschreibt, wie Sie die Infrastruktur bereitstellen und die Pipeline auf Ihrem Computer aufbauen. Es ist jedoch für den Einsatz in großem Umfang vorgesehen. Anstatt die Terraform-Module lokal bereitzustellen, können Sie sie in einer Umgebung mit mehreren Konten verwenden, z. B. in einer AWSControl Tower mit Account Factory für Terraform-Umgebung. In diesem Fall sollten Sie einen S3-Bucket mit Backend-Status verwenden, um Terraform-Statusdateien zu verwalten, anstatt den Konfigurationsstatus lokal zu verwalten.

  • Für eine skalierte Nutzung stellen Sie die Lösung von einem Control Tower- oder Landingzone-Kontomodell aus auf einem zentralen Konto bereit, z. B. einem Shared Services- oder Common Services-Konto, und gewähren Sie Benutzerkonten die Erlaubnis, auf das ECR Amazon-Repository und den AWS KMS Schlüssel zuzugreifen. Weitere Informationen zur Einrichtung finden Sie im re:POST-Artikel Wie kann ich einem sekundären Konto erlauben, Bilder in meinem ECR Amazon-Bild-Repository zu pushen oder abzurufen? Fügen Sie beispielsweise in einem Kontoautomaten oder Account Factory für Terraform Berechtigungen zu jeder Konto-Baseline oder Kontoanpassungs-Baseline hinzu, um Zugriff auf das ECR Amazon-Repository und den Verschlüsselungsschlüssel zu gewähren.

  • Nachdem die Container-Image-Pipeline bereitgestellt wurde, können Sie sie mithilfe von EC2 Image Builder Builder-Funktionen wie Komponenten ändern, die Ihnen helfen, mehr Komponenten in den Docker-Build zu packen.

  • Der AWS KMS Schlüssel, der zum Verschlüsseln des Container-Images verwendet wird, sollte von allen Konten gemeinsam genutzt werden, in denen das Image verwendet werden soll.

  • Sie können Unterstützung für andere Bilder hinzufügen, indem Sie das gesamte Terraform-Modul duplizieren und die folgenden Attribute ändern: recipes.tf

    • Ändern Sie parent_image = "amazonlinux:latest" zu einem anderen Bildtyp.

    • Ändern Sie repository_name es so, dass es auf ein vorhandenes ECR Amazon-Repository verweist. Dadurch wird eine weitere Pipeline erstellt, die einen anderen übergeordneten Image-Typ für Ihr bestehendes ECR Amazon-Repository bereitstellt.

Tools

Tools

  • Terraform (IaC-Bereitstellung)

  • Git (bei lokaler Bereitstellung)

  • AWSCLIVersion 1 oder Version 2 (bei lokaler Bereitstellung)

Kode

Der Code für dieses Muster befindet sich im GitHub Repository Terraform EC2 Image Builder Container Hardening Pipeline. Folgen Sie den Anweisungen im nächsten Abschnitt, um den Beispielcode zu verwenden.

Epen

AufgabeBeschreibungErforderliche Fähigkeiten

Richten Sie lokale Anmeldeinformationen ein.

Richten Sie Ihre AWS temporären Anmeldeinformationen ein.

  1. Prüfen Sie, ob der installiert AWS CLI ist:

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

  2. Führen Sie den aws configure Befehl aus und geben Sie die folgenden Werte ein:

    $ 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

Klonen Sie das Repository

  1. Klonen Sie das Repository, das mit diesem Muster bereitgestellt wurde. Sie können Secure Shell (SSH) verwendenHTTPS.

    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. Navigieren Sie zu Ihrem lokalen Verzeichnis, das diese Lösung enthält:

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

Variablen aktualisieren.

Aktualisieren Sie die Variablen in der hardening-pipeline.tfvars Datei so, dass sie Ihrer Umgebung und Ihrer gewünschten Konfiguration entsprechen. Sie müssen Ihre eigenen angebenaccount_id. Sie sollten jedoch auch die restlichen Variablen so ändern, dass sie zu Ihrer gewünschten Bereitstellung passen. Alle Variablen sind erforderlich.

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

Hier ist eine Beschreibung der einzelnen Variablen:

  • account_id‒ Die AWS Kontonummer, unter der Sie die Lösung bereitstellen möchten.

  • aws_region‒ Die AWS Region, in der Sie die Lösung bereitstellen möchten.

  • vpc_name‒ Der Name für Ihre VPC Infrastruktur.

  • kms_key_alias‒ Der AWS KMS Schlüsselname, der von der EC2 Image Builder Builder-Infrastrukturkonfiguration verwendet werden soll.

  • ec2_iam_role_name‒ Der Name der Rolle, die als EC2 Instanzprofil verwendet wird.

  • hardening_pipeline_role_name‒ Der Name der Rolle, die für die Bereitstellung der Hardening-Pipeline verwendet wird.

  • aws_s3_ami_resources_bucket‒ Der Name für einen S3-Bucket, der alle Dateien hostet, die zum Erstellen der Pipeline und der Container-Images erforderlich sind.

  • image_name‒ Der Name des Container-Images. Dieser Wert muss zwischen 3 und 50 Zeichen lang sein und darf nur alphanumerische Zeichen und Bindestriche enthalten.

  • ecr_name‒ Der Name der ECR Amazon-Registry, in der die Container-Images gespeichert werden sollen.

  • recipe_version‒ Die Version des Image-Rezepts. Der Standardwert ist 1.0.0.

  • ebs_root_vol_size‒ Die Größe (in Gigabyte) des Amazon Elastic Block Store (AmazonEBS) -Root-Volumes. Der Standardwert ist 10 Gigabyte.

AWS DevOps

Initialisieren Sie Terraform.

Nachdem Sie Ihre Variablenwerte aktualisiert haben, können Sie das Terraform-Konfigurationsverzeichnis initialisieren. Durch die Initialisierung eines Konfigurationsverzeichnisses wird der in der Konfiguration definierte AWS Anbieter heruntergeladen und installiert.

terraform init

Sie sollten eine Meldung sehen, die besagt, dass Terraform erfolgreich initialisiert wurde und die Version des Anbieters identifiziert wird, die installiert wurde.

AWS DevOps

Stellen Sie die Infrastruktur bereit und erstellen Sie ein Container-Image.

Verwenden Sie den folgenden Befehl, um die Terraform-Module mithilfe der in Ihrer Datei definierten Variablen zu initialisieren, zu validieren und auf die Umgebung anzuwenden: .tfvars

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

Passen Sie den Container an.

Sie können eine neue Version eines Container-Rezepts erstellen, nachdem EC2 Image Builder die Pipeline und das erste Rezept bereitgestellt hat.

Sie können jede der mehr als 31 in EC2 Image Builder verfügbaren Komponenten hinzufügen, um den Container-Build anzupassen. Weitere Informationen finden Sie im Abschnitt Komponenten unter Erstellen einer neuen Version eines Container-Rezepts in der EC2 Image Builder Builder-Dokumentation.

AWSAdministrator
AufgabeBeschreibungErforderliche Fähigkeiten

Überprüfen Sie AWS die Bereitstellung der Infrastruktur.

Wenn Sie Ihren ersten apply Terraform-Befehl erfolgreich ausgeführt haben und lokal bereitstellen, sollten Sie diesen Ausschnitt im Terminal Ihres lokalen Computers sehen:

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

Validieren Sie einzelne Infrastrukturressourcen. AWS

Um die einzelnen Ressourcen zu überprüfen, die bereitgestellt wurden, können Sie bei einer lokalen Bereitstellung den folgenden Befehl ausführen:

terraform state list

Dieser Befehl gibt eine Liste mit 43 Ressourcen zurück.

AWS DevOps
AufgabeBeschreibungErforderliche Fähigkeiten

Entfernen Sie die Infrastruktur und das Container-Image.

Wenn Sie mit Ihrer Terraform-Konfiguration fertig sind, können Sie den folgenden Befehl ausführen, um Ressourcen zu entfernen:

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

Fehlerbehebung

ProblemLösung

Fehler bei der Überprüfung der Anmeldeinformationen des Anbieters

Wenn Sie den Terraform apply - oder destroy Befehl von Ihrem lokalen Computer aus ausführen, tritt möglicherweise ein Fehler auf, der dem folgenden ähnelt:

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.

Dieser Fehler wird durch den Ablauf des Sicherheitstokens für die in der Konfiguration Ihres lokalen Computers verwendeten Anmeldeinformationen verursacht.

Informationen zur Behebung des Fehlers finden Sie in der AWS CLI Dokumentation unter Konfigurationseinstellungen einrichten und anzeigen.

Zugehörige Ressourcen