EC2 Image Builder와 Terraform을 사용하여 강화된 컨테이너 이미지용 파이프라인 구축

PDF

Mike Saintcross 및 Andrew Ranes가 작성

요약

이 패턴은 강화된 Amazon Linux 2 기본 컨테이너 이미지를 생성하는 EC2 Image Builder 파이프라인을 구축합니다. Terraform은 강화된 컨테이너 이미지를 생성하는 데 사용되는 인프라를 구성하고 프로비저닝하기 위한 코드형 인프라(IaC) 도구로 사용됩니다. 이 레시피는 레드햇 엔터프라이즈 리눅스 (RHEL) 7 STIG 버전 3 릴리스 7 ‒ 미디엄에 따라 강화된 도커 기반 Amazon 리눅스 2 컨테이너 이미지를 배포하는 데 도움이 됩니다. (EC2 Image Builder 설명서의 Linux STIG 구성 요소 섹션에서 STIG-Build-Linux-Medium 버전 2022.2.1을 참조하십시오.) 이를 골든 컨테이너 이미지라고 합니다.

이 빌드에는 두 개의 Amazon EventBridge 규칙이 포함되어 있습니다. 한 가지 규칙은 Amazon Inspector의 조사 결과가 높음 또는 중요일 때 컨테이너 이미지 파이프라인을 시작하여 비보안 이미지가 대체되도록 하는 것입니다. 이 규칙을 사용하려면 Amazon Inspector와 Amazon Elastic Container Registry(Amazon ECR)의 향상된 스캔 기능을 모두 활성화해야 합니다. 또 다른 규칙은 Amazon ECR 리포지토리로 이미지 푸시가 성공한 후 Amazon Simple Queue Service(Amazon SQS) 대기열에 알림을 전송하여 최신 컨테이너 이미지를 사용할 수 있도록 합니다.

참고

Amazon Linux 2의 지원 종료가 가까워지고 있습니다. 자세한 내용은 Amazon Linux 2 FAQs.

사전 조건 및 제한 사항

사전 조건 

• 인프라를 배포할 수 있는 계정.

• 로컬 배포를 위한 보안 인증을 설정하기 위해 Command Line Interface(CLI)가 설치되었습니다.

• Terraform 설명서의 지침에 따라 Terraform을 다운로드하고 설정했습니다.

• Git (로컬 시스템에서 프로비저닝하는 경우)

• 리소스를 생성하는 데 사용할 수 있는 계정 내 역할.

• 모든 변수는 .tfvars 파일에 정의되어 있습니다.  또는 Terraform 구성을 적용할 때 모든 변수를 정의할 수 있습니다.

제한 사항

• 이 솔루션은 프라이빗 서브넷에서의 인터넷 연결을 위한 NAT 게이트웨이와 인터넷 게이트웨이를 포함하는 Amazon Virtual Private Cloud(VPC) 인프라를 생성합니다. 태스크 오케스트레이터 및 실행자(AWSTOE)의 부트스트랩 프로세스가 인터넷에서 CLI 버전 2를 설치하기 때문에 VPC 엔드포인트를 사용할 수 없습니다.

제품 버전

• Amazon Linux 2

• CLI 버전 1.1 이상

아키텍처

대상 기술 스택

이 패턴은 다음을 포함하여 43개의 리소스를 생성합니다.

• Amazon Simple Storage Service(S3) 버킷 2개: 하나는 파이프라인 구성 요소 파일용, 다른 하나는 서버 액세스 및 Amazon VPC 흐름 로그용

• Amazon ECR 리포지토리

• 퍼블릭 서브넷, 프라이빗 서브넷, 라우팅 테이블, NAT 게이트웨이 및 인터넷 게이트웨이가 포함된 VPC

• EC2 Image Builder 파이프라인, 레시피, 구성 요소

• 컨테이너 이미지

• 이미지 암호화를 위한 Key Management Service(KMS) 키

• SQS 대기열

• 세 가지 역할: EC2 이미지 빌더 파이프라인을 실행하는 역할, EC2 이미지 빌더용 인스턴스 프로파일, 이벤트 브리지 규칙용 역할

