요약 사전 조건 및 제한 사항 아키텍처 도구 에픽 문제 해결 관련 리소스

Image Builder와 Terraform을 사용하여 강화된 컨테이너 EC2 이미지를 위한 파이프라인을 구축하십시오.

작성자: 마이크 세인크로스 () 와 앤드류 레인즈 () AWS AWS

코드 리포지토리: Terraform EC2 Image Builder 컨테이너 강화 파이프라인	환경: 프로덕션	소스: Packer, Chef 또는 Pure Ansible
대상: EC2 Image Builder	R 유형: 리아키텍트	워크로드: 오픈 소스
기술: 보안, ID, 규정 준수 DevOps	AWS서비스: 아마존 EC2 컨테이너 레지스트리, EC2 Image Builder

요약

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

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

참고: Amazon Linux 2의 지원이 거의 종료되었습니다. 자세한 내용은 Amazon Linux 2를 참조하십시오FAQs.

사전 조건 및 제한 사항

사전 조건

인프라를 배포할 수 있는 AWS계정.
AWS로컬 배포용 AWS 자격 증명을 설정하기 위해 명령줄 인터페이스 (AWSCLI) 가 설치되었습니다.
Terraform 설명서의 지침에 따라 Terraform을 다운로드하고 설정했습니다.
Git (로컬 시스템에서 프로비저닝하는 경우)
AWS리소스를 생성하는 데 사용할 수 있는 AWS 계정 내 역할입니다.
모든 변수는 .tfvars 파일에 정의되어 있습니다. 또는 Terraform 구성을 적용할 때 모든 변수를 정의할 수 있습니다.

제한 사항

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

제품 버전

Amazon Linux 2
AWSCLI버전 1.1 이상

아키텍처

대상 기술 스택

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

Amazon Simple Storage Service (Amazon S3) 버킷 2개: 하나는 파이프라인 구성 요소 파일용이고 다른 하나는 서버 액세스 및 Amazon 흐름 로그용입니다. VPC
아마존 ECR 리포지토리
퍼블릭 서브넷, 프라이빗 서브넷, 라우팅 테이블, 게이트웨이 및 인터넷 NAT 게이트웨이를 포함하는 가상 사설 클라우드 (VPC)
EC2Image Builder 파이프라인, 레시피, 컴포넌트
컨테이너 이미지
이미지 암호화를 위한 AWS 키 관리 서비스 (AWSKMS) 키
SQS 대기열
역할 3개: EC2 Image Builder 파이프라인을 실행하는 역할 1개, EC2 Image Builder용 인스턴스 프로필 1개, EventBridge 규칙을 위한 역할 1개
두 가지 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이미지를 스핀업하고 배포하는 데 필요한 최소 AWS 인프라를 위한 리소스도 dist-config.tf 포함되어 있습니다.
infra-network-config.tf컨테이너 이미지를 배포하기 위한 최소 VPC 인프라를 포함합니다.
hardening-pipeline.tfvars은(는) 적용 시 사용할 Terraform 변수를 포함합니다.
pipeline.tfTerraform에서 EC2 Image Builder 파이프라인을 생성하고 관리합니다.
recipes.tf은(는) 다양한 구성 요소 조합을 지정하여 컨테이너 레시피를 생성할 수 있는 곳입니다.
roles.tfAmazon Elastic Compute Cloud (AmazonIAM) 인스턴스 프로필 및 파이프라인 배포 역할에 대한 AWS Identity 및 Access Management (EC2) 정책 정의가 포함되어 있습니다.
trigger-build.tf EventBridge 규칙과 SQS 큐 리소스가 포함되어 있습니다.

대상 아키텍처

강화된 컨테이너 이미지를 위한 파이프라인을 구축하기 위한 아키텍처 및 워크플로

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

EC2Image Builder는 정의된 레시피를 사용하여 컨테이너 이미지를 빌드합니다. 레시피는 운영 체제 업데이트를 설치하고 RHEL STIG Medium을 Amazon Linux 2 기본 이미지에 적용합니다.
강화된 이미지는 프라이빗 Amazon ECR 레지스트리에 게시되며, 이미지가 성공적으로 게시되면 EventBridge 규칙에 따라 SQS 대기열에 메시지가 전송됩니다.
Amazon Inspector가 향상된 스캔을 위해 구성된 경우 Amazon 레지스트리를 스캔합니다. ECR
Amazon Inspector에서 이미지에 대한 심각도 또는 높음 심각도를 생성하는 경우, EventBridge 규칙에 따라 EC2 Image Builder 파이프라인이 다시 실행되어 새로 강화된 이미지를 게시합니다.

