EC2 Image Builder と Terraform を使用して、強化されたコンテナイメージのパイプラインを構築する - AWS 規範ガイダンス
[概要]前提条件と制限アーキテクチャツールエピックトラブルシューティング関連リソース

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

EC2 Image Builder と Terraform を使用して、強化されたコンテナイメージのパイプラインを構築する

作成者: Mike Saintcross (AWS) と Andrew Ranes (AWS）

コードリポジトリ: Terraform EC2 Image Builder コンテナ強化パイプライン

環境:本稼働

ソース: パッカー、シェフ、または Pure Ansible

ターゲット: EC2 Image Builder

R タイプ: リアーキテクト

ワークロード： オープンソース

テクノロジー: セキュリティ、アイデンティティ、コンプライアンス DevOps

AWS サービス: Amazon EC2 Container Registry、EC2Image Builder

[概要]

このパターンは、強化された Amazon Linux 2 EC2 ベースコンテナイメージを生成する Image Builder パイプラインを構築します。Terraform は、強化されたコンテナイメージの作成に使用されるインフラストラクチャを設定してプロビジョニングするための Infrastructure as Code (IaC) ツールとして使用されます。この recipe は、Red Hat Enterprise Linux (RHEL) 7 STIGバージョン 3 リリース 7 ‒ Medium に従って強化された Docker ベースの Amazon Linux 2 コンテナイメージをデプロイするのに役立ちます。（EC2Image Builder ドキュメントの Linux STIGコンポーネントセクションのSTIG「-Build-Linux-Medium バージョン 2022.2.1」を参照してください。） これは、ゴールデンコンテナイメージと呼ばれます。

ビルドには 2 つの Amazon EventBridge ルール が含まれています。1 つ目のルールは、Amazon Inspector の検出結果が「高」または「重要」の場合にコンテナイメージパイプラインを開始し、セキュアでないイメージが置き換えられるようにします。このルールでは、Amazon Inspector と Amazon Elastic Container Registry (Amazon ECR) の両方の拡張スキャンを有効にする必要があります。もう 1 つのルールは、Amazon ECRリポジトリへのイメージのプッシュが成功すると、Amazon Simple Queue Service (Amazon SQS) キューに通知を送信し、最新のコンテナイメージを使用するのに役立ちます。

注: Amazon Linux 2 のサポートは間もなく終了します。詳細については、「Amazon Linux 2FAQs」を参照してください。

前提条件と制限

前提条件

  • インフラストラクチャをデプロイできる AWSアカウント。

  • ローカルデプロイ用のAWS認証情報を設定するためにインストールAWSされたコマンドラインインターフェイス (AWSCLI）。

  • Terraform ドキュメントの「指示」に従って Terraform をダウンロードし、セットアップしました。

  • Git (ローカルマシンからプロビジョニングする場合)。

  • AWS リソースの作成に使用できるAWSアカウント内のロール。

  • .tfvars ファイルで定義されているすべての変数。 または、Terraform 設定を適用するときにすべての変数を定義できます。

機能制限

製品バージョン

  • Amazon Linux 2

  • AWS CLI バージョン 1.1 以降

アーキテクチャ

ターゲットテクノロジースタック

このパターンでは、以下を含む 43 個のリソースが作成されます。

  • 2 つの Amazon Simple Storage Service (Amazon S3) バケット: 1 つはパイプラインコンポーネントファイル用、もう 1 つはサーバーアクセスと Amazon VPCフローログ用

  • Amazon ECRリポジトリ

  • パブリックサブネット、プライベートサブネット、ルートテーブル、NATゲートウェイ、インターネットゲートウェイを含む仮想プライベートクラウド (VPC）

  • EC2 Image Builder パイプライン、レシピ、コンポーネント

  • コンテナイメージ

  • イメージ暗号化用の AWS Key Management Service (AWSKMS) キー

  • SQS キュー

  • 3 つのロール: 1 つは EC2 Image Builder パイプラインを実行するロール、1 つは EC2 Image Builder のインスタンスプロファイル、もう 1 つは EventBridge ルールを実行するロール

  • 2 つの EventBridge ルール

Terraform モジュール構造

ソースコードについては、「Terraform EC2 Image Builder Container Hardening Pipeline GitHub 」リポジトリを参照してください。

├── 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

モジュールの詳細

  • components.tf には、/files ディレクトリのコンテンツをアップロードするための Amazon S3 アップロードリソースが含まれています。カスタムコンポーネントYAMLファイルをモジュールで追加することもできます。

  • /files には、components.tf で使用されるコンポーネントを定義する .yml ファイルが含まれています。

  • image.tf には、基本的なイメージオペレーティングシステムの定義が含まれています。ここで、別のベースイメージパイプラインの定義を変更できます。　

  • infr-config.tf および dist-config.tf には、イメージのスピンアップと配布に必要な最小限のAWSインフラストラクチャのリソースが含まれています。

  • infra-network-config.tf には、コンテナイメージをデプロイする最小VPCインフラストラクチャが含まれています。

  • hardening-pipeline.tfvars の適用時に使用される Terraform 変数が含まれています。

  • pipeline.tf は、Terraform で EC2 Image Builder パイプラインを作成および管理します。

  • recipes.tf では、さまざまなコンポーネントの組み合わせを指定してコンテナレシピを作成できます。

  • roles.tf には、Amazon Elastic Compute Cloud (Amazon IAM) インスタンスプロファイルとパイプラインデプロイロールの AWS Identity and Access Management (EC2) ポリシー定義が含まれています。

  • trigger-build.tf には、 EventBridge ルールとSQSキューリソースが含まれています。

ターゲット アーキテクチャ

強化されたコンテナイメージのパイプラインを構築するためのアーキテクチャとワークフロー

この図は、次のワークフローを示しています。

  1. EC2 Image Builder は、オペレーティングシステムの更新をインストールし、Amazon Linux 2 ベースイメージSTIGに RHEL Medium を適用する定義済みレシピを使用してコンテナイメージを構築します。

  2. 強化されたイメージはプライベート Amazon ECRレジストリに公開され、イメージが正常に公開されると、 EventBridge ルールはSQSキューにメッセージを送信します。

  3. Amazon Inspector が拡張スキャン用に設定されている場合、Amazon ECRレジストリをスキャンします。

  4. Amazon Inspector がイメージの重大度が「重大」または「高」の検出結果を生成すると、 EventBridge ルールによって EC2 Image Builder パイプラインが再度実行され、新しく強化されたイメージが公開されます。

自動化とスケール

  • このパターンでは、インフラストラクチャをプロビジョニングしてコンピュータにパイプラインを構築する方法を説明しています。　 ただし、これは大規模な構築を目的としています。Terraform モジュールをローカルにデプロイする代わりに、Account Factory for Terraform 環境を備えた AWS Control Tower などのマルチアカウント環境で使用できます。 https://aws.amazon.com/blogs/aws/new-aws-control-tower-account-factory-for-terraform/その場合は、設定状態をローカルで管理するのではなく、バックエンド状態の S3 バケットを使用して Terraform 状態ファイルを管理する必要があります。

  • スケーリングされた使用のために、Control Tower またはランディングゾーンアカウントモデルから、共有サービスアカウントや共通サービスアカウントなどの 1 つの中央アカウントにソリューションをデプロイし、Amazon ECRリポジトリとAWSKMSキーにアクセスする許可をコンシューマーアカウントに付与します。セットアップの詳細については、「re:Post」の記事「Amazon イメージリポジトリでセカンダリアカウントがECRイメージをプッシュまたはプルできるようにするにはどうすればよいですか？」を参照してください。例えば、アカウント自動販売機または Account Factory for Terraform で、各アカウントベースラインまたはアカウントカスタマイズベースラインにアクセス許可を追加して、その Amazon ECRリポジトリと暗号化キーへのアクセスを提供します。

  • コンテナイメージパイプラインがデプロイされたら、コンポーネント などの EC2 Image Builder 機能を使用して変更できます。これにより、より多くのコンポーネントを Docker ビルドにパッケージ化できます。

  • コンテナイメージの暗号化に使用されるAWSKMSキーは、イメージの使用が意図されているアカウント間で共有する必要があります。

  • Terraform モジュール全体をコピーし、次の recipes.tf 属性を変更することで、他のイメージのサポートを追加できます：

    • 別の画像タイプを parent_image = "amazonlinux:latest" に変更します。

    • 既存の Amazon ECRリポジトリを指すrepository_nameように を変更します。これにより、別の親イメージタイプを既存の Amazon ECRリポジトリにデプロイする別のパイプラインが作成されます。

ツール

ツール

  • テラフォーム (IaC プロビジョニング)

  • Git (ローカルでプロビジョニングする場合)

  • AWS CLI バージョン 1 またはバージョン 2 (ローカルでプロビジョニングする場合）

コード

このパターンのコードは、 GitHub リポジトリ Terraform EC2 Image Builder Container Hardening Pipeline にあります。次のセクションの指示に従って、サンプルコードを使用します。

エピック

タスク説明必要なスキル

ローカルの認証情報を設定します。

AWS 一時的な認証情報を設定します。

  1. AWS CLI がインストールされているかどうかを確認します。

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

  2. aws configure を実行して、次の値を指定します。

    $ 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

リポジトリをクローン作成します。

  1. このパターンで提供されるリポジトリをクローンします。HTTPS または 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. このソリューションが格納されているローカルディレクトリに移動します。

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

変数を更新します。

環境と必要な構成に合わせて、hardening-pipeline.tfvars ファイル内の変数を更新します。自分で account_id を用意する必要があります。ただし、残りの変数も必要なデプロイに合わせて変更する必要があります。すべての変数が必須です。

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

以下に、各変数の説明を示します。

  • account_id ‒ ソリューションをデプロイするAWSアカウント番号。

  • aws_region ‒ ソリューションをデプロイする AWS リージョン。

  • vpc_name ‒ VPCインフラストラクチャの名前。

  • kms_key_alias EC2‒ Image Builder インフラストラクチャ設定で使用されるAWSKMSキー名。

  • ec2_iam_role_name ‒ EC2インスタンスプロファイルとして使用されるロールの名前。

  • hardening_pipeline_role_name ‒ 強化パイプラインをデプロイするために使用されるロールの名前。

  • aws_s3_ami_resources_bucket ‒ パイプラインとコンテナイメージの構築に必要なすべてのファイルをホストする S3 バケットの名前。

  • image_name ‒ コンテナイメージの名前。この値は 3 ～ 50 文字で、英数字とハイフンのみを含む必要があります。

  • ecr_name ‒ コンテナイメージを保存する Amazon ECRレジストリの名前。

  • recipe_version ‒ イメージ レシピのバージョン。デフォルト値は 1.0.0 です。

  • ebs_root_vol_size ‒ Amazon Elastic Block Store (Amazon ) ルートボリュームのサイズ (ギガバイト単位EBS）。デフォルト値は 10 ギガバイトです。

AWS DevOps

Terraform を初期化します。

変数値を更新した後、Terraform 設定ディレクトリを初期化できます。設定ディレクトリを初期化すると、設定で定義されているAWSプロバイダーがダウンロードされてインストールされます。

terraform init

Terraform が正常に初期化され、インストールされたプロバイダのバージョンを示すメッセージが表示されます。

AWS DevOps

インフラストラクチャをデプロイし、コンテナイメージを作成します。

以下の .tfvars コマンドを使用して、ファイルに定義されている変数を使用して Terraform モジュールを初期化、検証し、環境に適用します。

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

コンテナをカスタマイズします。

EC2 Image Builder がパイプラインと初期レシピをデプロイした後、コンテナレシピの新しいバージョンを作成できます。

EC2 Image Builder で使用可能な 31 以上のコンポーネントのいずれかを追加して、コンテナビルドをカスタマイズできます。詳細については、EC2Image Builder ドキュメントの「コンテナレシピの新しいバージョンを作成する」の「コンポーネント」セクションを参照してください。

AWS 管理者
タスク説明必要なスキル

AWS インフラストラクチャのプロビジョニングを検証します。

最初の Terraform apply コマンドが正常に完了した後、ローカルで設定を行っている場合は、ローカルコンピュータのターミナルに次のスニペットが表示されます：

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

個々のAWSインフラストラクチャリソースを検証します。

ローカルでプロビジョニングする場合、デプロイされた個々のリソースを検証するために、次のコマンドを実行します。

terraform state list

このコマンドは、43 個のリソースのリストを返します。

AWS DevOps
タスク説明必要なスキル

インフラストラクチャとコンテナイメージを削除します。

Terraform の設定が完了した後、次のコマンドを実行してリソースを削除できます。

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

トラブルシューティング

問題ソリューション

プロバイダー認証情報の検証中にエラーが発生しました。

ローカルマシンから Terraform apply または destroy コマンドを実行すると、次のようなエラーが発生する場合があります。

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.

このエラーは、ローカルマシンの設定で使用されている認証情報のセキュリティトークンの有効期限が切れていることが原因です。

エラーを解決するには、 AWSCLIドキュメントの「設定の設定と表示」を参照してください。

関連リソース