배경

AWS를 사용하는 프로젝트의 경우 시스템 관리자 등의 관리자 권한이 있는 경우가 대부분입니다.
개발자나 운용자는 IAM 같은 강력한 권한이 없다고 생각합니다.
예를 들어 개발 단계와 테스트에서 여러 차례 조정할 때 관리자가 대응하기 어렵다.
또 개발 환경이라면 한정적으로 권한을 부여할 수도 있다.

예제

"어? IAM 권한 같은 거...?"이 가능하다, ~할 수 있다,...
예제에는 ECS 자동 조정 설정 조정이 포함됩니다.
ECS의 FullAccess 권한이 있다면 아마 변경할 수 있을 것 같습니다.
일반적으로 ECS의 AutoScaling은 AutoScaling이 사용할 수 있는 전용 IAM 역할을 사용합니다.

서비스 업데이트 화면으로 치면 이 근처야.
Scaling을 위한 정책은 구체적으로 무엇입니까?말하자면
・ CloudWatch 경고를 통한 읽기/쓰기
• 서비스 변경에 필요한 작업 수
버려진 함수에 대한 지원이 부족합니다.
즉, 본론으로 돌아가 ECS에 필요한 작업 수를 1에서 2로 변경하려는 경우
ECS 서비스 변경 권한 = ECS 권한 제외
역할 자동 조정 권한 변경 = IAM 권한이 필요합니다.
개발자에게 IAM 권한이 없으면 액세스 검증 및 변경을 수행할 수 없습니다.
위에서 말한 바와 같이 AWS 사용자뿐만 아니라 AWS 서비스에도 IAM 권한을 부여하는 경우가 많다.
그러면 사용자는 IAM 권한을 추가해야 합니다.
그렇다고 관리자 권한을 함부로 늘릴 수는 없겠죠.

처리 방법

이런 상황에서 자원을 사용자에게 한정하기만 하면 해당하는 역할을 변경할 수 있는 권한을 해결할 수 있다.
이 예제에서는 ECS의 AutoScalingRole 리소스에 대해서만 Role 변경 권한을 부여합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::XXXXXXXXXXXX:role/aws-service-role/ecs.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ECSService"
        }
    ]
}

이것은 샘플입니다. 자원을 지정한 후에 "iam:PassRole"을 제공합니다.
참고로 이번에 지정된 Role은 AWS의 관리 역할인 ARN입니다.

총결산

AWS IAM은 사용자뿐만 아니라 AWS 서비스 권한도 부여합니다.
디자인할 때 머릿속에서 정리하지 않으면 혼란스러워요.
사용 권한 변경 권한?누가 썼지?서비스
다만 이곳을 잘못 알면 필요 없는 권한까지 주어져 위험이 커질 수 있으니 정기적으로 재검토하자.

경품

따라서 ECS의 관리 관리 정책 권장 사항은 2021/1/29에 따라 달라집니다.
전통적인 정책은iam:passrole을 포함하지만 자원과 조건은 제한을 받지 않습니다.
https://docs.amazonaws.cn/en_us/AmazonECS/latest/developerguide/managed-policy-transition.html
◆ 지금까지의 정책(발췌)
AmazonEC2ContainerServiceFullAccess

                "iam:PassRole"
            ],
            "Resource": "*"

◆ 새로운 추천 정책
AmazonECS_FullAccess
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_managed_policies.html#AmazonECS_FullAccess
지금 쓰고 있는 정책이 못 쓰는 것은 아니지만 이를 계기로 권한 주변을 다시 살펴보고 싶다.