Amazon Web Services 한국 블로그
Amazon ECS Exec를 통한 AWS Fargate 및 Amazon EC2 컨테이너 접근하기
AWS는 개발자 및 운영자를 포함한 모든 Amazon ECS 사용자가 Amazon EC2 또는 AWS Fargate에 배포된 태스크 내에서 실행되는 컨테이너에서 exec 명령을 시작할 수 있습니다. ECS Exec라는 기능을 통해 사용자는 컨테이너에 대해 대화형 쉘을 실행하거나 단일 명령을 실행할 수 있습니다. 이는 AWS 컨테이너 로드맵에서 가장 많이 요청을 받은 기능 중 하나였습니다.
사용자가 SSH를 사용하여 개별 컨테이너에 연결해서는 안되며 모니터링, 디버깅 및 로그 분석을 위해 적절한 관찰 가능성 메커니즘을 적용해야 한다는 것은 업계에서 잘 알려진 보안 모범 사례입니다. 이 기능은 모범 사례를 변경하는 것이 아니라 애플리케이션의 보안 태세를 개선하는 데 도움이 됩니다.
특히 애플리케이션 개발 주기의 초기 단계에서 빠른 피드백 루프가 필요한 상황이 있습니다. 예를 들어, 로컬에서 개발 및 테스트 중이고 docker exec 명령을 이용하는 경우 도음이 될 것입니다. 이 기능은 프로덕션 환경에서 발생하는 높은 심각도의 문제를 디버깅하기 위해 컨테이너에 대한 “유리 깨기(break-glass)” 액세스 권한을 얻는 데에도 유용합니다. 여기서 중요한 점은 컨테이너에서 exec-ing 명령을 시작할 때 컨테이너 내부에 설치된 도구와 유틸리티만 사용할 수 있다는 것입니다. 즉, netstat 또는 heapdump 유틸리티가 컨테이너의 기본 이미지에 설치되어 있지 않으면 사용할 수 없습니다.
이 기능이 발표되기 전에 EC2에 태스크를 배포하는 ECS 사용자는 문제를 해결하기 위해 다음과 같은 작업이 필요했습니다.
- EC2 인스턴스에 대한 SSH 액세스 권한 부여
- 포트 열기, 키 또는 암호 배포 등이 필요하므로 여기에도 큰 노력이 필요합니다.
- 클러스터에서 치료가 필요한 태스크가 배포된 특정 EC2 인스턴스 찾기
- SSH로 EC2 인스턴스에 연결
- 문제 해결을 위해 컨테이너에
docker exec명령 사용
이는 (EC2 인스턴스에서 실행 중인) 컨테이너에서 단순히exec 명령을 시작하기 위한 (보안 모범 사례에 반하는) 작업입니다.
또한 Fargate에는 SSH를 사용하여 연결할 수 있는 EC2 인스턴스가 없기 때문에 Fargate에 태스크를 배포하는 ECS 사용자에게는 이 옵션도 없었습니다. Fargate의 ECS에서는 컨테이너에 exec 명령을 실행하는 것이 불가능했습니다. 고객이 선택할 수 있는 옵션 중 하나는 컨테이너에서 exec 명령을 실행가능하도록 하거나 IDE에서 클라우드 디버깅을 사용할 수 있도록 EC2에 태스크를 재배포하는 것이었습니다.
ECS Exec는 AWS SDK, AWS CLI 및 AWS Copilot을 통해 지원됩니다. 앞으로 AWS Console에서 이 기능을 활성화할 예정입니다. 또한 이 기능은 Linux 컨테이너만 지원합니다(ECS Exec에 대한 Windows 컨테이너 지원은 이번 발표에 포함되지 않습니다).
이 글에서는 ECS Exec 기능의 몇 가지 핵심 측면에 대해 자세히 살펴보겠습니다. 여기에는 ECS Exec의 작동 방식 개요, 사전 요구 사항, 보안 고려 사항 등이 포함됩니다. 게시물의 마지막 섹션에서는 이 측면에서 nginx 컨테이너에 대한 직접 쉘 접근 방법을 보여주는 예를 소개합니다.
이 설명에서는 AWS CLI 경험에 중점을 둘 것입니다. AWS Copilot의 맥락에서 이 기능을 활용하는 방법은 이 설명서를 참조하십시오.
ECS Exec 작동 방식
ECS Exec는 AWS Systems Manager(SSM)와 특히 SSM Session Manager를 활용하여 “exec“ 명령을 시작하는 데 사용하는 디바이스와 대상 컨테이너 간에 보안 채널을 생성합니다. 엔지니어링 팀은 GitHub의 설계 제안서에서 작동 방식에 대한 몇 가지 세부 정보를 공유했습니다. 간단히 말하면 필요한 SSM 에이전트 바이너리를 컨테이너에 바인딩하여 탑재하는 것입니다.
또한 ECS 에이전트(또는 Fargate 에이전트)는 애플리케이션 코드와 함께 컨테이너 내에서 SSM 코어 에이전트를 시작할 책임이 있습니다. 이 동작은 AWS에서 완전히 관리하며 사용자에게 완전히 투명하다는 점을 이해하는 것이 중요합니다. 즉, 사용자는 SSM 바이너리가 컨테이너에 바인딩하여 탑재되고 시작되는 이 기반 작업에 대해 알 필요조차 없습니다. 사용자는 Dockerfile에 정의된 대로 애플리케이션 프로세스에만 집중하면 됩니다.
첫 번째 릴리스에서 ECS Exec을 사용하면 쉘에서든 단일 명령을 통해서든 컨테이너와 대화형 세션을 시작할 수 있습니다(docker exec -it과 동일). 가까운 시일 내에 ECS Exec가 비대화형 명령을 컨테이너에 전송하는 것도 지원할 예정입니다(docker exec -t와 동일).
이 기능은 양쪽 모두에서 SSM 기능이 필요하므로 사용자가 배포 및 구성 옵션에 따라 사전 요구 사항으로 설정해야 하는 몇 가지 사항이 있습니다(예: EC2 Vs Fargate). 그러면 다음 섹션인 사전 요구 사항으로 넘어갑니다.
ECS Exec의 사전 요구 사항
앞서 말했듯이 이 기능은 AWS SSM의 구성 요소를 활용합니다. 따라서 이 기능이 작동하기 위해 SSM의 각 부분들이 올바른 위치에 있어야 합니다. 이는 시작 측(예: 랩탑)과 엔드포인트(예: 컨테이너가 실행 중인 EC2 또는 Fargate 인스턴스) 모두에 해당됩니다.
클라이언트 측 요구 사항
AWS CLI를 사용하여 exec 명령을 시작하는 경우 설치해야 하는 유일한 패키지는 AWS CLI용 SSM Session Manager 플러그 인입니다. 사용 중인 플랫폼(Linux, Mac, Windows)에 따라 지침에 맞게 적절한 바이너리를 설정해야 합니다. 또한 AWS CLI v1을 사용 가능한 최신 버전으로 업그레이드해야 합니다. 이 버전에는 추가 ECS Exec 로직과 Session Manager 플러그 인을 연결하여 컨테이너로의 보안 연결을 시작하는 기능이 포함되어 있습니다.
서버 측 요구 사항(Amazon EC2)
설계 제안서에 설명된 대로, 이 기능은 exec 명령을 실행해야 하는 컨테이너가 실행 중인 호스트에서 필요한 SSM 구성 요소를 사용할 수 있을 것으로 예상합니다. 따라서 앞서 언급한 대로 이러한 바이너리를 컨테이너에 바인딩하여 탑재할 수 있습니다.
Amazon 검증을 거친 ECS 최적화 AMI를 사용하는 경우 최신 버전에는 SSM 사전 요구 사항이 이미 포함되어 있으므로 별도로 수행할 작업이 없습니다. 이 초기 릴리스에서는 고객이 보유한 AMI에서 이 새로운 기능의 사전 요구 사항을 추가할 수 있는 방법이 없습니다. 시작 후에 이러한 유연성을 추가할 계획입니다.
서버 측 요구 사항(AWS Fargate)
ECS 태스크와 해당 컨테이너가 Fargate에서 실행 중인 경우 Fargate에는 이 ECS 기능을 활성화하는 데 필요한 모든 인프라 소프트웨어 요구 사항이 이미 포함되어 있으므로 별도로 수행할 작업이 없습니다. Fargate 소프트웨어 스택은 소위 “플랫폼 버전”을 통해 관리되므로(AWS Fargate 플랫폼 버전 입문서를 원할 경우 이 블로그 참조) PV 1.4를 사용하고 있는지 확인하기만 하면 됩니다(이는 최신 버전으로 ECS Exec 사전 요구 사항과 함께 제공됨).
ECS Exec에 대한 인프라 구성
지금까지 사전 요구 사항에 대해 알아봤으므로 이제 이 기능을 호출하고 활용하기 위해 인프라를 어떻게 구성해야 하는지 살펴보겠습니다.
로깅 옵션 구성(선택 사항)
ECS Exec는 대화형 터미널(예: 랩탑, AWS CloudShell 또는 AWS Cloud9)에 세션을 로깅하는 것 외에도 명령 및 명령 출력을 (다음 중 하나 또는 둘 다에) 로깅할 수 있도록 지원합니다.
- Amazon S3 버킷
- Amazon CloudWatch 로그 그룹
이는 AWS CloudTrail에서 명령 자체를 로깅하는 것과 함께 일반적으로 보관 및 감사를 목적으로 수행됩니다.
명령이 쉘(예: “/bin/bash”)을 호출하면 컨테이너에 대한 대화형 접근 권한을 얻을 수 있다는 점에 유의하십시오. 이 경우 세션 내의 모든 명령과 해당 출력이 S3나 CloudWatch에 로깅됩니다. 셸 호출 명령과 이를 호출한 사용자가 감사 목적으로 ECS ExecuteCommand API 호출의 일부로 AWS CloudTrail에 로깅됩니다.
그러나 명령이 단일 명령(예: “pwd”)을 호출하는 경우 명령의 출력만 S3나 CloudWatch에 로깅되고 명령 자체는 ECS ExecuteCommand API 호출의 일부로 AWS CloudTrail에 로깅됩니다. 감사의 경우 로그의 항목과 AWS CloudTrail의 해당 API 호출 간의 연관성을 파악하기 위한 추가 단계가 필요합니다. 앞으로 이 작업을 간소화할 계획입니다.
또한 컨테이너 이미지에 script(util-linux의 일부)와 cat(coreutils의 일부)를 설치해야 명령 로그가 S3 나 CloudWatch에 올바르게 업로드된다는 것이 중요합니다. 이 블로그의 끝에 있는 설명에서는 이 지원이 이미 설치되어 있는 nginx 컨테이너 이미지를 사용할 것입니다. 이미지에 설치되어 있는지 확인합니다.
이러한 로깅 옵션은 ECS 클러스터 수준에서 구성됩니다. 새로운 AWS CLI는 이 구성을 지정할 수 있는 create-cluster 및 update-cluster 명령에 대한 새로운 --configuration 플래그(선택 사항)를 지원합니다. 이 게시물의 끝에 있는 설명에는 create-cluster 명령의 예가 나와 있지만, 배경의 경우 새로운 executeCommandConfiguration 옵션의 구문은 다음과 같습니다.
executeCommandConfiguration={kmsKeyId=string,\
logging=string,\
logConfiguration={cloudWatchLogGroupName=string,\
cloudWatchEncryptionEnabled=boolean,\
s3BucketName=string,\
s3EncryptionEnabled=boolean,\
s3KeyPrefix=string}}logging 변수는 ECS Exec 로깅 기능의 동작을 결정합니다.
- NONE: 로깅 비활성화
- DEFAULT: 구성된
awslogs드라이버로 로깅(드라이버가 구성되지 않은 경우 로그가 저장되지 않음) - OVERRIDE: 제공된 CloudWatch LogGroup나 S3 버킷으로 로깅
이 새로운 플래그에 대한 자세한 설명은 AWS CLI 설명서를 참조하세요.
우리는 exec 세션의 출력 로깅에 대해 이야기하고 있습니다. 이는 애플리케이션 로깅과는 아무런 관련이 없습니다. 애플리케이션은 일반적으로 stdout 또는 로그 파일로 로그를 내보내도록 구성되며 이 로깅은 이 게시물에서 설명하는 exec 명령 로깅과 다릅니다.
적절한 IAM 정책으로 태스크 역할 구성
컨테이너는 (애플리케이션과 동시에) SSM 코어 에이전트를 실행합니다. 이 에이전트가 호출될 때 SSM 서비스를 호출하여 보안 채널을 생성합니다. 따라서 ECS 태스크에는 SSM 코어 에이전트가 SSM 서비스를 호출할 수 있는 적절한 IAM 권한이 있어야 합니다. 이렇게 하려면 ECS 태스크 역할에 이를 허용하는 IAM 권한의 집합이 포함되어야 합니다.
확실히 말하자면 SSM 에이전트는 별도의 컨테이너 사이드카로 실행되지 않습니다. SSM 에이전트는 애플리케이션 컨테이너 내에서 추가 프로세스로 실행됩니다. 이 GitHub의 설계 제안서에 이에 대한 자세한 내용이 있습니다.
또한 클러스터가 이러한 옵션에 맞게 구성된 경우 태스크 역할에는 S3나 CloudWatch에 출력을 로깅할 수 있는 IAM 권한이 있어야 합니다. 이러한 옵션이 구성되지 않은 경우 이러한 IAM 권한이 필요하지 않습니다.
이 게시물 끝에 있는 실제 설명에는 이에 대한 예가 나와 있습니다.
ECS Exec에 대한 보안 및 감사 제어 구성
지금까지 사전 요구 사항과 인프라 구성에 대해 살펴봤습니다. 이제 새로운 ECS Exec 기능에 대한 보안 제어 및 규정 준수 지원에 대해 살펴보겠습니다.
IAM 보안 제어
예상하신대로 보안은 기본적으로 보안 주체(IAM 사용자, IAM 그룹 및 IAM 역할)에 연결된 IAM 정책을 통해 통합 및 구성되어 명령 실행을 호출할 수 있습니다.
이 제어는 새로운 ecs:ExecuteCommand IAM 작업에 의해 관리됩니다. 사용자 권한은 클러스터 수준에서 특정 ECS 태스크 내의 단일 컨테이너까지 세부적으로 범위를 지정할 수 있습니다. 태스크 배포의 매우 동적인 특성으로 인해 사용자는 특정 작업을 가리키는 정책에만 의존할 수 없습니다. 대신 태스크에 태그를 지정하고 해당 태그에 적절한 조건을 지정하여 IAM 정책을 생성하는 것이 좋습니다. ecs:ResourceTag/tag-key 조건 키와 aws:ResourceTag/tag-key 조건 키가 모두 지원됩니다. 액세스를 제한하도록 범위가 축소된 정책의 예는 다음과 같습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:ExecuteCommand"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/tag-key": "tag-value"",
"StringEquals": {
"ecs:container-name": "<container_name>"
}
}
},
"Resource":"arn:aws:ecs:<region>:<aws_account_id>:cluster/<cluster_name>"
}
]
}이 정책은 특정 이름 및 특정 클러스터의 컨테이너에서만 exec 명령을 시작할 수 있도록 IAM 보안 주체의 범위를 축소합니다. 또한 위에서 언급한 것처럼 태그에 정책 조건을 사용할 수도 있습니다.
향후 비대화형 명령 지원을 시작할 때 허용되는 상호 작용 유형을 제한하는 제어도 제공할 것입니다(예: 한 사용자는 “비대화형” 명령만 실행할 수 있는 반면 다른 사용자는 “대화형” 명령과 “비대화형” 명령을 실행할 수 있음).
보안 및 감사
처음에 말했듯이 사용자가 ssh를 사용하여 개별 태스크에 연결할 수 있도록 허용하는 것은 종종 안티 패턴으로 간주되며 특히 규제가 엄격한 환경에서 문제를 일으킬 수 있습니다. 따라서 엄격한 IAM 제어 외에도 모든 ECS Exec 요청이 감사 목적으로 AWS CloudTrail에 로깅됩니다.
AWS API 호출만 (호출된 명령과 함께) 로깅된다는 점을 이해하는 것이 중요합니다. 예를 들어 대화형 셸 섹션을 열면
/bin/bash명령만 CloudTrail에 로깅되고 셸 내의 다른 모든 항목은 로깅되지 않습니다. 하지만 클러스터가 이렇게 구성된 경우 이러한 셸 명령과 해당 출력이 CloudWatch 및/또는 S3에 로깅됩니다.
아래 연습에는 이 시나리오에 대한 예가 나와 있습니다.
데이터 채널 암호화
클라이언트와 연결하려는 컨테이너 간의 통신은 기본적으로 TLS1.2를 사용하여 암호화됩니다. 하지만보유한 AWS Key Management Service(KMS) 키를 사용하여 이 데이터 채널을 암호화할 수 있습니다. ECS 클러스터 구성 재정의는 고객 키를 선택적 파라미터로 구성할 수 있도록 지원합니다. 지정되면 지정된 키를 사용하여 암호화가 수행됩니다. 궁극적으로 ECS Exec는 SSM 설명서에 설명된 핵심 SSM 기능을 활용합니다.
AWS CLI 워크플로를 통한 ECS Exec 작동 방식
지금까지 이론을 알아봤습니다. 이제 실용적인 예를 살펴보겠습니다. 다음 연습에서는 Fargate에서 실행 중인 태스크의 일부인 nginx 컨테이너에서 대화형 셸을 활용하는 방법을 보여 줍니다. 이 예는 실제 문제 해결 시나리오에 영감을 주는 것이 아니라 기능 자체에 중점을 둡니다. 이러한 핵심 문제 해결 기능을 적용하기 위해 생각할 수 있는 기회와 시나리오가 부족하지 않을 것이라고 확신합니다.
무엇보다 먼저 위에서 설명한 “클라이언트 측 요구 사항”이 있는지 확인합니다. 즉, AWS CLI용 SSM Session Manager 플러그 인 뿐만 아니라 사용 가능한 최신 AWS CLI 버전도 있습니다.
다음 단계는 태스크를 처음부터 배포하는 것을 목표로 합니다. 숙련된 Amazon ECS 사용자인 경우 아래의 특정 ECS Exec 구성을 기존 태스크 및 IAM 역할에 적용할 수 있습니다. AWS Copilot CLI 사용자이고 AWS CLI 연습에 관심이 없는 경우 Copilot 설명서를 대신 참조하십시오. 다시 말해, 이 기능은 나중에 AWS Management Console의 Amazon ECS를 통해서도 사용할 수 있습니다.
AWS CLI는 현재 다음 단계를 성공적으로 실행할 수 있도록 상당히 강력한 보안 인증으로 구성되어 있습니다.
먼저 빈 폴더를 새로 만들고 해당 폴더로 이동해 보겠습니다. 또한 나중에 사용할 몇 가지 변수를 선언합니다. 여기에는 리전, 기본 VPC, 기본 VPC의 퍼블릭 서브넷 2개를 설정하는 것이 포함됩니다. 또한 버킷 이름은 고유해야 하므로 아래 내보내기에서 임의의 버킷 이름을 설정해야 합니다(이 예에서는 ecs-exec-demo-output-3637495736 사용).
export AWS_REGION=<xxxxxxx>
export VPC_ID=<vpc-xxxx>
export PUBLIC_SUBNET1=<subnet-xxxxx>
export PUBLIC_SUBNET2=<subnet-xxxxx>
export ECS_EXEC_BUCKET_NAME=ecs-exec-demo-output-xxxxxxxxxxECS 태스크 역할 및 ECS 태스크 실행 역할을 정의하기 위한 사전 요구 사항으로 IAM 정책을 생성해야 합니다. ecs-tasks-trust-policy.json 파일을 생성하고 다음 콘텐츠를 추가합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ecs-tasks.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}이제 AWS 리소스 생성을 시작할 수 있습니다. 이는 나중에 ECS 태스크를 정의하고 궁극적으로 시작하기 위한 사전 요구 사항입니다. 이러한 리소스는 다음과 같습니다.
- ECS Exec 데이터 채널을 암호화하기 위한 KMS 키
- ECS 클러스터
- CloudWatch 로그 그룹
- 이 로그 그룹에는 2개의 스트림이 포함되어 있습니다. 하나는 컨테이너
stdout용이고 다른 하나는 새로운 ECS Exec 기능의 로깅 출력용입니다.
- 이 로그 그룹에는 2개의 스트림이 포함되어 있습니다. 하나는 컨테이너
- 새로운 ECS Exec 기능의 로깅 출력을 위한 S3 버킷(선택적 접두부(prefix) 포함)
- 포트 80의 트래픽이
nginx컨테이너에 도달하도록 허용하는 데 사용할 보안 그룹 - ECS 태스크 역할과 ECS 태스크 실행 역할을 정의하는 데 사용할 두 개의 IAM 역할
이는 위에서 언급한 리소스를 동일한 순서로 생성하는 AWS CLI 명령입니다. ecs create-cluster 명령의 새로운 --configuration executeCommandConfiguration 옵션에 세심한 주의를 기울이십시오.
KMS_KEY=$(aws kms create-key --region $AWS_REGION)
KMS_KEY_ARN=$(echo $KMS_KEY | jq --raw-output .KeyMetadata.Arn)
aws kms create-alias --alias-name alias/ecs-exec-demo-kms-key --target-key-id $KMS_KEY_ARN --region $AWS_REGION
echo "The KMS Key ARN is: "$KMS_KEY_ARN
aws ecs create-cluster \
--cluster-name ecs-exec-demo-cluster \
--region $AWS_REGION \
--configuration executeCommandConfiguration="{logging=OVERRIDE,\
kmsKeyId=$KMS_KEY_ARN,\
logConfiguration={cloudWatchLogGroupName="/aws/ecs/ecs-exec-demo",\
s3BucketName=$ECS_EXEC_BUCKET_NAME,\
s3KeyPrefix=exec-output}}"
aws logs create-log-group --log-group-name /aws/ecs/ecs-exec-demo --region $AWS_REGION
aws s3api create-bucket --bucket $ECS_EXEC_BUCKET_NAME --region $AWS_REGION --create-bucket-configuration LocationConstraint=$AWS_REGION
ECS_EXEC_DEMO_SG=$(aws ec2 create-security-group --group-name ecs-exec-demo-SG --description "ECS exec demo SG" --vpc-id $VPC_ID --region $AWS_REGION)
ECS_EXEC_DEMO_SG_ID=$(echo $ECS_EXEC_DEMO_SG | jq --raw-output .GroupId)
aws ec2 authorize-security-group-ingress --group-id $ECS_EXEC_DEMO_SG_ID --protocol tcp --port 80 --cidr 0.0.0.0/0 --region $AWS_REGION
aws iam create-role --role-name ecs-exec-demo-task-execution-role --assume-role-policy-document file://ecs-tasks-trust-policy.json --region $AWS_REGION
aws iam create-role --role-name ecs-exec-demo-task-role --assume-role-policy-document file://ecs-tasks-trust-policy.json --region $AWS_REGION두 IAM 역할에는 아직 할당된 정책이 없습니다. 우리가 할 일은 다음과 같습니다.
- ECS 태스크 실행 역할의 경우 기존 스탠더드 AWS 관리형 정책(
AmazonECSTaskExecutionRolePolicy)을 연결하기만 하면 됩니다. - ECS 태스크 역할의 경우 컨테이너가 SSM을 통해 보안 채널 세션을 열고 ECS Exec 출력을 CloudWatch 및 S3 모두(LogStream 및 위에서 생성한 버킷)에 로깅할 수 있도록 허용하는 정책을 만들어야 합니다.
ecs-saexec-demo-task-role-policy.json 파일을 생성하고 다음 콘텐츠를 추가합니다. 다음 사항을 수정하십시오.
<AWS_REGION><ACCOUNT_ID><ECS_EXEC_BUCKET_NAME>(해당 값은ECS_EXEC_BUCKET_NAME변수에 있음)- 위에서 생성된
<KMS_KEY_ARN>(해당 값은KMS_KEY_ARN변수에 있음)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:DescribeLogStreams",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:<AWS_REGION>:<ACCOUNT_ID>:log-group:/aws/ecs/ecs-exec-demo:*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::<ECS_EXEC_BUCKET_NAME>/*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetEncryptionConfiguration"
],
"Resource": "arn:aws:s3:::<ECS_EXEC_BUCKET_NAME>"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "<KMS_KEY_ARN>"
}
]
}이러한 IAM 권한은 ECS 태스크 실행 역할 수준이 아닌 ECS 태스크 역할 수준에서 설정해야 합니다. SSM 코어 에이전트가 동일한 컨테이너에서 애플리케이션과 함께 실행되기 때문입니다. 다른 AWS 서비스에 대해 이러한 작업을 수행할 수 있도록 IAM 권한을 부여 받아야 하는 것은 컨테이너 자체입니다.
또한 위의 IAM 정책은 실제 애플리케이션이 작동하는 데 필요한 다른 IAM 정책과 함께 존재해야 한다는 점을 기억해야 합니다. 예를 들어 애플리케이션이 Amazon DynamoDB에서 데이터를 읽는 컨테이너를 태스크에서 실행 중인 경우, ECS 태스크 역할에는 DynamoDB 테이블 읽기를 허용하는 IAM 정책과 ECS Exec가 제대로 작동하도록 허용하는 IAM 정책이 있어야 합니다.
이제 AWS CLI 명령을 실행하여 정책을 IAM 역할에 바인딩할 수 있습니다.
aws iam attach-role-policy \
--role-name ecs-exec-demo-task-execution-role \
--policy-arn "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
aws iam put-role-policy \
--role-name ecs-exec-demo-task-role \
--policy-name ecs-exec-demo-task-role-policy \
--policy-document file://ecs-exec-demo-task-role-policy.jsonECS 태스크 정의를 등록할 준비가 되었습니다. 다음 콘텐츠로 ecs-exec-demo.json 파일을 생성합니다. 다음 사항을 수정합니다.
<ACCOUNT_ID><AWS_REGION>
{"family": "ecs-exec-demo",
"networkMode": "awsvpc",
"executionRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecs-exec-demo-task-execution-role",
"taskRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecs-exec-demo-task-role",
"containerDefinitions": [
{"name": "nginx",
"image": "nginx",
"linuxParameters": {
"initProcessEnabled": true
},
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/aws/ecs/ecs-exec-demo",
"awslogs-region": "<AWS_REGION>",
"awslogs-stream-prefix": "container-stdout"
}
}
}
],
"requiresCompatibilities": [
"FARGATE"
],
"cpu": "256",
"memory": "512"
}태스크 정의에는 새로운 ECS Exec 기능에 대한 참조 또는 구성 요구 사항이 포함되어 있지 않으므로 패치를 적용할 필요 없이 기존 정의를 계속 사용할 수 있습니다. SSM 에이전트 하위 프로세스가 분리되지 않도록
initProcessEnabled파라미터를true로 설정하는 것이 좋습니다. 그러나 이는 필수 사항이 아닙니다.
다음 명령은 위 파일에서 생성한 태스크 정의를 등록합니다.
aws ecs register-task-definition \
--cli-input-json file://ecs-exec-demo.json \
--region $AWS_REGION이제 Fargate 태스크를 시작해 보겠습니다! 이전 명령에서 위에서 설정한 환경 변수 중 일부를 사용할 것입니다. 제대로 입력되어 있는지 확인합니다. 또한 run-task 명령에서 --enable-execute-command 옵션을 통해 새 기능에 명시적으로 옵트인해야 합니다. 이렇게 하면 ECS 및 Fargate 에이전트가 SSM 바이너리를 바인딩하여 탑재한 다음 애플리케이션과 함께 시작하도록 지시합니다. 마찬가지로 create-service 명령과 함께 동일한 --enable-execute-command 플래그를 사용하여 ECS 서비스 수준에서 이 기능을 활성화할 수 있습니다. 태스크가 배포되거나 --enable-execute-command 플래그 없이 서비스가 생성된 경우 컨테이너에서 exec 명령을 시작할 수 있으려면 이 옵트인 설정을 사용하여 태스크를 다시 배포하거나(run-task 사용) 서비스를 업데이트해야 합니다(update-service 사용).
aws ecs run-task \
--cluster ecs-exec-demo-cluster \
--task-definition ecs-exec-demo \
--network-configuration awsvpcConfiguration="{subnets=[$PUBLIC_SUBNET1, $PUBLIC_SUBNET2],securityGroups=[$ECS_EXEC_DEMO_SG_ID],assignPublicIp=ENABLED}" \
--enable-execute-command \
--launch-type FARGATE \
--tags key=environment,value=production \
--platform-version '1.4.0' \
--region $AWS_REGIONrun-task 명령은 전체 태스크 세부 정보를 반환해야 하며 여기에서 태스크 ID를 찾을 수 있습니다. taskArn 출력을 검색합니다. 태스크 ID는 ARN의 마지막 부분을 나타냅니다.
"taskArn": "arn:aws:ecs:AWS_REGION:ACCOUNT_ID:task/ecs-exec-demo-cluster/*ef6260ed8aab49cf926667ab0c52c313*"또한 태스크에 특정 키 페어로 태그를 지정했습니다. 이 예에서는 이를 활용하지 않지만 원하는 경우 태그를 사용하여 IAM 제어 조건을 생성할 수 있습니다.
태스크가 성공적으로 RUNNING으로 전환될 때까지 태스크 ID를 사용하여 태스크를 쿼리합니다(run-task 명령에서 수집한 태스크 ID를 사용해야 함).
aws ecs describe-tasks \
--cluster ecs-exec-demo-cluster \
--region $AWS_REGION \
--tasks ef6260ed8aab49cf926667ab0c52c313태스크 상태의 "ExecuteCommandAgent"가 RUNNING이고 "enableExecuteCommand"가 true로 설정되어 있는지 확인합니다.
이 기능이 활성화되고 적절한 권한이 적용되면 컨테이너 중 하나에서 exec 명령을 시작할 준비가 된 것입니다.
이 연습에서는 지금까지 사용한
관리정책과 함께 IAM 역할을 계속 사용할 것입니다. 그러나 컨테이너에서 “exec-ing” 명령 시작은 새로운ecs:ExecuteCommandIAM 작업에 의해 제어되며 해당 작업은 태그의조건과 호환됩니다.
셸을 호출하는 명령을 실행해 보겠습니다.
aws ecs execute-command \
--region $AWS_REGION \
--cluster ecs-exec-demo-cluster \
--task ef6260ed8aab49cf926667ab0c52c313 \
--container nginx \
--command "/bin/bash" \
--interactive
Session Manager 플러그 인이 성공적으로 설치되었습니다. AWS CLI를 사용하여 세션을 시작합니다.
세션 ID로 세션 시작: ecs-execute-command-0122b68a67f39258e
이 세션은 AWS KMS를 사용하여 암호화됩니다.
root@ip-172-31-32-237:/# hostname
ip-172-31-32-237.ap-southeast-1.compute.internal
root@ip-172-31-32-237:/#
root@ip-172-31-32-237:/# ls
bin dev docker-entrypoint.sh home lib64 media opt root sbin sys usr
boot docker-entrypoint.d etc lib managed-agents mnt proc run srv tmp var
root@ip-172-31-32-237:/#
root@ip-172-31-32-237:/# echo "이 페이지는 ECS Exec를 사용하여 생성되었습니다." > /usr/share/nginx/html/index.html
root@ip-172-31-32-237:/#
root@ip-172-31-32-237:/# exit
exit
세션 ID로 세션 종료: ecs-execute-command-0122b68a67f39258e.위 명령에는
--container파라미터가 포함되어 있습니다. 단일 컨테이너가 있는 태스크의 경우 이 플래그는 선택 사항입니다. 그러나 컨테이너가 여러 개인 태스크의 경우 이 플래그는 필수 사항입니다.
위에서 볼 수 있듯이 Fargate에서 실행되는 컨테이너에 대한 셸을 획득하고 상호 작용할 수 있었습니다. hostname 및 ls와 같은 몇 가지 명령을 호출하는 것 외에도 “이 페이지는 ECS Exec를 사용하여 생성되었습니다.” 문자열로 nginx 홈페이지(index.html 파일)를 다시 작성했습니다. 이 태스크는 공인 IP 주소로 구성되었으며 curl을 사용하면 페이지가 실제로 변경되었음을 알 수 있습니다.
$ curl http://13.212.126.134/
이 페이지는 ECS Exec를 사용하여 생성되었습니다.
$다시 말해, 컨테이너 내부에 설치되어 사용 가능한 도구와 유틸리티만 ECS Exec와 함께 사용할 수 있습니다.
다음 예에서 볼 수 있듯이 셸을 획득하는 대신 대화형 모드에서 단일 명령을 호출할 수도 있습니다. 이 경우 ls를 사용하여 컨테이너 루트 디렉터리의 콘텐츠를 나열하는 것입니다.
aws ecs execute-command \
--region $AWS_REGION \
--cluster ecs-exec-demo-cluster \
--task 1234567890123456789 \
--container nginx \
--command "ls" \
--interactive
Session Manager 플러그 인이 성공적으로 설치되었습니다. AWS CLI를 사용하여 세션을 시작합니다.
세션 ID로 세션 시작: ecs-execute-command-00167f6ecbc18ee7e
bin docker-entrypoint.d home managed-agents opt run sys var
boot docker-entrypoint.sh lib media proc sbin tmp
dev etc lib64 mnt root srv usr
세션 ID로 세션 종료: ecs-execute-command-00167f6ecbc18ee7e.ls 명령은 AWS CloudTrail에 로깅된 ExecuteCommand API 호출의 페이로드의 일부입니다. CloudTrail 로그 콘텐츠의 이 추출에 있는 세션 ID 및 명령을 기록해 둡니다. 세션 ID와 다양한 타임스탬프는 이벤트의 상관 관계를 파악하는 데 도움이 됩니다.
"requestParameters": {
"cluster": "ecs-exec-demo-cluster",
"container": "nginx",
"command": "ls",
"interactive": true,
"task": "3b3b695a6d104ef5ae31fdb596f27429"
},
"responseElements": {
"clusterArn": "arn:aws:ecs:ap-southeast-1:123456789012:cluster/ecs-exec-demo-cluster",
"containerArn": "arn:aws:ecs:ap-southeast-1:123456789012:container/6c5790cb-7b68-4bab-9b12-aa6e880e00fa",
"containerName": "nginx",
"interactive": true,
"session": {
"sessionId": "ecs-execute-command-00167f6ecbc18ee7e",
"streamUrl": "wss://ssmmessages.ap-southeast-1.amazonaws.com/v1/data-channel/ecs-execute-command-00167f6ecbc18ee7e?role=publish_subscribe",
"tokenValue": "HIDDEN_DUE_TO_SECURITY_REASONS"
},
"taskArn": "arn:aws:ecs:ap-southeast-1:123456789012:task/ecs-exec-demo-cluster/3b3b695a6d104ef5ae31fdb596f27429"
},다음은 동일한 ls 명령에 대해 S3 버킷에 로깅되는 출력입니다.
다음은 동일한 ls 명령에 대해 CloudWatch 로그 스트림에 로깅되는 출력입니다.
힌트: S3 및/또는 CloudWatch에 명령 출력을 로깅하는 데 문제가 있는 경우 IAM 정책을 잘못 구성했을 수 있습니다. 일반적으로 이러한 문제를 해결하는 좋은 방법은 컨테이너 내부에서
/var/log/amazon/ssm/amazon-ssm-agent.log파일의 콘텐츠를 조사하는 것입니다.
이것으로 CloudTrail을 사용하여 컨테이너에 액세스한 사용자를 감사하고 각 명령을 출력하여 S3 또는 CloudWatch 로그에 로깅하는 방법 외에도 실행 중인 컨테이너에서 명령을 실행하는 방법을 보여 주는 연습을 마칩니다.
[업데이트] ECS Exec 사용 시 문제가 발생하는 경우 구성이 사전 요구 사항을 충족하는지 확인하는 스크립트를 릴리스했습니다. 스크립트는 여기에서 다운로드할 수 있습니다.
환경 해체
다음 명령을 실행하여 연습 중에 생성한 리소스를 해체합니다. 변수가 제대로 해석되고 올바른 ECS 태스크 ID를 사용하는지 확인합니다.
aws ecs stop-task --cluster ecs-exec-demo-cluster --region $AWS_REGION --task <your task id>
aws ecs delete-cluster --cluster ecs-exec-demo-cluster --region $AWS_REGION
aws logs delete-log-group --log-group-name /aws/ecs/ecs-exec-demo --region $AWS_REGION
# 이 명령을 실행할 때 주의하십시오. 이렇게 하면 이전에 생성한 버킷이 삭제됩니다.
aws s3 rm s3://$ECS_EXEC_BUCKET_NAME --recursive
aws s3api delete-bucket --bucket $ECS_EXEC_BUCKET_NAME
aws iam detach-role-policy --role-name ecs-exec-demo-task-execution-role --policy-arn "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
aws iam delete-role --role-name ecs-exec-demo-task-execution-role
aws iam delete-role-policy --role-name ecs-exec-demo-task-role --policy-name ecs-exec-demo-task-role-policy
aws iam delete-role --role-name ecs-exec-demo-task-role
aws kms schedule-key-deletion --key-id $KMS_KEY_ARN --region $AWS_REGION
aws ec2 delete-security-group --group-id $ECS_EXEC_DEMO_SG_ID --region $AWS_REGION결론
이 게시물에서는 ECS 사용자가 Amazon EC2 또는 AWS Fargate에 배포된 컨테이너와 보다 쉽게 상호 작용하고 디버깅할 수 있는 기능인 ECS Exec의 릴리스에 대해 설명했습니다. 여러분이 직접 사용해 보고 이에 대해 어떻게 생각하는지, 그리고 이를 통해 AWS, 특히 Amazon ECS에서 컨테이너를 더 쉽게 디버깅할 수 있는 방법을 알려 주시기 바랍니다.
AWS 파트너도 이번 발표에 대해 기쁘게 생각하며, 이들 중 일부는 이미 이 기능에 대한 지원을 제품에 통합했습니다. 고객은 개발자 및 운영자가 ECS Exec을 활용할 때 보안 태세에 영향을 미치지 않도록 모니터링, 경고 및 보고 기능이 필요할 수 있습니다. 자세한 내용은 AWS 파트너의 다음 게시물을 참조하십시오.
- Aqua: Amazon ECS Exec 문제 해결 기능 지원
- Datadog: ECS Exec 요청 모니터링 및 비정상적인 사용자 활동 감지
- SysDig: Amazon ECS Exec 및 Sysdig을 사용하여 컨테이너 명령 실행
- ThreatStack: AWS Fargate 쉬운 디버깅 하기
- TrendMicro: Cloud One – Conformity 규칙, Amazon ECS Exec 지원
ECS Exec에 대해 계획하고 있는 개선 사항에 대한 최신 정보를 얻으려면 공식 설명서를 자세히 살펴보십시오. 이 기능은 API, SDK, AWS CLI, AWS Copilot CLI 및 AWS CloudFormation을 통해 커머셜, 중국 및 AWS GovCloudCloud를 포함한 모든 공개 리전에서 오늘부터 사용할 수 있습니다.
– Massimo Re Ferre, AWS Principal Technologist
– Saloni Sonpal, AWS Container Product Manager
이 글은 AWS Container Blog의 NEW – Using Amazon ECS Exec to access your containers on AWS Fargate and Amazon EC2의 한국어 번역입니다.