[AWS] EMR Studio 및 Workspace 권한 관련 이슈 정리

📝서론

이번에 EMR에서 새로운 콘솔을 소개하면서, 기존의 notebook을 대체하는 Workspace 기능이 추가되었습니다. 다만 관련하여 권한 문서들이 너무 흩어져 있고, 헷갈리는 부분들이 꽤나 많습니다. Studio 생성, Workspace 생성 과정에서 권한 관련 이슈가 있을 때, 어떤 부분을 먼저 참고해보면 좋을 지 간략히 정리해보았습니다.

🤜본론

EMR_EC2_DefaultRole과 EMR_DefaultRole_V2(혹은 EMR role)의 차이점

저는 클러스터를 처음 생성했을 때, 위 두가지가 꽤나 헷갈렸던 기억이 있었는데요, 두가지의 차이는 다음과 같습니다.

EMR_EC2_DefaultRole은 클러스터에 사용되는 EC2 인스턴스에 주어지는 역할입니다. 인스턴스 프로필 역할과 동일한 개념이며,EMR_EC2_DefaultRole을 통해 클러스터 내부의 노드들은 필요한 권한을 얻게 됩니다. 만약 특정 S3에서 데이터를 읽어오는 Spark job을 submit 하려고 하는데 S3 Access Denied 에러가 등장한다면 이 인스턴스 프로필에 필요한 권한이 있는지 우선적으로 확인해볼 필요가 있습니다.

EMR_DefaultRole_V2는 EMR service role이라고도 하는데요, 이 service role은 클러스터에 필요한 리소스들을 확보할 때 (EC2 인스턴스) 사용합니다. 만약 클러스터를 생성하는 단계에서 에러가 발생한다면, 이 Service role의 권한이 부족한 부분이 있는지 먼저 확인해야 하겠습니다.

EMR Studio 생성시 사용하는 role 정리

Studio를 생성하게 될 경우 Studio 관리자, Studio 서비스 역할(Service role), Studio User정도의 세가지가 필요합니다. 위의 용도는 다음과 같습니다.

Studio 관리자는 EMR Studio를 생성, 삭제, 스튜디오에 User 추가 및 제거를 할 수 있습니다.
[+] 참고 문서
https://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-studio-admin-permissions.html

Studio 서비스 역할은 다른 AWS 서비스와 상호 작용할 수 있는 권한이 있는 IAM role입니다. Workspace의 파일 저장 및 Git 레포지토리와 연결 등에 필요합니다. 만약 Studio 생성 시에 이슈가 생긴다면, 해당 service role에 필요한 권한이 모두 충족되었는지 확인하는 것이 우선순위가 되겠습니다.
[+] 참고 문서
https://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-studio-service-role.html

Studio User는 말그대로 Studio를 사용하는 User인데요. 이 User는 Workspace 생성 및 삭제, EMR 클러스터 attach, detach 등 Workspace 내에서 작업 시 필요한 권한들을 이 User에 포함해줄 수 있습니다.
[+] 참고 문서

필요한 권한 정리

생성 혹은 작업 중 에러가 나타난다면 가장 먼저 확인해보면 좋을 부분에 대해 정리해보도록 하겠습니다.

(1) EMR Studio에서 Workspace 생성이 되지 않을 경우
EMR Studio 생성 시 사용한 Service Role의 권한을 확인합니다. 또한 CloudTrail을 이용하면 어떤 권한이 부족했는지 확인해볼 수 있습니다.

eventName	부족한 권한 이름
eventSource	ec2.amazonaws.com  
arn	arn:aws:iam::${account_num}:role/${service_role_name}
userName	service_role_name
errorCode	Client.UnauthorizedOperation
errorMessage	You are not authorized to perform this operation. Encoded authorization failure message: ..(omitted)…

또한, 해당 경우 에러가 발생하면 encoding된 메세지가 같이 등장하는데요, AWS CLI를 사용하여 메시지 decode 후 어떤 권한이 부족했는지 확인해볼 수 있습니다.

$ aws sts decode-authorization-message --encoded-message message-context 

(2) Workspace 내에서 EMR Cluster 생성하기

Workspace 내에서 클러스터를 생성하려고 할 때 Studio User를 이용했을 때 다음과 같은 에러가 발생합니다.

이 에러는 해당 Studio User에 'iam:PassRole' Action이 없어서 발생하는 에러인데요. EMR Cluster를 생성하기 위해서는 위에서 나온 EMR service role이 필요합니다. 'iam:PassRole' Action은 이 Studio User에게 EMR_DefaultRole (혹은 v2)을 사용할 수 있도록 역할을 전달해줍니다. 따라서 다음과 같은 정책을 생성한 후 해당 User에게 Attach 해주세요.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRole",
                "iam:PassRole"
            ],
            "Resource": [
                "arn:aws:iam::${account_num}:role/*",
                "arn:aws:iam::${account_num}:user/*"
            ]
        }
    ]
}

(3) Workspace 내에서 미리 지정한 Template를 이용하여 EMR Cluster를 생성할 때 이슈

Workspace에서 미리 지정된 EMR 클러스터 Template를 이용하려면, Service Catalog 에서 Product를 미리 생성해주어야 합니다.

위의 Create portfolio를 눌러 새로운 포트폴리오를 생성해야하고, 생성된 포트폴리오 안에는 다음과 같이 product가 추가되어있어야 합니다.

product 생성 시 YAML 형식의 파일을 업로드 하거나, 탬플릿이 업로드 되어있는 S3의 경로를 명시해줄 수도 있습니다.

체크 해야 할 부분은 다음과 같습니다.

• 아래와 같이 Access 탭에서 사용하는 EMR Studio User에게 권한을 Grant했는지 확인합니다. 만약 해당 부분에서 권한을 주지 않았다면, EMR Studio에서 지정된 Template을 확인할 수 없게 됩니다. (공란처리 됨)

• 위와 같이 권한을 제공했으며, Workspace에서 해당 template이 정상적으로 보이는데도 다음과 같이 Validation 에러가 발생하면서 S3 Access Denied 에러가 발생

이게 무슨 말인가 싶을 것입니다. 말 그대로 에러 이름은 Validation Error이지만 에러 메시지 내용은 S3에 Access Denied 되었다는 내용이 나오는데요.

eventName	DescribeProvisioningParameters
errorCode	ValidationException
errorMessage	S3 error: Access Denied For more information check http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html  

여기서 의문점이 생깁니다. 이용하는 User에 해당 template 양식을 올려둔 S3에 접근할 수 있는 권한을 주었음에도, 위와 같이 에러가 발생하곤 합니다.

결론적으로 이는 예상되는 동작이며, 보통 User에 S3 관련 권한 추가시 resource 부분을 all로 열어주지 않았을 때 일어나는 일입니다.
미리 지정된 클러스터 Template를 사용하기 위해서는 (1) Service Catalog가 template을 저장하는 나의 버킷 (cf-templates-* 형식), (2) AWS에서 Service Catalog가 이용하는 내부 버킷(이 있는 것으로 보입니다)에 대한 권한이 필요하기 때문에, 해당 User에게 S3의 GetObject Action에 대해 Resource를 all로 열어주는 정책을 생성하여 attach 해줍니다.

{
      "Sid": "s3",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "*"
      ]
}

결론

EMR Studio 및 Workspace, 그리고 필요한 서비스 역할들에 대하여 헷갈리지 않도록 간략히 정리해보았습니다. 혹시 관련하여 어려움을 겪고 계신다면 참고해보았을 때 도움이 되셨기를 바랍니다. 읽어주셔서 감사합니다!