기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# EKS 클러스터에 IAM 역할 활성화
<a name="setting-up-enable-IAM-roles"></a>

다음 항목에서는 IAM 역할을 활성화하기 위한 옵션을 자세히 설명합니다.

**Topics**
+ [옵션 1: EKS 클러스터에서 EKS Pod Identity 활성화](setting-up-enable-IAM.md)
+ [옵션 2: EKS 클러스터에서 서비스 계정에 대한 IAM 역할(IRSA) 활성화](setting-up-enable-IAM-service-accounts.md)

# 옵션 1: EKS 클러스터에서 EKS Pod Identity 활성화
<a name="setting-up-enable-IAM"></a>

Amazon EKS Pod Identity는 Amazon EC2 인스턴스 프로필이 Amazon EC2 인스턴스에 자격 증명을 제공하는 것과 비슷한 방식으로 애플리케이션에 대한 자격 증명을 관리하는 기능을 제공합니다. Amazon EKS Pod Identity는 추가 EKS Auth API와 각 노드에서 실행되는 에이전트 포드를 통해 워크로드에 보안 인증 정보를 제공합니다.

Amazon EMR on EKS는 emr-7.3.0 릴리스부터 StartJobRun 제출 모델에 대해 EKS 포드 ID를 지원하기 시작했습니다.

EKS Pod Identity에 대한 자세한 내용은 [EKS Pod Identity의 작동 방식 이해](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html)를 참조하세요.

## EKS Pod Identity를 사용해야 하는 이유는 무엇인가요?
<a name="setting-up-enable-IAM-pod-identity-why"></a>

EMR 설정의 일환으로 작업 실행 역할은 IAM 역할과 특정 네임스페이스(EMR 가상 클러스터)의 서비스 계정 간에 신뢰 경계를 설정합니다. IRSA를 사용하면 EMR 작업 실행 역할의 신뢰 정책을 업데이트하여 이를 수행할 수 있습니다. 그러나 IAM 신뢰 정책 길이의 4096자 하드 제한으로 인해 최대 열두(12개) EKS 클러스터에서 단일 작업 실행 IAM 역할을 공유하는 제약이 있었습니다.

포드 ID에 대한 EMR의 지원을 통해 이제 EKS 팀이 EKS 포드 ID의 연결 API를 통해 IAM 역할과 서비스 계정 간의 신뢰 경계를 관리합니다.

**참고**  
EKS Pod Identity의 보안 경계는 포드 수준이 아니라 서비스 계정 수준에 위치합니다.

## Pod Identity 고려 사항
<a name="setting-up-enable-IAM-pod-identity-consider"></a>

Pod Identity 제한 사항에 대한 자세한 내용은 [EKS Pod Identity 고려 사항](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations)을 참조하세요.

## EKS 클러스터에서 EKS Pod Identity 준비
<a name="setting-up-enable-IAM-pod-eks-cluster"></a>

### 필수 권한이 NodeInstanceRole에 있는지 확인
<a name="setting-up-enable-IAM-pod-eks-cluster-permission"></a>

노드 역할 `NodeInstanceRole`에는 에이전트가 EKS 인증 API에서 `AssumeRoleForPodIdentity` 작업을 수행할 수 있는 권한이 필요합니다. Amazon EKS 사용 설명서에 정의된 [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy)에 다음을 추가하거나 사용자 지정 정책을 사용할 수 있습니다.

EKS 클러스터가 **0.181.0**보다 높은 eksctl 버전으로 생성된 경우, 필요한 `AssumeRoleForPodIdentity` 권한을 포함한 AmazonEKSWorkerNodePolicy가 노드 역할에 자동으로 첨부됩니다. 권한이 없는 경우 Pod Identity에 대한 역할 인계를 허용하는 다음 권한을 AmazonEKSWorkerNodePolicy에 수동으로 추가합니다. 이 권한은 EKS Pod Identity 에이전트가 포드의 자격 증명을 검색하는 데 필요합니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks-auth:AssumeRoleForPodIdentity"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEKSAUTHAssumeroleforpodidentity"
    }
  ]
}
```

------

### EKS Pod Identity 에이전트 추가 기능 만들기
<a name="setting-up-enable-IAM-pod-eks-cluster-agent"></a>

다음 명령을 사용하여 EKS Pod Identity Agent 추가 기능을 최신 버전으로 생성합니다.

```
aws eks create-addon --cluster-name cluster-name --addon-name eks-pod-identity-agent

kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```

다음 단계를 사용하여 Amazon EKS 콘솔에서 EKS Pod Identity Agent 추가 기능을 생성합니다.

1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)에서 Amazon EKS 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **클러스터**를 선택한 다음 EKS Pod Identity 에이전트 추가 기능을 구성할 클러스터의 이름을 선택합니다.

1. **추가 기능** 탭을 선택합니다.

1. **추가 기능 더 가져오기**를 선택합니다.

1. EKS Pod Identity 에이전트 추가 기능 상자의 오른쪽 상단에 있는 상자를 선택하고 **다음**을 선택합니다.

1. **선택한 추가 기능 설정 구성** 페이지의 **버전** 드롭다운 목록에서 임의의 버전을 선택합니다.

1. (선택사항) **선택적 구성 설정**을 확장하여 추가 구성을 입력합니다. 예를 들어, 대체 컨테이너 이미지 위치 및 `ImagePullSecrets`를 제공할 수 있습니다. 허용된 키가 포함된 JSON Schema는 **추가 기능 구성 스키마**에 표시됩니다.

   **구성 값**에 구성 키와 값을 입력합니다.

1. **다음**을 선택합니다.

1. CLI를 통해 에이전트 포드가 클러스터에서 실행 중인지 확인합니다.

   `kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'`

예시 출력은 다음과 같습니다.

```
NAME                              READY   STATUS    RESTARTS      AGE
eks-pod-identity-agent-gmqp7      1/1     Running   1 (24h ago)   24h
eks-pod-identity-agent-prnsh      1/1     Running   1 (24h ago)   24h
```

이 작업을 수행하면 `kube-system` 네임스페이스에 새 DaemonSet가 설정됩니다. 각 EKS 노드에서 실행되는 Amazon EKS Pod Identity 에이전트는 [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) 작업을 사용하여 EKS Auth API에서 임시 자격 증명을 검색합니다. 그런 다음 컨테이너 내에서 실행하는 AWS SDKs에 이러한 자격 증명을 사용할 수 있습니다.

자세한 내용은 퍼블릭 문서의 사전 조건인 [Amazon EKS Pod Identity Agent 설정](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)을 참조하세요.

## 작업 실행 역할 생성
<a name="setting-up-enable-IAM-pod-create-job-role"></a>

### EKS Pod Identity를 허용하는 작업 실행 역할 만들기 또는 업데이트
<a name="setting-up-enable-IAM-pod-create-job-role-update"></a>

Amazon EMR를 사용하여 EKS에서 워크로드를 실행하려면 IAM 역할을 생성해야 합니다. 이 설명서에서는 이 역할을 작업 실행 역할이라고 합니다. IAM 역할 생성에 대한 자세한 내용은 사용 설명서에서 [IAM 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)을 참조하세요.

또한 작업 실행 역할에 필요한 권한을 지정하는 IAM 정책을 생성한 다음이 정책을 역할에 연결하여 EKS Pod Identity를 활성화합니다.

예를 들어, 다음과 같은 작업 실행 역할이 있습니다. 자세한 내용은 [작업 실행 역할 만들기](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)를 참조하세요.

```
arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole
```

**중요**  
Amazon EMR on EKS는 작업 실행 역할 이름을 기반으로 Kubernetes 서비스 계정을 자동으로 생성합니다. `cluster_name`, `pod_name` 및 `service_account_name`의 조합이 길이 제한을 초과할 경우 작업이 실패할 수 있으므로 역할 이름이 너무 길지 않은지 확인합니다.

**작업 실행 역할 구성** - 작업 실행 역할이 EKS Pod Identity에 대한 아래 신뢰 권한으로 생성되었는지 확인합니다. 기존 작업 실행 역할을 업데이트하려면 다음 EKS 서비스 보안 주체를 신뢰 정책의 추가 권한으로 신뢰하도록 구성합니다. 이 신뢰 권한은 기존 IRSA 신뢰 정책과 함께 사용할 수 있습니다.

```
cat >trust-relationship.json <<EOF
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}
EOF
```