• 두 가지 EventBridge 규칙

Terraform 모듈 구조

소스 코드는 GitHub 리포지토리 Terraform EC2 Image Builder 컨테이너 강화 파이프라인을 참조하십시오.

├── 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은(는) 이미지를 가동하고 배포하는 데 필요한 최소 인프라를 위한 리소스를 포함합니다.

• 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) 인스턴스 프로파일 및 파이프라인 배포 역할에 대한 Identity 및 Access Management(IAM) 정책 정의가 포함되어 있습니다.

• trigger-build.tf에는 EventBridge 규칙 및 SQS 대기열 리소스가 들어 있습니다.

대상 아키텍처

다이어그램은 다음 워크플로를 보여줍니다:

1. EC2 Image Builder는 정의된 레시피를 사용하여 컨테이너 이미지를 구축합니다. 이 레시피는 운영 체제 업데이트를 설치하고 Amazon Linux 2 기본 이미지에 RHEL Medium STIG를 적용합니다.

2. 강화된 이미지는 프라이빗 Amazon ECR 레지스트리에 게시되며, 이미지가 성공적으로 게시되면 EventBridge 규칙이 SQS 대기열에 메시지를 보냅니다.

3. Amazon Inspector가 향상된 스캔을 위해 구성된 경우 Amazon ECR 레지스트리를 스캔합니다.

4. Amazon Inspector에서 이미지에 대한 중요 또는 높음 심각도를 생성하면 EventBridge 규칙이 EC2 Image Builder 파이프라인을 다시 실행하여 새로 강화된 이미지를 게시하도록 트리거합니다.

자동화 및 규모 조정

• 이 패턴은 컴퓨터에 인프라를 프로비저닝하고 파이프라인을 구축하는 방법을 설명합니다. 하지만 이는 대규모로 사용하기 위한 것입니다. Terraform 모듈을 로컬에 배포하는 대신 Terraform용 Account Factory가 있는 Control Tower 환경과 같은 다중 계정 환경에서 사용할 수 있습니다. 이 경우 구성 상태를 로컬에서 관리하는 대신 백엔드 상태 S3 버킷을 사용하여 Terraform 상태 파일을 관리해야 합니다.

• 확장된 사용을 위해 Control Tower 또는 랜딩 존 계정 모델에서 Shared Services 또는 Common Services 계정과 같은 하나의 중앙 계정에 솔루션을 배포하고 소비자 계정에 Amazon ECR 리포지토리와 KMS 키에 액세스할 수 있는 권한을 부여하십시오. 설정에 대한 자세한 내용은 re:Post 문서 Amazon ECR 이미지 리포지토리에서 보조 계정이 이미지를 푸시하거나 가져오도록 허용하려면 어떻게 해야 합니까?를 참조하십시오. 예를 들어 계정 자동 판매기 또는 Account Factory for Terraform에서 각 계정 기준 또는 계정 사용자 지정 기준에 권한을 추가하여 해당 Amazon ECR 리포지토리 및 암호화 키에 대한 액세스를 제공합니다.

• 컨테이너 이미지 파이프라인이 배포된 후에는 구성 요소와 같은 EC2 Image Builder 기능을 사용하여 수정할 수 있으며, 이를 통해 더 많은 구성 요소를 Docker 빌드에 패키징할 수 있습니다.

• 컨테이너 이미지를 암호화하는 데 사용되는 KMS 키는 이미지를 사용할 계정 간에 공유해야 합니다.

• 전체 Terraform 모듈을 복제하고 다음 recipes.tf 속성을 수정하여 다른 이미지에 대한 지원을 추가할 수 있습니다.

  • parent_image = "amazonlinux:latest"을(를) 다른 이미지 유형으로 수정하십시오.

  • repository_name이(가) 기존 Amazon ECR 리포지토리를 가리키도록 수정하십시오. 그러면 기존 Amazon ECR 리포지토리에 다른 상위 이미지 유형을 배포하는 또 다른 파이프라인이 생성됩니다.

도구

도구

• Terraform (IaC 프로비저닝)

• Git (로컬에서 프로비저닝하는 경우)

