[AWS] ECS ASG 구성 시 ServiceLinkedRole 권한 이슈가 발생하는 경우?

ECS AutoScaling을 설정하기 위해 ECS Service를 업데이트 하는 과정 중에 iam:CreateServiceLinkedRole이라는 권한 이슈가 발생하였다. ServiceLinkedRole은 AWS 서비스가 역할을 생성 및 관리하는 것으로만 알고 있었기에 이번 포스팅을 통해 이슈를 이해하고 해결해보자.

01. ECS Service 업데이트 콘솔

User is missing the following permissions: iam:CreateServiceLinedRole

현재 사내 API 서비스는 ECS Fargate를 기반으로 운영되고 있으며, 총 3개의 ECS 클러스터(A, B, C)에서 서비스가 실행되고 있다. 이 중 B, C 클러스터에는 Auto Scaling(AS) 정책이 지정되지 않은 상태이며, 이를 설정하려는 과정에서 IAM 권한 문제(iam:CreateServiceLinkedRole 부족)로 인해 ASG 설정에 실패하는 이슈가 발생하였다. 본 문서는 해당 이슈의 내용을 정리한다.

01-1. ECS Service 조정 정책 확인

조정 정책 유형

대상 추적 옵션

• 이미지와 같이 CPU, Mem 설정 난이도가 상당히 쉽다
• ECS에 의해 어느정도 AG에 대한 최적화를 원할 때 사용한다

단계 조정 옵션

• 단계 조정 옵션은 Cloudwatch와의 연계를 통해 설정이 되는 AG 정책이다
• 세부적인 Scaling 옵션을 설정 할 때 사용이되며, 하한 - 상한에 대한 옵션을 사용자가 지정하고 이에 따른 Scaling 옵션을 지정할 수 있는 장점이 있다

정책 이름

# ECS의 AG Policy 이름
ECSPersonalScaleOutPolicyProd

• ECS Service의 AG에 사용될 정책 이름을 지정하는 옵션이다

Amazon ECS 서비스 경보

• Amazon ECS 지표를 사용하여 새 경보를 생성: 기존 생성되어 있는 알람이 아닌 신규 알람 + AG 정책 생성
• 기존 경보 사용: 기존에 생성되어 있는 경보 사용

경보 이름

# Cloudwatch의 Alarm 이름
ECSPersonalScaleOutAlarmProd

• Cloudwatch의 Alarm 이름으로 지정될 경보 이름을 지칭한다

Amazon ECS 서비스 지표

• 어떤 지표를 기반으로 AutoScaling 이벤트를 동작하게 할 것인지 지정하는 옵션이다
• 기본적으로 CPUUtilization, MemoryUtilization 2가지 옵션이 존재한다

통계

• ECS Service Scaling 이벤트 발생 시 어떤 지표를 기준으로 통계를 할지 결정하는 옵션이다
• 기본적으로 평균, 최소, 최대, 합계, 샘플 개수 옵션이 존재한다

기간

기간 1분

• 기간은 하나의 데이터 포인트를 수집하는 간격이다
• 즉, AWS ECS가 사용하는 CPU 사용률(CPUUtilization)을 1분마다 측정한다는 의미

지표 비교 임계값

• 이벤트가 발생하는 메트릭 수치를 입력하는 란이다
• ex) CPU > 30 이상인 경우 → 지표 비교 임계값을 30로 지정해주면 된다

경보 시작을 위한 평가 기간

경보 시작을 위한 평가기간 1

• 위에서 기간은 1분으로 설정되어 있으며, 이 말은 1분간 데이터 포인트를 수집하고 평가하겠다는 의미다
• 경보 시작을 위한 평가 기간은, 기간 내에 몇번 조건에 만족하였는지 평가하는 횟수를 의미한다

크기 조정 작업

위 내용은 단순한 예시입니다. 실제 Scaling 옵션은 프로젝트 상황에 맞게 지정해야 합니다.

• 하한 30 - 상한 40 : CPUUtilization이 30 ~ 40 사이를 유지하는 경우 2개의 Task 증설
• 하한 40 - 상한 50 : CPUUtilization이 40 ~ 50 사이를 유지하는 경우 2개의 Task 증설
• 하한 50 - +Infinity : CPUUtilization이 50 ~ 유지하는 경우 4개의 Task 증설

휴지기간

휴지기간 : 300

• AWS Auto Scaling이 한 번의 스케일링 작업을 실행 한 뒤, 다음 스케일링 작업이 수행되기까지의 대기시간을 의미한다
• 300초로 잡아 두었기 때문에, Scaling 이벤트가 발생하고 난 다음에는 5분간 Auto Scaling이 발생하지 않는다

01-2. iam:CreateServiceLinkedRole 권한 이슈 해소

PassRole은 사용자가 직접 만든 역할을 특정 AWS 서비스가 사용하도록 넘겨주는 권한이지만, 잘못된 권한 부여, 신뢰 정책 설정 오류로 인한 삭제 등의 위험이 있다. 반면, Service-Linked Role은 특정 AWS 서비스가 필요로 하는 역할을 자동으로 생성 및 관리하며, 해당 AWS 서비스만 사용하도록 제한된 전용 역할이다. 이를 통해 보안성을 높이고 사용자의 개입 없이 AWS가 직접 역할과 권한을 관리할 수 있다.