**사용자 권한**: 사용자에게는 `StartJobRun` API 호출을 실행하거나 작업을 제출할 수 있는 `iam:PassRole` 권한이 필요합니다. 이 권한을 통해 사용자는 작업 실행 역할을 EMR on EKS에 전달할 수 있습니다. 기본적으로 작업 관리자에게는 권한이 있어야 합니다.

사용자에게 필요한 권한은 다음과 같습니다.

```
{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole",
    "Condition": {
        "StringEquals": {
            "iam:PassedToService": "pods.eks.amazonaws.com"
        }
    }
}
```

특정 EKS 클러스터에 대한 사용자 액세스를 추가적으로 제한하려면 IAM 정책에 AssociatedResourceArn 속성 필터를 추가합니다. 역할 가정을 승인된 EKS 클러스터로 제한하여 리소스 수준 보안 제어를 강화합니다.

```
"Condition": {
        "ArnLike": {
            "iam:AssociatedResourceARN": [
                "arn:aws:eks:us-west-2:111122223333:cluster/*"
            ]
        }
```

## EKS Pod Identity 연결 설정
<a name="setting-up-enable-IAM-pod-identity-asociations"></a>

### 사전 조건
<a name="setting-up-enable-IAM-pod-identity-asociations-prereq"></a>