• CLI 버전 1 또는 버전 2 (로컬에서 프로비저닝하는 경우)

코드

이 패턴의 코드는 GitHub 리포지토리 Terraform EC2 Image Builder 컨테이너 강화 파이프라인에 있습니다. 샘플 코드를 사용하려면 다음 섹션의 지침을 따르십시오.

에픽

인프라 프로비저닝

작업	설명	필요한 기술
로컬 보안 인증을 설정합니다.	임시 보안 인증을 설정합니다. CLI가 설치되었는지 확인합니다. $ aws --version aws-cli/1.16.249 Python/3.6.8... CLI 버전은 1.1 이상이어야 합니다. 명령을 찾을 수 없는 경우, CLI를 설치하십시오. 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>	DevOps
리포지토리를 복제합니다.	이 패턴과 함께 제공된 리포지토리를 복제하십시오. HTTPS 또는 Secure Shell(SSH)을 사용할 수 있습니다. HTTPS: git clone https://github.com/aws-samples/terraform-ec2-image-builder-container-hardening-pipeline SSH: git clone [e-mail]:aws-samples/terraform-ec2-image-builder-container-hardening-pipeline.git 다음 솔루션이 포함된 로컬 디렉터리로 이동합니다. cd terraform-ec2-image-builder-container-hardening-pipeline	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_region ‒ 솔루션을 배포할 리전입니다. vpc_name ‒ VPC 인프라의 이름. kms_key_alias ‒ EC2 Image Builder 인프라 구성에서 사용할 KMS 키 이름입니다. 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) 루트 볼륨의 크기 (기가바이트). 기본값은 10GB입니다.	DevOps
Terraform을 초기화합니다.	변수 값을 업데이트한 후 Terraform 구성 디렉터리를 초기화할 수 있습니다. 구성 디렉터리를 초기화하면 구성에 정의된 공급자가 다운로드되고 설치됩니다. terraform init Terraform이 성공적으로 초기화되었으며 설치된 제공자의 버전을 식별한다는 메시지가 표시되어야 합니다.	DevOps
인프라를 배포하고 컨테이너 이미지를 생성합니다.	다음 명령을 사용하여 .tfvars 파일에 정의된 변수를 사용하여 Terraform 모듈을 초기화, 검증 및 환경에 적용하십시오. terraform init && terraform validate && terraform apply -var-file *.tfvars -auto-approve	DevOps
컨테이너를 사용자 지정합니다.	EC2 Image Builder에서 파이프라인과 초기 레시피를 배포한 후 새 버전의 컨테이너 레시피를 생성할 수 있습니다. EC2 Image Builder에서 사용 가능한 31개 이상의 구성 요소를 추가하여 컨테이너 빌드를 사용자 지정할 수 있습니다. 자세한 내용은 EC2 Image Builder 설명서에서 새 버전의 컨테이너 레시피 생성의 구성 요소 섹션을 참조하십시오.	관리자

인프라 프로비저닝