자동화 및 규모 조정

이 패턴은 컴퓨터에 인프라를 프로비저닝하고 파이프라인을 구축하는 방법을 설명합니다. 하지만 이는 대규모로 사용하기 위한 것입니다. Terraform 모듈을 로컬로 배포하는 대신 Terraform용 Account Factory가 있는 Control Tower AWS 환경과 같은 다중 계정 환경에서 사용할 수 있습니다. 이 경우 구성 상태를 로컬에서 관리하는 대신 백엔드 상태 S3 버킷을 사용하여 Terraform 상태 파일을 관리해야 합니다.
확장 사용을 위해 Control Tower 또는 landing zone 계정 모델에서 Shared Services 또는 Common Services 계정과 같은 하나의 중앙 계정에 솔루션을 배포하고 소비자 계정에 Amazon ECR 리포지토리와 AWS KMS 키에 액세스할 수 있는 권한을 부여하십시오. 설정에 대한 자세한 내용은 re:post 문서를 참조하십시오. Amazon 이미지 저장소에서 보조 계정이 ECR 이미지를 푸시하거나 가져오도록 허용하려면 어떻게 해야 합니까? 예를 들어 계정 자동 판매기 또는 Account Factory for Terraform에서 각 계정 기준 또는 계정 사용자 지정 기준에 권한을 추가하여 해당 Amazon ECR 리포지토리 및 암호화 키에 대한 액세스를 제공합니다.
컨테이너 이미지 파이프라인이 배포된 후에는 구성 요소와 같은 EC2 Image Builder 기능을 사용하여 수정할 수 있으며, 이를 통해 더 많은 구성 요소를 Docker 빌드에 패키징할 수 있습니다.
컨테이너 이미지를 암호화하는 데 사용되는 AWS KMS 키는 이미지를 사용할 계정 간에 공유해야 합니다.
전체 Terraform 모듈을 복제하고 다음 recipes.tf 속성을 수정하여 다른 이미지에 대한 지원을 추가할 수 있습니다.
- parent_image = "amazonlinux:latest"을(를) 다른 이미지 유형으로 수정하십시오.
- 기존 Amazon ECR 리포지토리를 repository_name 가리키도록 수정하십시오. 그러면 기존 Amazon ECR 리포지토리에 다른 상위 이미지 유형을 배포하는 또 다른 파이프라인이 생성됩니다.

도구

Terraform (IaC 프로비저닝)
Git (로컬에서 프로비저닝하는 경우)
AWSCLI버전 1 또는 버전 2 (로컬에서 프로비저닝하는 경우)

코드

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

에픽

작업	설명	필요한 기술
로컬 보안 인증을 설정합니다.	임시 자격 증명을 설정하세요. AWS 가 설치되어 AWS CLI 있는지 확인하세요. `$ aws --version aws-cli/1.16.249 Python/3.6.8...` AWSCLI버전은 1.1 이상이어야 합니다. 명령을 찾을 수 없는 경우 를 설치하십시오 AWS 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>`	AWS DevOps
리포지토리를 복제합니다.	이 패턴과 함께 제공된 리포지토리를 복제하십시오. HTTPS또는 보안 셸 (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` 다음 솔루션이 포함된 로컬 디렉터리로 이동합니다. `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 인프라 구성에서 사용할 AWS 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 엘라스틱 블록 스토어 (Amazon) 루트 볼륨의 크기 (기가바이트EBS). 기본값은 10GB입니다.	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
컨테이너를 사용자 지정합니다.	EC2Image Builder에서 파이프라인과 초기 레시피를 배포한 후 새 버전의 컨테이너 레시피를 생성할 수 있습니다. EC2Image Builder에서 사용할 수 있는 31개 이상의 구성 요소를 추가하여 컨테이너 빌드를 사용자 지정할 수 있습니다. 자세한 내용은 EC2 Image Builder 설명서에서 새 버전의 컨테이너 레시피 만들기의 구성 요소 섹션을 참조하십시오.	AWS관리자

작업 설명 필요한 기술

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

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 구성 작업을 마치면 다음 명령을 실행하여 리소스를 제거할 수 있습니다.


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

AWS DevOps

문제 해결

문제 Solution

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

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

로컬 시스템에서 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.

이 오류는 로컬 시스템 구성에 사용된 보안 인증 정보의 보안 토큰이 만료되어 발생합니다.

오류를 해결하려면 AWS CLI 설명서의 구성 설정 설정 및 보기를 참조하십시오.