EKS 관리자 사용자와 같은 Pod Identity 연결을 생성하는 IAM 자격 증명에 `eks:CreatePodIdentityAssociation` 및 `iam:PassRole` 권한이 있는지 확인합니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:CreatePodIdentityAssociation"
      ],
      "Resource": [
        "arn:aws:eks:*:*:cluster/*"
      ],
      "Sid": "AllowEKSCreatepodidentityassociation"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:aws:iam::*:role/*"
      ],
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "pods.eks.amazonaws.com"
        }
      },
      "Sid": "AllowIAMPassrole"
    }
  ]
}
```

------

### 역할 및 EMR 서비스 계정에 대한 연결 생성
<a name="setting-up-enable-IAM-pod-identity-asociations-emr-service"></a>

------
#### [ Create EMR role associations through the AWS CLI ]

작업을 Kubernetes 네임스페이스에 제출할 때 관리자는 작업 실행 역할과 EMR 관리형 서비스 계정의 자격 증명 간에 연결을 생성합니다. 단, EMR 관리형 서비스 계정은 작업 제출 시 자동으로 생성되며 작업이 제출된 네임스페이스로 범위가 지정됩니다.

 AWS CLI (버전 2.24.0 이상)에서 다음 명령을 실행하여 포드 자격 증명과의 역할 연결을 생성합니다.

다음 명령을 실행하여 Pod Identity와 역할 연결을 생성합니다.

```
aws emr-containers create-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

참고:
+ 각 클러스터에는 1,000개의 연결 제한이 있을 수 있습니다. 각 작업 실행 역할 - 네임스페이스 매핑에는 작업 제출자, 드라이버 및 실행기 포드에 대한 3개의 연결이 필요합니다.
+ 클러스터와 동일한 AWS 계정에 있는 역할만 연결할 수 있습니다. EKS Pod Identity가 사용하도록 구성한 이 계정의 역할에 다른 계정의 액세스 권한을 위임할 수 있습니다. 액세스 권한 위임 및에 대한 자습서는 [IAM 자습서: IAM 역할을 사용하여 AWS 계정 간 액세스 권한 위임](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)을 `AssumeRole`참조하세요.

------
#### [ Create EMR role associations through Amazon EKS ]

EMR은 작업이 제출될 때 특정 명명 패턴이 있는 서비스 계정을 생성합니다. 수동으로 연결하거나이 워크플로를 AWS SDK와 통합하려면 다음 단계를 따르세요.

구문 서비스 계정 이름:

```
emr-containers-sa-spark-%(SPARK_ROLE)s-%(AWS_ACCOUNT_ID)s-%(BASE36_ENCODED_ROLE_NAME)s
```

아래 예제에서는 샘플 작업 실행 역할 JobExecutionRoleIRSAv2의 역할 연결을 생성합니다.

**역할 연결 예제:**

```
RoleName: JobExecutionRoleIRSAv2
Base36EncodingOfRoleName: 2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

**샘플 CLI 명령:**

```
# setup for the client service account (used by job runner pod)
# emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# driver service account
# emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe        
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# executor service account
# emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

------

EKS Pod Identity에 필요한 모든 단계를 완료한 후에는 IRSA 설정에서 다음 단계를 건너뛸 수 있습니다.
+ [EKS 클러스터에서 서비스 계정에 대한 IAM 역할(IRSA) 활성화](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [작업 실행 역할 생성](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [작업 실행 역할의 신뢰 정책 업데이트](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)

[사용자에게 Amazon EMR on EKS에 대한 액세스 권한 부여](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html) 단계로 직접 건너뛸 수 있습니다.

## 역할 연결 삭제
<a name="setting-up-enable-IAM-pod-identity-asociations-delete-associations"></a>

가상 클러스터 또는 작업 실행 역할을 삭제하고 더 이상 서비스 계정에 EMR에 대한 액세스 권한을 부여하지 않으려는 경우 해당 역할에 대한 연결을 삭제합니다. 그 이유는 EKS가 존재하지 않는 리소스(네임스페이스 및 서비스 계정)와의 연결을 허용하기 때문입니다. Amazon EMR on EKS는 네임스페이스가 삭제되거나 역할이 더 이상 사용되지 않는 경우 연결을 삭제하여 다른 연결을 위한 공간을 확보할 것을 권장합니다.

**참고**  
EKS에는 생성할 수 있는 연결 수에 제한이 있으므로(소프트 제한: 클러스터당 연결 1,000개), 연결을 삭제하지 않으면 잔여 연결이 확장 기능에 영향을 미칠 수 있습니다. 지정된 네임스페이스에 Pod Identity 연결을 나열하여 정리해야 하는 잔여 연결이 있는지 확인할 수 있습니다.

```
aws eks list-pod-identity-associations --cluster-name mycluster --namespace mynamespace
```

 AWS CLI (버전 2.24.0 이상)에서 다음 emr-containers 명령을 실행하여 EMR의 역할 연결을 삭제합니다.

```
aws emr-containers delete-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

## 기존 IRSA를 Pod Identity로 자동 마이그레이션
<a name="setting-up-enable-IAM-pod-identity-auto-migrate"></a>

eksctl 도구를 사용하여 서비스 계정에 대한 기존 IAM 역할(IRSA)을 Pod Identity 연결로 마이그레이션할 수 있습니다.

```
eksctl utils migrate-to-pod-identity \
    --cluster mycluster \
    --remove-oidc-provider-trust-relationship \
    --approve
```

`--approve` 플래그를 지정하지 않고 명령을 실행하면 마이그레이션 단계를 반영하는 계획만 출력되며 실제 마이그레이션이 발생하지 않습니다.

## 문제 해결
<a name="setting-up-enable-IAM-pod-identity-troubleshooting"></a>

### 자격 증명 공급자에 대한 NoClassDefinitionFound 또는 ClassNotFound 예외로 인해 작업이 실패했거나 자격 증명 공급자를 가져오지 못했습니다.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-no-class"></a>

EKS Pod Identity는 컨테이너 자격 증명 공급자를 사용하여 필요한 자격 증명을 검색합니다. 사용자 지정 자격 증명 공급자를 지정한 경우 올바르게 작동하는지 확인합니다. 또는 EKS Pod Identity를 지원하는 올바른 AWS SDK 버전을 사용하고 있는지 확인합니다. 자세한 내용은 [Amazon EKS 시작하기](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)를 참조하세요.

### eks-pod-identity-agent 로그에 표시된 "[x] 크기 제한으로 인해 자격 증명을 검색하지 못함" 오류로 인해 작업이 실패했습니다.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds"></a>

EMR on EKS는 Kubernetes 서비스 계정을 작업 실행 역할 이름을 기반으로 생성합니다. 역할 이름이 너무 길면 , `cluster_name` `pod_name` 및 `service_account_name`의 조합이 길이 제한을 초과하기 때문에 EKS Auth가 자격 증명을 검색할 수 없습니다. 공간을 가장 많이 차지하는 구성 요소를 식별하고 그에 따라 크기를 조정합니다.

### eks-pod-identity 로그에 표시된 "xxx 자격 증명 검색에 실패했습니다." 오류로 인해 작업이 실패했습니다.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds-error"></a>

이 문제의 한 가지 가능한 원인은 클러스터에 대해 PrivateLink를 올바르게 구성하지 않고 프라이빗 서브넷에 EKS 클러스터가 구성되어 있기 때문일 수 있습니다. 클러스터가 프라이빗 네트워크에 있는지 확인하고 문제를 해결하려면 AWS PrivateLink를 구성합니다. 자세한 지침은 [Amazon EKS 시작하기](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)를 참조하세요.

# 옵션 2: EKS 클러스터에서 서비스 계정에 대한 IAM 역할(IRSA) 활성화
<a name="setting-up-enable-IAM-service-accounts"></a>

서비스 계정에 대한 IAM 역할 기능은 Amazon EKS 버전 1.14 이상 및 2019년 9월 3일 이후 버전 1.13 이상으로 업데이트된 EKS 클러스터에서 사용할 수 있습니다. 이 기능을 사용하기 위해 기존 EKS 클러스터를 버전 1.14 이상으로 업데이트할 수 있습니다. 자세한 내용은 [Amazon EKS 클러스터 Kubernetes 버전 업데이트](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)를 참조하세요.

클러스터에서 서비스 계정에 대한 IAM 역할을 지원하는 경우 클러스터는 이 역할에 연결된 [OpenID Connect](https://openid.net/connect/) 발행자 URL을 갖게 됩니다. Amazon EKS 콘솔에서이 URL을 보거나 다음 AWS CLI 명령을 사용하여 검색할 수 있습니다.

**중요**  
이 명령에서 적절한 출력을 받으려면 최신 버전의 AWS CLI 를 사용해야 합니다.

```
aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text
```

예상 출력은 다음과 같습니다.

```
https://oidc.eks.<region-code>.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E
```

클러스터에서 서비스 계정에 대한 IAM 역할을 사용하려면 [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) 또는 [AWS Management Console](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console)을 사용하여 OIDC ID 제공업체를 생성해야 합니다.

## `eksctl`로 클러스터의 IAM OIDC 자격 증명 공급자를 생성하려면
<a name="setting-up-OIDC-eksctl"></a>

`eksctl` 버전은 다음 명령을 통해 확인할 수 있습니다. 이 절차에서는 `eksctl`을 설치했으며 `eksctl` 버전이 0.32.0 이상인 것으로 가정합니다.

```
eksctl version
```

eksctl 설치 또는 업그레이드에 관한 자세한 내용은 [Installing or upgrading eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl)을 참조하세요.

다음 명령을 사용하여 클러스터용 OIDC 자격 증명 공급자를 생성합니다. *cluster\$1name*을 고유한 값으로 바꿉니다.

```
eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve
```

## 를 사용하여 클러스터에 대한 IAM OIDC 자격 증명 공급자를 생성하려면 AWS Management Console
<a name="setting-up-OIDC-console"></a>

클러스터의 Amazon EKS 콘솔 설명에서 OIDC 발급자 URL을 검색하거나 다음 AWS CLI 명령을 사용합니다.

 AWS CLI에서 OIDC 발급자 URL을 검색하려면 다음 명령을 사용합니다.

```
aws eks describe-cluster --name <cluster_name> --query "cluster.identity.oidc.issuer" --output text
```

Amazon EKS 콘솔에서 OIDC 발급자 URL을 검색하려면 다음 단계를 사용합니다.

1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.

1. 탐색 창에서 **ID 제공업체**를 선택하고 **제공업체 생성**을 선택합니다.

   1. **공급자 유형**에서 **공급자 유형 선택**을 선택한 다음 **OpenID Connect**를 선택합니다.

   1. **Provider URL(공급자 URL)**에 클러스터의 OIDC 발행자 URL을 붙여넣습니다.

   1. 대상에서 sts.amazonaws.com을 입력한 후 **다음 단계**를 선택합니다.

1. 공급자 정보가 올바른지 확인한 다음 **생성**을 선택하여 자격 증명 공급자를 생성합니다.

# 작업 실행 역할 생성
<a name="creating-job-execution-role"></a>

Amazon EMR on EKS에서 워크로드를 실행하려면 IAM 역할을 생성해야 합니다. 이 설명서에서는 이 역할을 *작업 실행 역할*이라고 합니다. IAM 역할 생성에 대한 자세한 내용은 IAM 사용 설명서에서 [IAM 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)을 참조하세요.

또한 작업 실행 역할에 대한 권한을 지정하는 IAM 정책을 생성한 다음, IAM 정책을 작업 실행 역할에 연결해야 합니다.

작업 실행 역할에 대한 다음 정책은 리소스 대상, Amazon S3 및 CloudWatch에 대한 액세스를 허용합니다. 이러한 권한은 작업 및 액세스 로그를 모니터링하는 데 필요합니다. AWS CLI를 사용하여 동일한 프로세스를 수행하려면: 

작업 실행을 위한 IAM 역할 만들기: EMR이 작업 실행에 사용할 역할을 만들어 보겠습니다. 이 역할은 EKS에서 실행될 때 EMR 작업이 수행하게 될 역할입니다.

```
cat <<EoF > ~/environment/emr-trust-policy.json
 {
   "Version": "2012-10-17",		 	 	 
   "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "Service": "elasticmapreduce.amazonaws.com"
       },
       "Action": "sts:AssumeRole"
     }
   ]
 }
 EoF
  
 aws iam create-role --role-name EMRContainers-JobExecutionRole --assume-role-policy-document file://~/environment/emr-trust-policy.json
```

다음으로 s3 및 cloudwatch에 로그를 쓸 수 있도록 필요한 IAM 정책을 역할에 연결합니다.

```
cat <<EoF > ~/environment/EMRContainers-JobExecutionRole.json
 {
     "Version": "2012-10-17",		 	 	 
     "Statement": [
         {
             "Effect": "Allow",
             "Action": [
                 "s3:PutObject",
                 "s3:GetObject",
                 "s3:ListBucket"
             ],
             "Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
         },
         {
             "Effect": "Allow",
             "Action": [
                 "logs:PutLogEvents",
                 "logs:CreateLogStream",
               "logs:DescribeLogGroups",
                 "logs:DescribeLogStreams"
             ],
             "Resource": [
                 "arn:aws:logs:*:*:*"
             ]
         }
     ]
 } 
 EoF
 aws iam put-role-policy --role-name EMRContainers-JobExecutionRole --policy-name EMR-Containers-Job-Execution --policy-document file://~/environment/EMRContainers-JobExecutionRole.json
```

**참고**  
액세스 범위는 적절해야 하며, 작업 실행 역할의 모든 S3 객체에 부여되지 않아야 합니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket"
      ],
      "Sid": "AllowS3Putobject"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:PutLogEvents",
        "logs:CreateLogStream",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:*:*:*"
      ],
      "Sid": "AllowLOGSPutlogevents"
    }
  ]
}
```

------

자세한 내용은 [작업 실행 역할 사용](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [S3 로그를 사용하도록 작업 실행 구성](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) 및 [CloudWatch Logs를 사용하도록 작업 실행 구성](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch)을 참조하세요.

# 작업 실행 역할의 신뢰 정책 업데이트
<a name="setting-up-trust-policy"></a>

서비스 계정에 대한 IAM 역할(IRSA)을 사용하여 Kubernetes 네임스페이스에서 작업을 실행하는 경우 관리자는 작업 실행 역할과 EMR 관리형 서비스 계정의 자격 증명 사이에서 신뢰 관계를 생성해야 합니다. 신뢰 관계는 작업 실행 역할의 신뢰 정책을 업데이트하여 생성할 수 있습니다. 단, EMR 관리형 서비스 계정은 작업 제출 시 자동으로 생성되며 작업이 제출된 네임스페이스로 범위가 지정됩니다.

다음 명령을 실행하여 신뢰 정책을 업데이트합니다.

```
 aws emr-containers update-role-trust-policy \
       --cluster-name cluster \
       --namespace namespace \
       --role-name iam_role_name_for_job_execution
```

자세한 내용은 [Amazon EMR on EKS에서 작업 실행 역할 사용](iam-execution-role.md) 단원을 참조하십시오.

**중요**  
위 명령을 실행하는 운영자에게 `eks:DescribeCluster`, `iam:GetRole`, `iam:UpdateAssumeRolePolicy` 권한이 있어야 합니다.