AWS AccessDeniedException: user is not authorized to perform: iam:PassRole on resource 에러 해결 방법

 Boto3나 AWS CLI를 사용하여 Glue 명령어를 수행할 때 다음과 같은 에러메세지가 떴다.

botocore.errorfactory.AccessDeniedException: An error occurred (AccessDeniedException) when calling the UpdateJob operation: UserL arn:aws:iam:***:user/{유저이름} is not authorized to perform: iam:PassRole on resource: arn:aws:iam:***:role/{역할이름} because no identity-based policy allows the iam:PassRole action

 처음 봤을 때 일단 똑같은 말을 여러 번 하면서 쓸데없이 길게 뜬 에러메세지라 빡쳤다. 마음을 다잡고 해석을 해보면 결국 현재 컴퓨터(또는 가상머신)에서 사용하고 있는 user에게 명령어를 내릴때 argument로 넘겨준 역할(role)을 수행할 수 있는 iam:PassRole 권한이 없기 때문에 발생한 에러다.

 결국 user에게 iam:PassRole을 주면 되는데, 이게 Permission에서 아무리 검색해봐도 없다..

 하지만 결국 답은 공식문서에 나와있었다. 친절하게 적혀있지 않아서 어쩌라고 싶었는데 찬찬히 읽어보면 생각보다 해결 방법이 간단하다.

 

해결방법

1. 권한을 수정할 수 있는 계정으로 로그인 한 뒤 IAM > User > User groups로 들어간다.

2. CLI나 boto3를 사용하는 컴퓨터에 인증된 user가 속한 group을 클릭한다.

3. 'Permissions' 탭에 들어간다.

4. Add permissions > Create inline policy를 클릭한다. 

5. JSON을 클릭한 뒤 다음 구문을 입력한 후 Review policy를 클릭한다 (Resource에는 명령어를 실행할 때 role값으로 넘겨준 역할 arn을 적어주면 된다).

 주의할 점: 에러 메세지는 Passrole 문제라고 페이크쳤지만 Passrole과 Getrole 둘 다 있어야한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:PassRole",
                "iam:GetRole"
            ],
            "Resource": "arn:aws:iam::{계정 번호}:role/{역할 이름}"
        }
    ]
}

6. Name에 본인이 식별할 수 있는 해당 permission의 이름(e.g. IAMPassRole)을 지정해주고 create policy 버튼을 눌러 정책을 생성한다.

7. 해당 group에 사용하고자하는 작업을 수행할 수 있는 권한을 추가해준다 (이미 있으면 pass).

 나는 Glue job을 생성, 수정, 삭제하는 작업이 필요하므로 AWSGlueConsoleFullAccess 권한을 추가해줬다.

 

문제 해결!

 

iam:PassRole이 필요한 이유

 Role에 얼마만큼의 권한이 부여되어 있든 상관없이 사용자에게 부여된 권한만큼만 서비스에 접근할 수 있게 하기 위함이다.

 예를 들어, admin이라는 이름의 역할에 모든 서비스에 대한 접근 권한이 부여되어 있고 사용자에게는 Glue 접근 권한이 없다면 해당 사용자가 admin 역할로 명령어를 수행해도 Glue에 접근할 수 없도록 한다. 이를 통해 사용자마다 일일이 Role을 만들어 줘야하는 번거로움을 없앨 수 있다.

 따라서 role이름이 admin이고 user이름이 de라고 할때, de에게 passrole 정책이 부여되어 있으면 admin role에 부여된 권한과 상관 없이 de user에게 부여된 권한을 사용할 수 있다.

• 즉, admin role에 glue 접근 권한이 없어도 de user에 glue 권한이 있으면 접근할 수 있다.
• 반대로 admin role에 glue 권한이 있어도 de user에 권한이 없으면 접근할 수 없다.
• 그리고 둘 다 권한이 있어도 passrole 정책이 부여되어 있지 않으면 Glue는 사용할 수 없다 (왜요..).

 S3와 Lamda는 Passrole을 사용하지 않는 것 같고, Glue와 EC2는 사용하는 것 같다. 기준 무엇