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

# EC2 Image Builder と Terraform を使用して、強化されたコンテナイメージ用のパイプラインを構築する
<a name="build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform"></a>

*Mike Saintcross、Andrew Ranes (Amazon Web Services)*

## 概要
<a name="build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform-summary"></a>

このパターンは、強化した [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/) ベースコンテナイメージを生成する [EC2 Image Builder パイプライン](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)を構築します。Terraform は、強化されたコンテナイメージの作成に使用されるインフラストラクチャを設定してプロビジョニングするための Infrastructure as Code (IaC) ツールとして使用されます。このレシピは、Red Hat Enterprise Linux (RHEL) 7 STIG バージョン 3 リリース 7 — Medium によって強化された Docker ベースの Amazon Linux 2 コンテナイメージのデプロイに役立ちます。(EC2 Image Builder ドキュメントの「*Linux STIG コンポーネント*」セクションにある「[STIG-Build-Linux-Medium バージョン 2022.2.1](https://docs.aws.amazon.com/imagebuilder/latest/userguide/toe-stig.html#linux-os-stig)」を参照してください。) これは、*ゴールデン*コンテナイメージと呼ばれます。

ビルドには 2 つの [Amazon EventBridge ルール](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html)が含まれています。1 つ目のルールは、[Amazon Inspector の検出結果](https://docs.aws.amazon.com/inspector/latest/user/findings-managing.html)が「**高**」または「**重要**」の場合にコンテナイメージパイプラインを開始し、セキュアでないイメージが置き換えられるようにします。このルールでは、Amazon Inspector と Amazon Elastic Container Registry (Amazon ECR) の両方の[拡張スキャン](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning-enhanced.html)を有効にする必要があります。2 つ目のルールは、Amazon ECR リポジトリへのイメージのプッシュが成功すると、Amazon Simple Queue Service (Amazon SQS) [キュー](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-queue-types.html)に通知を送信します。これにより、最新のコンテナイメージを使用できるようになります。

**注記**  
Amazon Linux 2 のサポートは間もなく終了します。詳細については、「[Amazon Linux 2 に関するよくある質問](https://aws.amazon.com/amazon-linux-2/faqs/)」を参照してください。

## 前提条件と制限事項
<a name="build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform-prereqs"></a>

**前提条件**
+ インフラストラクチャをデプロイできる [AWS アカウント](https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/)。
+ ローカルデプロイ用の AWS 認証情報を設定するために [AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) をインストールします。
+ Terraform ドキュメントの「[指示](https://developer.hashicorp.com/terraform/tutorials/aws-get-started)」に従って Terraform を[ダウンロード](https://developer.hashicorp.com/terraform/downloads)し、セットアップしました。
+ [Git](https://git-scm.com/) (ローカルマシンからプロビジョニングする場合)。
+ AWS リソースの作成に使用できる AWS アカウント内の [ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。
+ [.tfvars](https://developer.hashicorp.com/terraform/tutorials/configuration-language/variables) ファイルで定義されているすべての変数。 または、Terraform 設定を適用するときにすべての変数を定義できます。

**制限事項**
+ このソリューションは、プライベートサブネットからのインターネット接続用の [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) と [インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) を含む Amazon Virtual Private Cloud (Amazon VPC) インフラストラクチャを作成します。[VPC エンドポイント](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html) を使用できないのは、[AWS タスクオーケストレーターおよびエグゼキューター (AWSTOE)](https://aws.amazon.com/premiumsupport/knowledge-center/image-builder-pipeline-execution-error/) によるブートストラップ プロセスでは、インターネットから AWSCLI バージョン 2 がインストールされるためです。

**製品バージョン**
+ Amazon Linux 2
+ AWS CLI バージョン 1.1 以降

## アーキテクチャ
<a name="build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform-architecture"></a>

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

このパターンでは、以下を含む 43 個のリソースが作成されます。
+ 2 つの Amazon Simple Storage Service (Amazon S3) [バケット](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html)。1 つはパイプラインコンポーネントファイル用、もう 1 つはサーバーアクセスと Amazon VPC フローログ用です
+ [Amazon ECR リポジトリ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)
+ パブリックサブネット、プライベートサブネット、ルートテーブル、NAT ゲートウェイ、インターネットゲートウェイを含む仮想プライベートクラウド (VPC)　
+ EC2 Image Builder パイプライン、レシピ、コンポーネント
+ コンテナイメージ
+ イメージを暗号化するための AWS Key Management Service (AWS KMS) [キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys)
+ SQS キュー
+ 3 つのロール: 1 つ目は EC2 Image Builder パイプラインを実行し、2 つ目は EC2 Image Builder 用のインスタンスプロファイルを実行し、3 つ目は EventBridge ルールを実行します。
+ 2 つの EventBridge ルール

**Terraform モジュール構造**

ソースコードについては、GitHub リポジトリの「[Terraform EC2 Image Builder コンテナ強化パイプライン](https://github.com/aws-samples/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
```

**モジュールの詳細**
+ `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 EC2) インスタンスプロファイルとパイプラインデプロイロールの AWS Identity and Access Management (IAM) ポリシー定義が含まれています。
+ `trigger-build.tf` には、EventBridge ルールと SQS キューリソースが含まれています。

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

![\[強化されたコンテナイメージのパイプラインを構築するためのアーキテクチャとワークフロー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4b16bdfa-4f34-41e9-a69a-d023253c8585/images/23443eca-132f-46ac-98bd-32a9e9359a77.png)


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

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

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

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

1. Amazon Inspector がイメージの重大度が「**非常事態**」または「**高**」という検出結果を生成した場合、EventBridge ルールによって EC2 Image Builder パイプラインが再び実行され、新たに強化されたイメージが公開されます。

**自動化とスケール**
+ このパターンでは、インフラストラクチャをプロビジョニングしてコンピュータにパイプラインを構築する方法を説明しています。　 ただし、これは大規模な構築を目的としています。Terraform モジュールをローカルにデプロイする代わりに、[Account Factory for Terraform](https://aws.amazon.com/blogs/aws/new-aws-control-tower-account-factory-for-terraform/) 環境を備えた [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) などのマルチアカウント環境で使用できます。その場合は、設定状態をローカルで管理するのではなく、[バックエンド状態の S3 バケット](https://developer.hashicorp.com/terraform/language/settings/backends/s3)を使用して Terraform 状態ファイルを管理する必要があります。
+ スケーラブルに使用する場合は、Control Tower またはランディングゾーン アカウントモデルから、共有サービスアカウントや共通サービスアカウントなどのある中央アカウントにソリューションをデプロイし、Amazon ECR リポジトリと AWS KMS キーにアクセスする権限をコンシューマーアカウントに付与します。セットアップの詳細については、re: Post の記事「[Amazon ECR イメージリポジトリ内のイメージをセカンダリアカウントにプッシュまたはプルさせるにはどうすればよいですか?](https://repost.aws/knowledge-center/secondary-account-access-ecr)」を参照してください。例えば、[アカウント自動販売機](https://www.hashicorp.com/resources/terraform-landing-zones-for-self-service-multi-aws-at-eventbrite)または Account Factory for Terraform では、各アカウントベースラインまたはアカウントカスタマイズベースラインにアクセス権限を追加して、その Amazon ECR リポジトリと暗号化キーへのアクセスを提供します。
+ コンテナイメージパイプラインがデプロイされたら、[コンポーネント](https://docs.aws.amazon.com/imagebuilder/latest/userguide/manage-components.html) などの EC2 Image Builder 機能を使用してパイプラインを変更できます。これにより、より多くのコンポーネントを Docker ビルドにパッケージ化できます。
+ コンテナイメージの暗号化に使用される AWS KMS キーは、イメージを使用するアカウント間で共有する必要があります。
+ Terraform モジュール全体をコピーし、次の `recipes.tf` 属性を変更することで、他のイメージのサポートを追加できます：
  + 別の画像タイプを `parent_image = "amazonlinux:latest"` に変更します。
  + 既存の Amazon ECR リポジトリを指定するように `repository_name` を変更します。これにより、別の親イメージタイプを既存の Amazon ECR リポジトリにデプロイするパイプラインがもう 1 つ作成されます。

## ツール
<a name="build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform-tools"></a>

**ツール**
+ テラフォーム (IaC プロビジョニング)
+ Git (ローカルでプロビジョニングする場合)
+ AWS CLI バージョン 1 またはバージョン 2 (ローカルにプロビジョニングする場合)

**コード**

ソースコードについては、GitHub リポジトリの「[Terraform EC2 Image Builderコンテナ強化パイプライン](https://github.com/aws-samples/terraform-ec2-image-builder-container-hardening-pipeline)」を参照してください。次のセクションの指示に従って、サンプルコードを使用します。

## エピック
<a name="build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform-epics"></a>

### インフラストラクチャをプロビジョニングする
<a name="provision-the-infrastructure"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| ローカルの認証情報を設定します。 | AWS の一時認証情報を設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform.html) | AWS DevOps | 
| リポジトリをクローン作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform.html) | AWS DevOps | 
| 変数を更新します。 | 環境と必要な構成に合わせて、`hardening-pipeline.tfvars` ファイル内の変数を更新します。自分で `account_id` を用意する必要があります。ただし、残りの変数も必要なデプロイに合わせて変更する必要があります。すべての変数が必須です。<pre>account_id     = "<DEPLOYMENT-ACCOUNT-ID>"<br />aws_region     = "us-east-1"<br />vpc_name       = "example-hardening-pipeline-vpc"<br />kms_key_alias = "image-builder-container-key"<br />ec2_iam_role_name = "example-hardening-instance-role"<br />hardening_pipeline_role_name = "example-hardening-pipeline-role"<br />aws_s3_ami_resources_bucket = "example-hardening-ami-resources-bucket-0123"<br />image_name = "example-hardening-al2-container-image"<br />ecr_name = "example-hardening-container-repo"<br />recipe_version = "1.0.0" <br />ebs_root_vol_size = 10</pre>以下に、各変数の説明を示します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform.html) | AWS DevOps | 
| Terraform を初期化します。 | 変数値を更新した後、Terraform 設定ディレクトリを初期化できます。設定ディレクトリを初期化すると、設定で定義されている AWS プロバイダーがダウンロードおよびインストールされます。　<pre>terraform init</pre>Terraform が正常に初期化され、インストールされたプロバイダのバージョンを示すメッセージが表示されます。 | AWS DevOps | 
| インフラストラクチャをデプロイし、コンテナイメージを作成します。 | 以下の `.tfvars` コマンドを使用して、ファイルに定義されている変数を使用して Terraform モジュールを初期化、検証し、環境に適用します。<pre>terraform init && terraform validate && terraform apply -var-file *.tfvars -auto-approve</pre> | AWS DevOps | 
| コンテナをカスタマイズします。 | EC2 Image Builder がパイプラインと初期レシピをデプロイした後、コンテナレシピの新しいバージョンを作成できます。EC2 Image Builder にある 31 種類以上のコンポーネントのいずれかを追加して、コンテナビルドをカスタマイズできます。詳細については、EC2 Image Builder ドキュメントの「[コンテナレシピの新しいバージョンを作成する](https://docs.aws.amazon.com/imagebuilder/latest/userguide/create-container-recipes.html)」の「*コンポーネント*」セクションを参照してください。 | AWS 管理者 | 

### リソースを検証する
<a name="validate-resources"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| AWS インフラストラクチャのプロビジョニングを検証します。 | 最初の Terraform `apply` コマンドが正常に完了した後、ローカルで設定を行っている場合は、ローカルコンピュータのターミナルに次のスニペットが表示されます：<pre>Apply complete! Resources: 43 added, 0 changed, 0 destroyed.</pre> | AWS DevOps | 
| 個々の AWS インフラストラクチャリソースを検証します。 | ローカルでプロビジョニングする場合、デプロイされた個々のリソースを検証するために、次のコマンドを実行します。<pre>terraform state list</pre>このコマンドは、43 個のリソースのリストを返します。 | AWS DevOps | 

### リソースを削除する
<a name="remove-resources"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| インフラストラクチャとコンテナイメージを削除します。 | Terraform の設定が完了した後、次のコマンドを実行してリソースを削除できます。<pre>terraform init && terraform validate && terraform destroy -var-file *.tfvars -auto-approve</pre> | AWS DevOps | 

## トラブルシューティング
<a name="build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform-troubleshooting"></a>


| 問題 | ソリューション | 
| --- | --- | 
| プロバイダー認証情報の検証中にエラーが発生しました。 | ローカルマシンから Terraform `apply` または `destroy` コマンドを実行すると、次のようなエラーが発生する場合があります。<pre>Error: configuring Terraform AWS Provider: error validating provider <br />credentials: error calling sts:GetCallerIdentity: operation error STS: <br />GetCallerIdentity, https response error StatusCode: 403, RequestID: <br />123456a9-fbc1-40ed-b8d8-513d0133ba7f, api error InvalidClientTokenId: <br />The security token included in the request is invalid.</pre>このエラーは、ローカルマシンの設定で使用されている認証情報のセキュリティトークンの有効期限が切れていることが原因です。このエラーを解決するには、AWS CLI ドキュメントの「[設定の設定と表示](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-methods)」を参照してください。 | 

## 関連リソース
<a name="build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform-resources"></a>
+ 「[Terraform EC2 Image Builder コンテナ強化パイプライン](https://github.com/aws-samples/terraform-ec2-image-builder-container-hardening-pipeline)」
+ [EC2 Image Builder ドキュメント](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)
+ 「[AWS Control Tower Account Factory for Terraform](https://aws.amazon.com/blogs/aws/new-aws-control-tower-account-factory-for-terraform/)」 (AWS ブログ記事)
+ 「[バックエンドステート S3 バケット](https://developer.hashicorp.com/terraform/language/settings/backends/s3)」 (Terraform ドキュメント)
+ 「[AWS CLI の最新バージョンをインストールまたは更新する](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」 (AWS CLI ドキュメント)
+ 「[Terraform をダウンロード](https://developer.hashicorp.com/terraform/downloads)」