헷갈리는 부분이 많으니, 아래 좀 더 정리를 해보자.

• PassRole(사용자가 생성한 역할을 AWS에게 넘긴다)
  • 사용자가 직접 생성한 역할을 AWS 서비스가 사용하도록 넘겨주는 것
  • 즉, 사용자가 역할을 만들고 AWS 서비스가 그 역할을 가정(Assume)해야 한다
• Service-Linked Role(AWS 특정 서비스가 역할을 생성 한다)
  • 특정 AWS 서비스가 직접 역할을 생성하고 관리하는 전용 역할
  • 역할(Role)의 신뢰 관계(trust relationship)가 해당 서비스로 고정 됨
  • 사용자가 임의로 변경할 수 없음

Cross-Account Role Assume

A account(5542xxxx) -> Role A 역할 전환(Role Assume) -> B account(712xxxx) role search-test-role로 접근

https://medium.com/@mohasina.clt/switchrolemastery-your-step-by-step-guide-to-aws-cross-account-access-d3bef687589e

현재 사내 서비스는 위와 같이 Role을 Assume하는 Cross-Account Role Assume 방식으로 콘솔을 컨트롤 하고 있다. 그렇기 때문에 iam:CreateServiceLinkedRole의 권한을 추가해야 할 주체는 사용자가 Assume 받은 특정 Role에 iam:CreateServiceLinkedRole을 추가해야 한다고 판단하고 있다.

search-test-role의 커스텀 Policy 내용

...중략
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:AWSServiceName": [
                        "cloud9.amazonaws.com",
                        "ecs.amazonaws.com"
                    ]
                }
            }
        }
    ]
}
...중략

기존 Assume 받은 Role의 정책(Policy)을 확인한 결과, 모든 리소스(*)에 대해 특정 서비스(ecs, cloud9)가 iam:CreateServiceLinkedRole을 수행할 권한이 부여된 상태다. 다만, ECS Auto Scaling에 필요한 ecs.application-autoscaling.amazonaws.com 서비스에 대한 권한이 포함되지 않아, ECS의 AG를 구성할 수 없는 것으로 보인다. 따라서 ECS Auto Scaling 서비스도 권한을 부여받을 수 있도록 아래와 같이 정책 수정이 필요하다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:AWSServiceName": [
                        "cloud9.amazonaws.com",
                        "ecs.amazonaws.com",
                        "ecs.application-autoscaling.amazonaws.com"
                    ]
                }
            }
        }
    ]
}

IAM의 CreateServiceLinkedRole 작업은 리소스 수준(Resource-Level) 권한 제어를 지원하지 않는다. 따라서 IAM 정책에서 Resource를 반드시 "*"로 설정해야 한다. 이는 서비스 연결 역할(Service-Linked Role)이 아직 존재하지 않는 새로운 역할을 생성하는 API이므로, 구체적인 리소스 식별자(ARN)를 미리 지정할 수 없기 때문이다. 그러나 "*"로 열어 두면, 어떤 AWS 서비스에 대해서든 서비스 연결 역할을 생성할 수 있어 보안상 위험이 발생할 수 있다. 이에 대한 대안으로, Condition 절을 사용해 특정 AWS 서비스에만 역할을 생성할 수 있도록 제한하여 필요한 범위 내에서 안전하게 권한을 부여한다.

공식 문서 내용 확인

AWS ECS에서 Application Auto Scaling(애플리케이션 자동 확장) 기능을 사용할 때, AWS가 자동으로 서비스 연결 역할을 생성한다. 또한 해당 역할은 특정 서비스(ECS)에서만 사용이 가능하고, AWS 서비스에 의해 생성 된 역할명은 아래와 같다.

• AWSServiceRoleForApplicationAutoScaling_ECSService

서비스 연결 역할(Service-Linked Role)을 사용하기 위해서는 주체자(AWS 로그인한 사용자)의 역할(Assume 받은 역할 : search-test-role)에 정의된 정책의 신뢰 관계(Trust Relationship)에 따라 특정 AWS 서비스만 사용할 수 있도록 제한이 된다. 그렇기에 ecs.application-autoscaling.amazonaws.com 을 아래와 같이 정책에 Condition으로 넣어야 한다. (위 내용은 실제 권한 문제 해결 후, 추가적인 내용은기재할 예정이다)

{
    "Effect": "Allow",
    "Action": [
        "iam:CreateServiceLinkedRole"
    ],
    "Resource": "*",
    "Condition": {
        "StringLike": {
            "iam:AWSServiceName": [
                "cloud9.amazonaws.com",
                "ecs.amazonaws.com",
                "ecs.application-autoscaling.amazonaws.com"
            ]
        }
    }
}

99. 참고 자료

Amazon ECS 및 Application Auto Scaling - Application Auto Scaling