작업	설명	필요한 기술
로컬 보안 인증을 설정합니다.	임시 보안 인증을 설정합니다. CLI가 설치되었는지 확인합니다. $ aws --version aws-cli/1.16.249 Python/3.6.8... CLI 버전은 1.1 이상이어야 합니다. 명령을 찾을 수 없는 경우, CLI를 설치하십시오. 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>	DevOps
리포지토리를 복제합니다.	이 패턴과 함께 제공된 리포지토리를 복제하십시오. HTTPS 또는 Secure Shell(SSH)을 사용할 수 있습니다. HTTPS: git clone https://github.com/aws-samples/terraform-ec2-image-builder-container-hardening-pipeline SSH: git clone [e-mail]:aws-samples/terraform-ec2-image-builder-container-hardening-pipeline.git 다음 솔루션이 포함된 로컬 디렉터리로 이동합니다. cd terraform-ec2-image-builder-container-hardening-pipeline	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_region ‒ 솔루션을 배포할 리전입니다. vpc_name ‒ VPC 인프라의 이름. kms_key_alias ‒ EC2 Image Builder 인프라 구성에서 사용할 KMS 키 이름입니다. 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) 루트 볼륨의 크기 (기가바이트). 기본값은 10GB입니다.	DevOps
Terraform을 초기화합니다.	변수 값을 업데이트한 후 Terraform 구성 디렉터리를 초기화할 수 있습니다. 구성 디렉터리를 초기화하면 구성에 정의된 공급자가 다운로드되고 설치됩니다. terraform init Terraform이 성공적으로 초기화되었으며 설치된 제공자의 버전을 식별한다는 메시지가 표시되어야 합니다.	DevOps
인프라를 배포하고 컨테이너 이미지를 생성합니다.	다음 명령을 사용하여 .tfvars 파일에 정의된 변수를 사용하여 Terraform 모듈을 초기화, 검증 및 환경에 적용하십시오. terraform init && terraform validate && terraform apply -var-file *.tfvars -auto-approve	DevOps
컨테이너를 사용자 지정합니다.	EC2 Image Builder에서 파이프라인과 초기 레시피를 배포한 후 새 버전의 컨테이너 레시피를 생성할 수 있습니다. EC2 Image Builder에서 사용 가능한 31개 이상의 구성 요소를 추가하여 컨테이너 빌드를 사용자 지정할 수 있습니다. 자세한 내용은 EC2 Image Builder 설명서에서 새 버전의 컨테이너 레시피 생성의 구성 요소 섹션을 참조하십시오.	관리자

리소스 검증

작업	설명	필요한 기술
인프라 프로비저닝을 검증합니다.	첫 번째 Terraform apply 명령을 성공적으로 완료한 후 로컬에서 프로비저닝하는 경우 로컬 시스템의 터미널에서 다음 스니펫을 확인할 수 있습니다. Apply complete! Resources: 43 added, 0 changed, 0 destroyed.	DevOps
개별 인프라 리소스를 검증합니다.	로컬에서 프로비저닝하려면 다음 명령을 실행하면 배포된 개별 리소스의 유효성을 검사할 수 있습니다. terraform state list 이 명령은 43개 리소스 목록을 반환합니다.	DevOps

리소스 검증

작업	설명	필요한 기술
인프라 프로비저닝을 검증합니다.	첫 번째 Terraform apply 명령을 성공적으로 완료한 후 로컬에서 프로비저닝하는 경우 로컬 시스템의 터미널에서 다음 스니펫을 확인할 수 있습니다. Apply complete! Resources: 43 added, 0 changed, 0 destroyed.	DevOps
개별 인프라 리소스를 검증합니다.	로컬에서 프로비저닝하려면 다음 명령을 실행하면 배포된 개별 리소스의 유효성을 검사할 수 있습니다. terraform state list 이 명령은 43개 리소스 목록을 반환합니다.	DevOps

리소스 제거

작업	설명	필요한 기술
인프라 및 컨테이너 이미지를 제거합니다.	Terraform 구성 작업을 마치면 다음 명령을 실행하여 리소스를 제거할 수 있습니다. terraform init && terraform validate && terraform destroy -var-file *.tfvars -auto-approve	DevOps

리소스 제거

작업	설명	필요한 기술
인프라 및 컨테이너 이미지를 제거합니다.	Terraform 구성 작업을 마치면 다음 명령을 실행하여 리소스를 제거할 수 있습니다. terraform init && terraform validate && terraform destroy -var-file *.tfvars -auto-approve	DevOps

문제 해결

문제

Solution

공급자 보안 인증을 검증하는 중 오류가 발생했습니다.

로컬 시스템에서 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. 이 오류는 로컬 시스템 구성에 사용된 보안 인증 정보의 보안 토큰이 만료되어 발생합니다. 오류를 해결하려면 CLI 설명서의 구성 설정 지정 및 보기를 참조하십시오.

관련 리소스

• Terraform EC2 Image Builder 컨테이너 하드닝 파이프라인 (GitHub 리포지토리)

• EC2 Image Builder 설명서

• Terraform용 Control Tower 어카운트 팩토리 (블로그 게시물)

• 백엔드 상태 S3 버킷 (Terraform 설명서)

• CLI의 최신 버전 설치 또는 업데이트 (CLI 설명서)

• Terraform 다운로드