# Amazon ECS의 IAM 역할 모범 사례
Amazon ECS에 필요한 역할은 작업 정의 시작 유형 및 사용하는 기능에 따라 다릅니다. 역할을 공유하는 대신 테이블에 별도의 역할을 생성하는 것이 좋습니다.
| 역할 | 정의 | 필요한 경우 | 추가 정보 |
| --- | --- | --- | --- |
| 태스크 실행 역할 | 이 역할을 통해 Amazon ECS가 사용자를 대신해 다른 AWS 서비스를 사용할 수 있습니다. | 작업은 AWS Fargate 또는 외부 인스턴스에 호스팅됩니다. 그리고, [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/security-iam-roles.html) 작업은 AWS Fargate 또는 Amazon EC2 인스턴스에 호스팅됩니다. 그리고, [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/security-iam-roles.html) | [Amazon ECS 태스크 실행 IAM 역할](task_execution_IAM_role.md) |
| 태스크 역할 | 이 역할을 통해 컨테이너의 애플리케이션 코드가 다른 AWS 서비스를 사용할 수 있습니다. | 애플리케이션은 Amazon S3와 같은 다른 AWS 서비스에 액세스합니다. | [Amazon ECS 작업 IAM 역할](task-iam-roles.md) |
| 컨테이너 인스턴스 역할 | 이 역할을 통해 EC2 인스턴스 또는 외부 인스턴스를 클러스터에 등록할 수 있습니다. | 작업은 Amazon EC2 인스턴스 또는 외부 인스턴스에 호스팅됩니다. | [Amazon ECS 컨테이너 인스턴스 IAM 역할](instance_IAM_role.md) |
| Amazon ECS Anywhere 역할 | 이 역할을 통해 외부 인스턴스에서 AWS API에 액세스할 수 있습니다. | 작업은 외부 인스턴스에 호스팅됩니다. | [Amazon ECS Anywhere IAM 역할](iam-role-ecsanywhere.md) |
| Amazon ECS CodeDeploy 역할 | 이 역할을 통해 CodeDeploy에서 서비스를 업데이트할 수 있습니다. | CodeDeploy 블루/그린 배포 유형을 사용하여 서비스를 배포합니다. | [Amazon ECS CodeDeploy IAM 역할](codedeploy_IAM_role.md) |
| Amazon ECS EventBridge 역할 | 이 역할을 통해 EventBridge에서 서비스를 업데이트할 수 있습니다. | EventBridge 규칙 및 대상을 사용하여 작업을 예약합니다. | [Amazon ECS EventBridge IAM 역할](CWE_IAM_role.md) |
| Amazon ECS 인프라 역할 | 이 역할을 통해 Amazon ECS에서 클러스터의 인프라 리소스를 관리할 수 있습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/security-iam-roles.html) | [Amazon ECS 인프라 IAM 역할](infrastructure_IAM_role.md) |
## 태스크 역할
태스크 역할을 할당하는 것을 권장합니다. 작업의 역할과 작업이 실행되는 Amazon EC2 인스턴스의 역할은 구분할 수 있습니다. 각 작업에 역할을 할당하면 최소 권한 액세스 원칙에 부합하며, 작업과 리소스를 보다 정밀하게 제어할 수 있습니다.
작업 정의에 작업 역할을 추가하면 Amazon ECS 컨테이너 에이전트는 작업에 대한 고유한 보안 인증 ID(예: `12345678-90ab-cdef-1234-567890abcdef`)를 사용하여 토큰을 자동으로 생성합니다. 그러면 이 토큰과 역할 보안 인증이 에이전트의 내부 캐시에 추가됩니다. 에이전트는 컨테이너의 환경 변수 `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`를 보안 인증 ID의 URI(예: `/v2/credentials/12345678-90ab-cdef-1234-567890abcdef`)로 채웁니다.
Amazon ECS 컨테이너 에이전트의 IP 주소에 환경 변수를 추가하고 결과 문자열에서 `curl` 명령을 실행하여 컨테이너 내에서 임시 역할 보안 인증을 수동으로 검색할 수 있습니다.
```
curl 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
```
예상 출력은 다음과 같습니다.
```
{
"RoleArn": "arn:aws:iam::123456789012:role/SSMTaskRole-SSMFargateTaskIAMRole-DASWWSF2WGD6",
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"Token": "IQoJb3JpZ2luX2VjEEM/Example==",
"Expiration": "2021-01-16T00:51:53Z"
}
```
최신 버전의 AWS SDK는 AWS API 호출 시 `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` 환경 변수에서 이러한 보안 인증을 자동으로 가져옵니다. 자격 증명을 갱신하는 방법에 대한 자세한 내용은 RePost의 [AWS 자격 증명 갱신](https://repost.aws/questions/QUgcf1EIOPS7GZNboeAiyO9Q/renewing-aws-credentials)을 참조하세요.
출력에는 애플리케이션이 AWS 리소스에 액세스하는 데 사용하는 비밀 액세스 키 ID와 보안 암호 키로 구성된 액세스 키 쌍이 포함됩니다. AWS에서 보안 인증이 유효한지 확인하는 데 사용하는 토큰도 포함됩니다. 기본적으로 작업 역할을 사용하여 작업에 할당된 보안 인증은 6시간 동안 유효합니다. 그런 다음 Amazon ECS 컨테이너 에이전트에 의해 자동으로 교체됩니다.
## 태스크 실행 역할
작업 실행 역할은 Amazon ECS 컨테이너 에이전트에 사용자를 대신하여 특정 AWS API 호출을 수행할 권한을 부여하는 데 사용됩니다. 예를 들어, AWS Fargate를 사용하는 경우 Fargate에는 Amazon ECR에서 이미지를 풀하고 CloudWatch Logs에 로그를 기록하도록 허용하는 IAM 역할이 필요합니다. 작업에서 이미지 풀 보안 암호와 같이 AWS Secrets Manager에 저장된 보안 암호를 참조하는 경우에도 IAM 역할이 필요합니다.
**참고**
인증된 사용자로 이미지를 풀하는 경우 [Docker Hub의 풀 속도 제한](https://www.docker.com/pricing/resource-consumption-updates) 변경으로 인한 영향을 덜 받을 수 있습니다. 자세한 내용은 [Private registry authentication for container instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth-container-instances.html)를 참조하세요.
Amazon ECR 및 Amazon ECR Public을 사용하면 Docker에서 적용한 제한을 피할 수 있습니다. Amazon ECR에서 이미지를 풀하면 네트워크 풀 시간을 단축하는 데에도 도움이 되고 트래픽이 VPC를 나갈 때 데이터 전송 변경 사항이 줄어듭니다.
**중요**
Fargate를 사용할 때는 `repositoryCredentials`를 사용하여 프라이빗 이미지 레지스트리에 인증해야 합니다. Fargate에 호스팅된 작업의 경우 Amazon ECS 컨테이너 에이전트 환경 변수 `ECS_ENGINE_AUTH_TYPE` 또는 `ECS_ENGINE_AUTH_DATA`를 설정하거나 `ecs.config` 파일을 수정할 수 없습니다. 자세한 내용은 [Private registry authentication for tasks](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html)를 참조하세요.
## 컨테이너 인스턴스 역할
`AmazonEC2ContainerServiceforEC2Role` 관리형 IAM 정책에 다음 권한이 포함되어야 합니다. 최소 권한 부여에 대한 표준 보안 권고 사항에 따라 `AmazonEC2ContainerServiceforEC2Role` 관리형 정책을 가이드로 사용할 수 있습니다. 사용 사례에 대해 관리형 정책에서 부여한 권한이 필요하지 않은 경우 사용자 지정 정책을 생성하고 필요한 권한만 추가합니다.
+ `ec2:DescribeTags` – (선택 사항) 위탁자가 Amazon EC2 인스턴스와 연결된 태그를 설명할 수 있습니다. 이 권한은 Amazon ECS 컨테이너 에이전트가 리소스 태그 전파를 지원하는 데 사용합니다. 자세한 내용은 [리소스 태그 지정 방법](ecs-using-tags.md#tag-resources) 섹션을 참조하세요.
+ `ecs:CreateCluster` – (선택 사항) 보안 주체가 Amazon ECS 클러스터를 생성할 수 있습니다. 이 권한은 `default` 클러스터가 이미 존재하지 않는 경우 이를 생성하기 위해 Amazon ECS 컨테이너 에이전트에서 사용합니다.
+ `ecs:DeregisterContainerInstance` – (선택 사항) 보안 주체가 클러스터에서 Amazon ECS 컨테이너 인스턴스의 등록을 취소할 수 있습니다. Amazon ECS 컨테이너 에이전트는 이 API 작업을 직접 호출하지 않지만 이전 버전과의 호환성을 보장하기 위해 이 권한을 유지합니다.
+ `ecs:DiscoverPollEndpoint` – (필수) 이 작업은 Amazon ECS 컨테이너 에이전트가 업데이트를 폴링하는 데 사용하는 엔드포인트를 반환합니다.
+ `ecs:Poll` – (필수) Amazon ECS 컨테이너 에이전트가 Amazon ECS 컨트롤 플레인과 통신하여 태스크 상태 변경 사항을 보고할 수 있습니다.
+ `ecs:RegisterContainerInstance` – (필수) 보안 주체가 클러스터에 컨테이너 인스턴스를 등록할 수 있습니다. 이 권한은 Amazon EC2 인스턴스를 클러스터에 등록하고 리소스 태그 전파를 지원하기 위해 Amazon ECS 컨테이너 에이전트에서 사용합니다.
+ `ecs:StartTelemetrySession` – (선택 사항) Amazon ECS 컨테이너 에이전트가 Amazon ECS 컨트롤 플레인과 통신하여 각 컨테이너 및 태스크에 대한 상태 정보 및 지표를 보고할 수 있습니다.
이 권한이 필수는 아니지만 컨테이너 인스턴스 지표를 통해 규모 조정 작업을 시작하고 상태 확인 명령과 관련된 보고서를 수신할 수 있도록 하려면 이 권한을 추가하는 것이 좋습니다.
+ `ecs:TagResource` - (선택 사항) Amazon ECS 컨테이너 에이전트가 클러스터 생성 시 클러스터에 태그를 지정하고, 컨테이너 인스턴스가 클러스터에 등록될 때 인스턴스에 태그를 지정할 수 있습니다.
+ `ecs:UpdateContainerInstancesState` – 보안 주체가 Amazon ECS 컨테이너 인스턴스의 상태를 수정할 수 있습니다. 이 권한은 Amazon ECS 컨테이너 에이전트가 스팟 인스턴스 드레이닝에 사용합니다.
+ `ecs:Submit*` – (필수) 여기에는 `SubmitAttachmentStateChanges`, `SubmitContainerStateChange` 및 `SubmitTaskStateChange` API 작업이 포함됩니다. 각 리소스의 상태 변경 사항을 Amazon ECS 제어 영역에 보고하기 위해 Amazon ECS 컨테이너 에이전트에서 사용합니다. `SubmitContainerStateChange` 권한은 Amazon ECS 컨테이너 에이전트에서 더 이상 사용하지 않지만 이전 버전과의 호환성을 보장하기 위해 유지됩니다.
+ `ecr:GetAuthorizationToken` – (선택 사항) 보안 주체가 권한 부여 토큰을 검색할 수 있습니다. 권한 부여 토큰은 IAM 인증 자격 증명을 나타내며 IAM 보안 주체가 액세스할 수 있는 모든 Amazon ECR 레지스트리에 액세스하는 데 사용할 수 있습니다. 수신된 권한 부여 토큰은 12시간 동안 유효합니다.
+ `ecr:BatchCheckLayerAvailability` – (선택 사항) 컨테이너 이미지가 Amazon ECR 프라이빗 리포지토리에 푸시될 때 이미지가 이미 푸시되었는지 확인하기 위해 각 이미지 계층을 검사합니다. 이미지가 푸시되었다면 이미지 계층을 건너뜁니다.
+ `ecr:GetDownloadUrlForLayer` – (선택 사항) Amazon ECR 프라이빗 리포지토리에서 컨테이너 이미지를 가져올 때 아직 캐시되지 않은 각 이미지 레이어에 대해 이 API를 한 번 호출합니다.
+ `ecr:BatchGetImage` – (선택 사항) Amazon ECR 프라이빗 리포지토리에서 컨테이너 이미지를 가져올 때 이미지 매니페스트를 검색하기 위해 이 API를 한 번 호출합니다.
+ `logs:CreateLogStream` – (선택 사항) 보안 주체가 지정된 로그 그룹에 대한 CloudWatch Logs 로그 스트림을 생성할 수 있습니다.
+ `logs:PutLogEvents` – (선택 사항) 보안 주체가 로그 이벤트의 배치를 지정된 로그 스트림에 업로드할 수 있습니다.
## 서비스 연결 역할
Amazon ECS에 대한 서비스 연결 역할을 사용하면 사용자를 대신하여 다른 서비스 API를 호출할 수 있는 권한을 Amazon ECS 서비스에 부여할 수 있습니다. Amazon ECS에는 네트워크 인터페이스를 생성 및 삭제하고, 대상을 대상 그룹에 등록 및 등록 취소할 수 있는 권한이 필요합니다. 또한 조정 정책을 생성 및 삭제하는 데 필요한 권한도 필요합니다. 이러한 권한은 서비스 연결 역할을 통해 부여합니다. 이 역할은 서비스를 처음 사용할 때 자동으로 생성됩니다.
**참고**
서비스 연결 역할을 실수로 삭제한 경우 다시 생성할 수 있습니다. 자세한 내용은 [Create the service-linked role](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using-service-linked-roles.html#create-service-linked-role)을 참조하세요.
## 역할 권장 사항
작업 IAM 역할 및 정책을 설정할 때 다음을 수행하는 것이 좋습니다.
### Amazon EC2 메타데이터에 대한 액세스 차단
Amazon EC2 인스턴스에서 작업을 실행할 때 Amazon EC2 메타데이터에 대한 액세스를 차단하여 컨테이너가 해당 인스턴스에 할당된 역할을 상속하지 못하도록 하는 것이 좋습니다. 애플리케이션에서 AWS API 작업을 호출해야 하는 경우 대신 작업에 대한 IAM 역할을 사용하세요.
**브리지** 모드로 실행 중인 작업이 Amazon EC2 메타데이터에 액세스하지 못하도록 하려면 다음 명령을 실행하거나 인스턴스의 사용자 데이터를 업데이트하세요. 인스턴스의 사용자 데이터 업데이트에 대한 자세한 지침은 이 [AWS 지원 문서](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-container-ec2-metadata/)를 참조하세요. 작업 정의 브리지 모드에 대한 자세한 내용은 [task definition network mode](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#network_mode)를 참조하세요.
```
sudo yum install -y iptables-services; sudo iptables --insert FORWARD 1 --in-interface docker+ --destination 169.254.169.254/32 --jump DROP
```
이 변경 사항이 재부팅 후에도 유지되도록 하려면 Amazon Machine Image(AMI)에만 적용되는 다음 명령을 실행하세요.
+ Amazon Linux 2
```
sudo iptables-save | sudo tee /etc/sysconfig/iptables && sudo systemctl enable --now iptables
```
+ Amazon Linux
```
sudo service iptables save
```
`awsvpc` 네트워크 모드를 사용하는 작업의 경우 `/etc/ecs/ecs.config` 파일에서 환경 변수 `ECS_AWSVPC_BLOCK_IMDS`를 `true`로 설정하세요.
`host` 네트워크 내에서 실행 중인 컨테이너가 Amazon EC2 메타데이터에 액세스하지 못하도록 하려면 `ecs-agent config` 파일에서 `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST` 변수를 `false`로 설정해야 합니다.
### `awsvpc` 네트워크 모드 사용
네트워크 `awsvpc` 네트워크 모드를 사용하면 다른 작업 간이나 Amazon VPC 내에서 실행되는 다른 서비스와 다른 작업 간의 트래픽 흐름을 제한할 수 있습니다. 이 경우 보안 계층이 또 하나 추가됩니다. `awsvpc` 네트워크 모드에서는 Amazon EC2에서 실행되는 작업에 대한 작업 수준 네트워크 격리를 제공합니다. 이는 AWS Fargate에서 기본 모드이며, 작업에 보안 그룹을 할당하는 데 사용할 수 있는 유일한 네트워크 모드입니다.
### 마지막으로 액세스한 정보를 사용하여 역할 세분화
한 번도 사용하지 않았거나 한동안 사용하지 않은 작업은 제거하는 것이 좋습니다. 이렇게 하면 원치 않는 액세스를 방지할 수 있습니다. 이렇게 하려면 IAM에서 제공되는 마지막으로 액세스한 정보를 검토한 다음에 사용한 적이 없거나 최근에 사용하지 않은 작업을 제거합니다. 다음 단계에 따라 이 작업을 수행할 수 있습니다.
다음 명령을 실행하여 참조된 정책에 대한 마지막 액세스 정보를 보여주는 보고서를 생성합니다.
```
aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/ExamplePolicy1
```
출력에 있는 `JobId`를 사용하여 다음 명령을 실행합니다. 이를 수행한 후 보고서의 결과를 볼 수 있습니다.
```
aws iam get-service-last-accessed-details --job-id 98a765b4-3cde-2101-2345-example678f9
```
자세한 내용은 [마지막으로 액세스한 정보를 사용하여 AWS에서의 권한 세분화](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_last-accessed.html)를 참조하세요.
### AWS CloudTrail을 모니터링하여 의심스러운 활동 식별
AWS CloudTrail을 모니터링하여 의심스러운 활동을 찾아낼 수 있습니다. 대부분의 AWS API 호출은 AWS CloudTrail에 이벤트로 기록됩니다. 이러한 호출을 AWS CloudTrail Insights에서 분석하며 `write` API 호출과 관련된 의심스러운 동작이 있으면 알림을 받게 됩니다. 호출 볼륨의 급증도 여기에 포함될 수 있습니다. 이러한 알림에는 비정상적인 활동이 발생한 시간, API에 기여한 상위 자격 증명 ARN과 같은 정보가 포함됩니다.
이벤트의 `userIdentity` 속성을 보면 AWS CloudTrail에서 IAM 역할의 작업으로 수행된 작업을 식별할 수 있습니다. 다음 예제에서 `arn`에는 수임된 역할의 이름 `s3-write-go-bucket-role`과 작업 이름 `7e9894e088ad416eb5cab92afExample` 순으로 포함됩니다.
```
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA36C6WWEJ2YEXAMPLE:7e9894e088ad416eb5cab92afExample",
"arn": "arn:aws:sts::123456789012:assumed-role/s3-write-go-bucket-role/7e9894e088ad416eb5cab92afExample",
...
}
```
**참고**
역할을 수임하는 작업이 Amazon EC2 컨테이너 인스턴스에서 실행되는 경우 Amazon ECS 컨테이너 에이전트는 `/var/log/ecs/audit.log.YYYY-MM-DD-HH` 형식의 주소에 있는 에이전트의 감사 로그에 요청을 기록합니다. 자세한 내용은 [Task IAM Roles Log](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logs.html#task_iam_roles-logs) 및 [Logging Insights Events for Trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-insights-events-with-cloudtrail.html)를 참조하세요.