**이 페이지 개선에 도움 주기** 

이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.

# Kubernetes 서비스 계정을 사용하여 Kubernetes 워크로드에 AWS에 대한 액세스 권한 부여
<a name="service-accounts"></a>[서비스 계정 관리](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[서비스 계정에 대한 IAM 역할](iam-roles-for-service-accounts.md)[EKS Pod Identity가 포드에 AWS 서비스에 대한 액세스 권한을 부여하는 방법 알아보기](pod-identities.md)

## 서비스 계정 토큰
<a name="service-account-tokens"></a>

[BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) 기능은 Kubernetes 버전에서 기본적으로 활성화됩니다. 이 기능은 Kubernetes에서 실행되는 워크로드가 대상, 시간 및 키 바인딩인 JSON 웹 토큰을 요청하도록 허용하여 서비스 계정 토큰의 보안을 향상시킵니다. 서비스 계정 토큰에는 1시간 만료 기간이 있습니다. 이전 Kubernetes 버전에는 토큰에 만료 기간이 없었습니다. 즉, 이러한 토큰에 의존하는 클라이언트는 1시간 이내에 토큰을 새로 고쳐야 합니다. 다음 [Kubernetes 클라이언트 SDK](https://kubernetes.io/docs/reference/using-api/client-libraries/)는 필요한 시간 내에 토큰을 자동으로 새로 고칩니다.
+ Go 버전 `0.15.7` 이상
+ Python 버전 `12.0.0` 이상
+ Java 버전 `9.0.0` 이상
+ JavaScript 버전 `0.10.3` 이상
+ Ruby `master` 브랜치
+ Haskell 버전 `0.3.0.0` 
+ C\$1 버전 `7.0.5` 이상

워크로드가 이전 클라이언트 버전을 사용하는 경우 업데이트해야 합니다. 클라이언트가 최신 시간 바운드 서비스 계정 토큰으로 원활하게 마이그레이션되도록 Kubernetes는 기본 1시간 서비스 계정 토큰의 만료 기간을 추가로 연장합니다. Amazon EKS 클러스터의 경우 연장 만료 기간은 90일입니다. Amazon EKS 클러스터 Kubernetes API 서버는 90일이 지난 토큰을 사용한 요청을 거부합니다. 애플리케이션 및 해당 종속성을 확인하여 Kubernetes 클라이언트 SDK가 이전에 나열된 버전과 동일하거나 이후 버전인지 확인하는 것이 좋습니다.

API 서버가 1시간 이상 된 토큰으로 요청을 수신하면 API 감사 로그 이벤트에 `annotations.authentication.k8s.io/stale-token`으로 주석을 추가합니다. 주석의 값은 다음 예와 유사합니다.

```
subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.
```

클러스터에 [컨트롤 플레인 로깅](control-plane-logs.md)이 사용 설정되어 있는 경우 주석은 감사 로그에 있습니다. 다음과 같은 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 쿼리를 사용하여 Amazon EKS 클러스터에서 오래된 토큰을 사용하는 모든 포드를 식별할 수 있습니다.

```
fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime
```

`subject`는 포드가 사용한 서비스 계정을 참조합니다. `elapsedtime`은 최신 토큰을 읽은 후 경과 시간(초)을 표시합니다. API 서버에 대한 요청은 `elapsedtime`이 90일(7,776,000 초)을 초과하는 경우, 거부됩니다. 이전에 나열된 버전 중 하나를 사용하여 토큰을 자동으로 새로 고치도록 하려면 애플리케이션의 Kubernetes 클라이언트 SDK를 적극적으로 업데이트해야 합니다. 사용된 서비스 계정 토큰이 90일에 가까우며 토큰 만료 전에 클라이언트 SDK 버전을 업데이트할 시간이 충분하지 않은 경우 기존 포드를 종료하고 새 포드를 생성할 수 있습니다. 이로 인해 서비스 계정 토큰을 다시 가져와서 클라이언트 버전 SDK를 업데이트하는 데 추가로 90일이 제공됩니다.

포드가 배포의 일부인 경우 고가용성을 유지하면서 포드를 종료하라고 제안된 방법은 다음 명령으로 롤아웃을 수행하는 것입니다. *my-deployment*를 배포 이름으로 바꿉니다.

```
kubectl rollout restart deployment/my-deployment
```

## 클러스터 추가 기능
<a name="boundserviceaccounttoken-validated-add-on-versions"></a>

다음 클러스터 추가 기능은 Kubernetes 클라이언트 SDK를 사용하여 서비스 계정 토큰을 자동으로 다시 가져오도록 업데이트되었습니다. 나열된 버전 또는 이후 버전이 클러스터에 설치되었는지 확인하는 것이 좋습니다.
+ Kubernetes용 Amazon VPC CNI 플러그인 및 지표 헬퍼 플러그인 버전 `1.8.0` 이상. 현재 버전을 확인하거나 업데이트하려면 [Amazon VPC CNI를 통해 포드에 IP 할당](managing-vpc-cni.md) 및 [cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md) 부분을 참조하세요.
+ CoreDNS 버전 `1.8.4` 이상. 현재 버전을 확인하거나 업데이트하려면 [Amazon EKS 클러스터에서 DNS에 대한 CoreDNS 관리](managing-coredns.md) 부분을 참조하세요.
+  AWS Load Balancer Controller 버전 `2.0.0` 이상. 현재 버전을 확인하거나 업데이트하려면 [AWS 로드 밸런서 컨트롤러를 통해 인터넷 트래픽 라우팅](aws-load-balancer-controller.md) 부분을 참조하세요.
+ 현재 `kube-proxy` 버전 현재 버전을 확인하거나 업데이트하려면 [Amazon EKS 클러스터에서 `kube-proxy` 관리](managing-kube-proxy.md) 부분을 참조하세요.
+  AWS for Fluent Bit 버전 `2.25.0` 이상. 현재 버전을 업데이트하려면 GitHub의 [릴리스](https://github.com/aws/aws-for-fluent-bit/releases)를 참조하세요.
+ Fluentd 이미지 버전 [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) 이상 및 Kubernetes 메타데이터 버전 [2.11.1](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/2.11.1) 이상용 Fluentd 필터 플러그인.

## Amazon Elastic Kubernetes Service 클러스터의 워크로드에 AWS ID 및 액세스 관리 권한 부여
<a name="service-accounts-iam"></a>

Amazon EKS는 *서비스 계정에 대한 IAM 역할* 및 *EKS Pod Identity*를 통해 Amazon EKS 클러스터에서 실행되는 워크로드에 AWS ID 및 액세스 관리 권한을 부여합니다.

 **서비스 계정에 대한 IAM 역할**   
 *서비스 계정에 대한 IAM 역할(IRSA)*은 세분화된 IAM 권한으로 AWS에서 실행되는 Kubernetes 애플리케이션을 구성하여 Amazon S3 버킷, Amazon DynamoDB 테이블 등과 같은 다양한 기타 AWS 리소스에 액세스할 수 있도록 합니다. 동일한 Amazon EKS 클러스터에서 여러 애플리케이션을 함께 실행하고 각 애플리케이션이 필요한 최소 권한 집합만 갖도록 할 수 있습니다. IRSA는 Amazon EKS, Amazon EKS Anywhere, AWS의 Red Hat OpenShift Service, Amazon EC2 인스턴스의 자체 관리형 Kubernetes 클러스터 등 AWS에서 지원하는 다양한 Kubernetes 배포 옵션을 지원하도록 구축되었습니다. 따라서 IRSA는 IAM과 같은 기본 AWS 서비스를 사용하여 빌드되었으며 Amazon EKS 서비스 및 EKS API에 대한 직접적인 종속성을 갖지 않았습니다. 자세한 내용은 [서비스 계정에 대한 IAM 역할](iam-roles-for-service-accounts.md) 섹션을 참조하세요.

 **EKS Pod Identity**   
EKS Pod Identity는 클러스터 관리자에게 Amazon S3 버킷, Amazon DynamoDB 테이블 등과 같은 다양한 기타 AWS 리소스에 액세스할 수 있도록 간소화된 애플리케이션 인증 워크플로를 제공합니다. EKS Pod Identity는 EKS 전용이므로 클러스터 관리자가 IAM 권한을 획득하도록 Kubernetes 애플리케이션을 구성하는 방법이 간소화됩니다. 이제 AWS Management Console, EKS API, AWS CLI를 통해 직접 몇 단계만 거치면 이러한 권한을 쉽게 구성할 수 있으며, 임의의 Kubernetes 객체에 있는 클러스터 내에서 별도의 조치를 취하지 않아도 됩니다. 클러스터 관리자는 EKS와 IAM 서비스 간에 전환하거나 권한이 있는 IAM 작업을 사용하여 애플리케이션에 필요한 권한을 구성할 필요가 없습니다. 이제 새 클러스터를 생성할 때 역할 신뢰 정책을 업데이트할 필요 없이 여러 클러스터에서 IAM 역할을 사용할 수 있습니다. EKS Pod Identity에서 제공하는 IAM 보안 인증 정보에는 클러스터 이름, 네임스페이스, 서비스 계정 이름 등의 속성이 포함된 역할 세션 태그가 포함됩니다. 관리자는 역할 세션 태그를 사용하여 일치하는 태그를 기반으로 AWS 리소스에 대한 액세스를 허용하여 여러 서비스 계정에서 작업할 수 있는 단일 역할을 작성할 수 있습니다. 자세한 내용은 [EKS Pod Identity가 포드에 AWS 서비스에 대한 액세스 권한을 부여하는 방법 알아보기](pod-identities.md) 섹션을 참조하세요.

### EKS Pod Identity와 IRSA 비교
<a name="service-accounts-iam-compare"></a>

대략적으로 EKS Pod Identity와 IRSA 모두 Kubernetes 클러스터에서 실행되는 애플리케이션에 IAM 권한을 부여할 수 있도록 합니다. 하지만 구성 방법, 지원되는 제한 사항, 활성화된 기능 등이 근본적으로 다릅니다. 아래에서는 두 솔루션의 몇 가지 주요 측면을 비교합니다.

**참고**  
 AWS에서는 가능하면 EKS Pod Identity를 사용하여 포드에 AWS 리소스에 대한 액세스 권한을 부여할 것을 권장합니다. 자세한 내용은 [EKS Pod Identity가 포드에 AWS 서비스에 대한 액세스 권한을 부여하는 방법 알아보기](pod-identities.md) 섹션을 참조하세요.


| 속성 | EKS Pod Identity | IRSA | 
| --- | --- | --- | 
|  역할 확장성  |  새로 도입된 Amazon EKS 서비스 보안 주체 `pods.eks.amazonaws.com`과의 신뢰를 구축하려면 각 역할을 한 번 설정해야 합니다. 이 한 번의 단계를 거친 후에는 새 클러스터에서 역할이 사용될 때마다 역할의 신뢰 정책을 업데이트할 필요가 없습니다.  |  새 클러스터에서 역할을 사용할 때마다 새 EKS 클러스터 OIDC 제공자 엔드포인트로 IAM 역할의 신뢰 정책을 업데이트해야 합니다.  | 
|  클러스터 확장성  |  EKS Pod Identity의 경우 사용자가 IAM OIDC 공급자를 설정할 필요가 없으므로 이 제한은 적용되지 않습니다.  |  각 EKS 클러스터에는 OpenID Connect(OIDC) 발급자 URL이 연결되어 있습니다. IRSA를 사용하려면 IAM의 각 EKS 클러스터에 대해 고유한 OpenID Connect 제공자를 생성해야 합니다. IAM의 기본 글로벌 제한은 각 AWS 계정에 대해 100개의 OIDC 제공자입니다. IRSA가 있는 각 AWS 계정에 대해 100개를 초과하는 EKS 클러스터를 보유하려는 계획인 경우 IAM OIDC 제공자 한도에 도달합니다.  | 
|  역할 확장성  |  EKS Pod Identity의 경우 사용자가 신뢰 정책에서 IAM 역할과 서비스 계정 간의 신뢰 관계를 정의할 필요가 없으므로 이 제한은 적용되지 않습니다.  |  IRSA에서는 역할의 신뢰 정책에서 IAM 역할과 서비스 계정 간의 신뢰 관계를 정의합니다. 기본적으로 신뢰 정책 크기의 길이는 `2048`입니다. 즉, 일반적으로 단일 신뢰 정책에서 4개의 신뢰 관계를 정의할 수 있습니다. 신뢰 정책 길이 제한을 늘릴 수 있지만 일반적으로 단일 신뢰 정책 내에서 최대 8개의 신뢰 관계로 제한됩니다.  | 
|  STS API Quota 사용  |  EKS Pod Identity는 포드에 대한 AWS 자격 증명 전송을 간소화하고, 코드가 AWS Security Token Service(STS)를 직접 호출할 필요가 없습니다. EKS 서비스는 역할 수임을 처리하고, 포드가 AWS STS와 통신하거나 STS API Quota를 사용하지 않고 포드에서 AWS SDK를 사용하여 작성된 애플리케이션에 자격 증명을 제공합니다.  |  IRSA에서 포드의 AWS SDK를 사용하여 작성된 애플리케이션은 토큰을 사용하여 AWS Security Token Service(STS)에서 `AssumeRoleWithWebIdentity` API를 직접 호출합니다. AWS SDK에 있는 코드의 로직에 따라 코드에서 AWS STS를 불필요하게 호출하고 스로틀링 오류를 수신할 수 있습니다.  | 
|  역할 재사용 가능성  |   EKS Pod Identity에서 제공하는 AWS STS 보안 인증 정보에는 클러스터 이름, 네임스페이스, 서비스 계정 이름 등과 같은 역할 세션 태그가 포함됩니다. 역할 세션 태그를 사용하면 관리자는 연결된 태그를 기반으로 AWS 리소스에 대한 액세스를 허용함으로써 유효 권한이 다른 여러 서비스 계정에서 사용할 수 있는 단일 IAM 역할을 작성할 수 있습니다. 이를 속성 기반 액세스 제어(ABAC)라고 합니다. 자세한 내용은 [태그를 기반으로 포드에 AWS 리소스에 대한 액세스 권한 부여](pod-id-abac.md) 섹션을 참조하세요.  |   AWS STS 세션 태그는 지원되지 않습니다. 클러스터 간에 역할을 재사용할 수 있지만 모든 포드는 해당 역할의 모든 권한을 받습니다.  | 
|  지원되는 환경  |  EKS Pod Identity는 Amazon EKS에서만 사용할 수 있습니다.  |  IRSA는 Amazon EKS, Amazon EKS Anywhere, AWS의 Red Hat OpenShift Service, Amazon EC2 인스턴스의 자체 관리형 Kubernetes 클러스터 등에서 사용할 수 있습니다.  | 
|  지원되는 EKS 버전  |  지원되는 모든 EKS 클러스터 버전. 특정 플랫폼 버전은 [EKS Pod Identity 클러스터 버전](pod-identities.md#pod-id-cluster-versions) 섹션을 참조하세요.  |  지원되는 모든 EKS 클러스터 버전.  | 

# 서비스 계정에 대한 IAM 역할
<a name="iam-roles-for-service-accounts"></a>

**작은 정보**  
 향후 예정된 Amazon EKS 워크숍에 [등록](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)합니다.

포드의 컨테이너에 있는 애플리케이션은 AWS SDK 또는 AWS CLI를 사용하여 AWS ID 및 액세스 관리(IAM) 권한을 사용하여 AWS 서비스에 API 요청을 할 수 있다. 애플리케이션은 AWS 자격 증명으로 AWS API 요청에 서명해야 합니다. **서비스 계정에 대한 IAM 역할(IRSA)**은 Amazon EC2 인스턴스 프로파일이 Amazon EC2 인스턴스에 자격 증명을 제공하는 것과 비슷한 방식으로 애플리케이션에 대한 자격 증명을 관리하는 기능을 제공합니다. AWS 자격 증명을 생성하여 컨테이너에 배포하거나 Amazon EC2 인스턴스의 역할을 사용하는 대신에 IAM 역할을 Kubernetes 서비스 계정과 연결하고 서비스 계정을 사용하도록 포드를 구성합니다. [AWS Ouposts의 Amazon EKS에 대한 로컬 클러스터](eks-outposts-local-cluster-overview.md)가 있는 서비스 계정에는 IAM 역할을 사용할 수 없습니다.

서비스 계정의 IAM 역할을 통해 다음과 같은 이점을 누릴 수 있습니다.
+  **최소 권한** – IAM 권한의 범위를 서비스 계정으로 지정할 수 있습니다. 그러면 해당 서비스 계정을 사용하는 포드만 이 권한에 액세스할 수 있습니다. 또한 이 기능을 사용하면 `kiam`, `kube2iam` 같은 타사 솔루션이 필요 없습니다.
+  **자격 증명 격리** - [Amazon EC2 인스턴스 메타데이터 서비스(IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)에 대한 액세스가 제한되면 포드의 컨테이너는 컨테이너가 사용하는 서비스 계정과 연결된 IAM 역할에 대한 자격 증명만 검색할 수 있습니다. 컨테이너는 다른 포드의 다른 컨테이너에서 사용하는 자격 증명에 액세스할 수 없습니다. IMDS가 제한되지 않으면 포드의 컨테이너도 [Amazon EKS 노드 IAM 역할](create-node-role.md)에 액세스할 수 있으며 컨테이너는 동일한 노드에 있는 다른 포드의 IAM 역할 자격 증명에 액세스할 수도 있습니다. 자세한 내용은 [작업자 노드에 할당된 인스턴스 프로필에 대한 액세스 제한](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations) 부분을 참조하세요.

**참고**  
`hostNetwork: true`로 구성된 포드는 항상 IMDS 액세스 권한이 있지만 AWS SDK와 CLI는 활성화된 경우 IRSA 자격 증명을 사용합니다.
+  **감사** - AWS CloudTrail을 통한 액세스 및 이벤트 로깅을 사용하여 소급적 감사를 지원합니다.

**중요**  
컨테이너는 보안 경계가 아니며, 서비스 계정에 대한 IAM 역할을 사용해도 변경되지 않습니다. 동일한 노드에 할당된 포드는 커널과 포드 구성에 따라 잠재적으로 다른 리소스를 공유하게 됩니다. 별도의 노드에서 실행되는 포드는 컴퓨팅 계층에서 격리되지만, 개별 인스턴스의 범위를 넘어서는 추가 권한이 있는 노드 애플리케이션이 Kubernetes API에 있습니다. 몇 가지 예로 `kubelet`, `kube-proxy`, CSI 스토리지 드라이버 또는 자체 Kubernetes 애플리케이션이 있습니다.

다음 절차를 완료하여 서비스 계정에 대한 IAM 역할을 활성화합니다.

1.  [클러스터에 대한 IAM OIDC 제공자 만들기](enable-iam-roles-for-service-accounts.md) - 이 절차는 각 클러스터에 대해 한 번만 완료합니다.
**참고**  
EKS VPC 엔드포인트를 활성화한 경우 해당 VPC 내에서 EKS OIDC 서비스 엔드포인트에 액세스할 수 없습니다. 따라서 VPC에서 `eksctl`을 통해 OIDC 공급자를 생성하는 등의 작업은 작동하지 않으며 `https://oidc.eks.region.amazonaws.com` 요청을 시도할 때 시간 초과가 발생합니다. 오류 메시지의 예는 다음과 같습니다.  

   ```
   server cant find oidc.eks.region.amazonaws.com: NXDOMAIN
   ```
이 단계를 완료하려면 VPC 외부(예: AWS CloudShell 또는 인터넷에 연결된 컴퓨터)에서 명령을 실행할 수 있습니다. 또는 VPC에서 Route 53 Resolver와 같은 분할-수평 조건부 확인자를 생성하여 OIDC 발급자 URL에 대해 다른 확인자를 사용하고 VPC DNS를 사용하지 않을 수 있습니다. CoreDNS의 조건부 전달의 예는 GitHub의 [Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038)를 참조하세요.

1.  [Kubernetes 서비스 계정에 IAM 역할 할당](associate-service-account-role.md) - 애플리케이션이 갖길 원하는 각 고유 권한 집합에 대해 이 절차를 완료합니다.

1.  [Kubernetes 서비스 계정을 사용하도록 포드 구성](pod-configuration.md) - AWS 서비스에 액세스해야 하는 각 포드에 대해 이 절차를 완료합니다.

1.  [AWS SDK와 함께 IRSA 사용](iam-roles-for-service-accounts-minimum-sdk.md) - 워크로드가 지원되는 버전의 AWS SDK를 사용하고 있는지, 워크로드가 기본 자격 증명 체인을 사용하는지 확인합니다.

## IAM, Kubernetes 및 OpenID Connect(OIDC) 백그라운드 정보
<a name="irsa-oidc-background"></a>

2014년에 AWS Identity and Access Management는 OpenID Connect(OIDC)를 사용하여 페더레이션 ID에 대한 지원을 추가했습니다. 이 기능을 사용하면 지원되는 자격 증명 공급자를 이용해 AWS API 직접 호출을 인증하고 유효한 OIDC JSON 웹 토큰(JWT)을 수신할 수 있습니다. 이 토큰을 AWS STS `AssumeRoleWithWebIdentity` API 작업에 전달하고 IAM 임시 역할 자격 증명을 수신할 수 있습니다. 이 자격 증명을 사용하여 Amazon S3 및 DynamoDB와 같은 AWS 서비스와 상호 작용할 수 있습니다.

각 JWT 토큰은 서명 키 페어로 서명됩니다. 키는 Amazon EKS에서 관리하는 OIDC 공급자가 제공하며 프라이빗 키는 7일마다 교체됩니다. Amazon EKS는 퍼블릭 키를 만료될 때까지 보관합니다. 외부 OIDC 클라이언트를 연결하는 경우 퍼블릭 키가 만료되기 전에 서명 키를 갱신해야 합니다. [서명 키를 가져와서 OIDC 토큰을 검증](irsa-fetch-keys.md)하는 방법을 알아봅니다.

Kubernetes는 서비스 계정을 자체 내부 자격 증명 시스템으로 오랫동안 사용해 왔습니다. 포드는 Kubernetes API 서버에서만 검증할 수 있는 자동으로 마운트되는 토큰(OIDC JWT는 아니었음)을 사용하는 Kubernetes API 서버를 통해 인증을 할 수 있습니다. 이러한 레거시 서비스 계정 토큰은 만료되지 않으며, 서명 키를 교체하려면 까다로운 프로세스를 거쳐야 합니다. Kubernetes 버전 `1.12`에서 새로운 `ProjectedServiceAccountToken` 기능에 대한 지원이 추가되었습니다. 이 기능은 서비스 계정 ID도 포함된 OIDC JSON 웹 토큰이며 구성 가능한 대상을 지원합니다.

Amazon EKS는 `ProjectedServiceAccountToken` JSON 웹 토큰에 대한 서명 키가 포함된 각 클러스터에 대한 퍼블릭 OIDC 검색 엔드포인트를 호스팅하므로 IAM과 같은 외부 시스템이 Kubernetes에서 발급한 OIDC 토큰을 확인하고 수락할 수 있습니다.

# 클러스터에 대한 IAM OIDC 공급자 생성
<a name="enable-iam-roles-for-service-accounts"></a>

클러스터에는 [OpenID Connect](https://openid.net/connect/)(OIDC) 발급자 URL이 연결되어 있습니다. 서비스 계정에 AWS Identity and Access Management(IAM) 역할을 사용하려면 클러스터의 OIDC 발급자 URL에 IAM OIDC 제공자가 있어야 합니다.

## 사전 조건
<a name="_prerequisites"></a>
+ 기존 Amazon EKS 클러스터. 배포하려면 [Amazon EKS 시작하기](getting-started.md) 섹션을 참조하세요.
+ 장치에 설치 및 구성된 AWS 명령줄 인터페이스(AWS CLI)의 버전 `2.12.3` 이상 또는 버전 `1.27.160` 이상 또는 AWS CloudShell. 현재 버전을 확인하려면 `aws --version | cut -d / -f2 | cut -d ' ' -f1`을 사용합니다. `yum`, `apt-get` 또는 macOS용 Homebrew와 같은 패키지 관리자는 최신 버전의 AWS CLI 이전에 나온 버전이 몇 가지 있을 때도 있습니다. 최신 버전을 설치하려면 * AWS 명령줄 인터페이스 사용 설명서*에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요. AWS CloudShell에 설치된 AWS CLI 버전도 최신 버전보다 여러 버전 이전일 수도 있습니다. 업데이트하려면 * AWS CloudShell 사용 설명서*의 [홈 디렉터리에 AWS CLI 설치하기](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)를 참조하세요.
+ `kubectl` 명령줄 도구는 장치 또는 AWS CloudShell에 설치됩니다. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. 예를 들어, 클러스터 버전이 `1.29`인 경우 `kubectl` 버전 `1.28`, `1.29` 또는 `1.30`를 함께 사용할 수 있습니다. `kubectl`을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 부분을 참조하세요.
+ 클러스터 구성이 포함된 기존 `kubectl` `config` 파일입니다. `kubectl` `config` 파일을 생성하려면 [Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결](create-kubeconfig.md) 섹션을 참조하세요.

`eksctl` 또는 AWS Management Console을 사용하여 클러스터에 대한 IAM OIDC 제공자를 생성할 수 있습니다.

## OIDC 공급자 생성(eksctl)
<a name="_create_oidc_provider_eksctl"></a>

1. 장치에 설치된 `eksctl` 명령줄 도구의 버전 `0.215.0` 이상 또는 AWS CloudShell이 필요합니다. `eksctl`을 설치 또는 업그레이드하려면 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요.

1. 클러스터의 OIDC 발행자 ID를 판단합니다.

   클러스터의 OIDC 발행자 ID를 검색하고 변수에 저장합니다. `<my-cluster>`을 사용자의 고유한 값으로 교체합니다.

   ```
   cluster_name=<my-cluster>
   oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
   echo $oidc_id
   ```

1. 클러스터의 발행자 ID를 가진 IAM OIDC 제공자가 이미 계정에 있는지 판단합니다.

   ```
   aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
   ```

   출력이 반환되면 클러스터에 대한 IAM OIDC 제공자가 이미 있는 것이므로 다음 단계를 건너뛸 수 있습니다. 출력이 반환되지 않은 경우 해당 클러스터에 대한 IAM OIDC 공급자를 생성해야 합니다.

1. 다음 명령을 사용하여 클러스터의 IAM OIDC ID 공급자를 생성합니다.

   ```
   eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve
   ```
**참고**  
EKS VPC 엔드포인트를 활성화한 경우 해당 VPC 내에서 EKS OIDC 서비스 엔드포인트에 액세스할 수 없습니다. 그에 따라 VPC에서 `eksctl`을 통해 OIDC 공급자를 생성하는 등의 작업은 작동하지 않으며 시간 초과가 발생합니다. 오류 메시지의 예는 다음과 같습니다.  

   ```
   ** server cant find oidc.eks.<region-code>.amazonaws.com: NXDOMAIN
   ```

   이 단계를 완료하려면 VPC 외부(예: AWS CloudShell 또는 인터넷에 연결된 컴퓨터)에서 명령을 실행할 수 있습니다. 또는 VPC에서 Route 53 Resolver와 같은 분할-수평 조건부 확인자를 생성하여 OIDC 발급자 URL에 대해 다른 확인자를 사용하고 VPC DNS를 사용하지 않을 수 있습니다. CoreDNS의 조건부 전달의 예는 GitHub의 [Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038)를 참조하세요.

## OIDC 공급자 생성(AWS 콘솔)
<a name="create_oidc_provider_shared_aws_console"></a>

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

1. 왼쪽 창에서 **클러스터**를 선택한 다음 **클러스터** 페이지에서 클러스터 이름을 선택합니다.

1. **개요** 탭의 **세부 정보** 섹션에서 **OpenID Connect 공급자 URL**의 값을 적어 둡니다.

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

1. 왼쪽 탐색 창의 **액세스 관리**에서 **자격 증명 공급자**를 선택합니다. 클러스터의 URL과 일치하는 **공급자**가 목록에 있으면 클러스터에 대한 공급자가 이미 있는 것입니다. 클러스터의 URL과 일치하는 공급자가 나열되지 않는 경우 공급자를 생성해야 합니다.

1. 공급자를 생성하려면 **공급자 추가**를 선택합니다.

1. **제공업체 유형**에서 **OpenID Connect**를 선택합니다.

1. **공급자 URL**에 클러스터의 OIDC 제공자 URL을 입력합니다.

1. **대상**에 `sts.amazonaws.com`을 입력합니다.

1. (선택사항) 원하는 태그(예: 이 공급자의 클러스터를 식별하는 태그)를 추가합니다.

1. **공급자 추가**를 선택합니다.

다음 단계: [Kubernetes 서비스 계정에 IAM 역할 할당](associate-service-account-role.md) 

# Kubernetes 서비스 계정에 IAM 역할 할당
<a name="associate-service-account-role"></a>

이 주제에서는 Kubernetes 서비스 계정이 AWS Identity and Access Management(IAM) 역할을 수임하도록 구성하는 방법에 대해 설명합니다. 서비스 계정을 사용하도록 구성된 모든 포드는 해당 역할에 액세스 권한이 있는 모든 AWS 서비스에 액세스할 수 있습니다.

## 사전 조건
<a name="_prerequisites"></a>
+ 기존 클러스터가 있어야 합니다. 아직 없는 경우 [Amazon EKS 시작하기](getting-started.md) 안내서 중 하나에 따라 생성할 수 있습니다.
+ 클러스터에 대한 기존 IAM OpenID Connect(OIDC) 공급자. 이미 있는지 확인하거나 생성하는 방법을 알아보려면 [클러스터에 대한 IAM OIDC 공급자 생성](enable-iam-roles-for-service-accounts.md) 섹션을 참조하세요.
+ 장치에 설치 및 구성된 AWS 명령줄 인터페이스(AWS CLI)의 버전 `2.12.3` 이상 또는 버전 `1.27.160` 이상 또는 AWS CloudShell. 현재 버전을 확인하려면 `aws --version | cut -d / -f2 | cut -d ' ' -f1`을 사용합니다. `yum`, `apt-get` 또는 macOS용 Homebrew와 같은 패키지 관리자는 최신 버전의 AWS CLI 이전에 나온 버전이 몇 가지 있을 때도 있습니다. 최신 버전을 설치하려면 * AWS 명령줄 인터페이스 사용 설명서*에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요. AWS CloudShell에 설치된 AWS CLI 버전도 최신 버전보다 여러 버전 이전일 수도 있습니다. 업데이트하려면 * AWS CloudShell 사용 설명서*의 [홈 디렉터리에 AWS CLI 설치하기](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)를 참조하세요.
+ `kubectl` 명령줄 도구는 장치 또는 AWS CloudShell에 설치됩니다. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. 예를 들어, 클러스터 버전이 `1.29`인 경우 `kubectl` 버전 `1.28`, `1.29` 또는 `1.30`를 함께 사용할 수 있습니다. `kubectl`을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 부분을 참조하세요.
+ 클러스터 구성이 포함된 기존 `kubectl` `config` 파일입니다. `kubectl` `config` 파일을 생성하려면 [Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결](create-kubeconfig.md) 섹션을 참조하세요.

## 1단계: IAM 정책 생성
<a name="irsa-associate-role-procedure"></a>

IAM 역할에 기존 IAM 정책을 연결하려면 다음 단계로 건너뜁니다.

1. IAM 정책을 생성합니다. 자체 정책을 생성하거나 필요한 권한 중 일부를 이미 부여하는 AWS 관리형 정책을 복사하여 특정 요구 사항에 맞게 사용자 지정할 수 있습니다. 자세한 내용은 **IAM 사용 설명서에서 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)을 참조하세요.

1. 포드가 액세스할 AWS 서비스에 대한 권한이 포함된 파일을 생성합니다. 모든 AWS 서비스에 대한 모든 작업 목록은 [서비스 승인 참조](https://docs.aws.amazon.com/service-authorization/latest/reference/)에서 확인하세요.

   다음 명령을 실행하여 Amazon S3 버킷에 대한 읽기 전용 액세스를 허용하는 예제 정책 파일을 생성할 수 있습니다. 이 버킷에 구성 정보 또는 부트스트랩 스크립트를 저장할 수도 있고, 의 컨테이너는 이 버킷에서 파일을 읽어 애플리케이션으로 로드할 수 있습니다. 이 예제 정책을 생성하려면 다음 내용을 디바이스에 복사합니다. *my-pod-secrets-bucket*을 버킷 이름으로 바꾸고 명령을 실행합니다.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

1. IAM 정책을 생성합니다.

   ```
   aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
   ```

## 2단계: IAM 역할 생성 및 연결
<a name="_step_2_create_and_associate_iam_role"></a>

IAM 역할을 생성하고 Kubernetes 서비스 계정에 연결합니다. `eksctl` 또는 AWS CLI를 사용할 수 있습니다.

### 역할 생성 및 연결(eksctl)
<a name="_create_and_associate_role_eksctl"></a>

이 `eksctl` 명령은 지정된 네임스페이스에 Kubernetes 서비스 계정을 생성하고, 지정된 이름으로 IAM 역할(존재하지 않는 경우)을 생성하고, 역할에 기존 IAM 정책 ARN을 연결하고, 서비스 계정에 IAM 역할 ARN을 주석으로 추가합니다. 이 명령의 샘플 자리 표시자 값을 구체적 값으로 바꿔야 합니다. `eksctl`을 설치 또는 업그레이드하려면 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요.

```
eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name my-role \
    --attach-policy-arn arn:aws:iam::111122223333:policy/my-policy --approve
```

**중요**  
역할 또는 서비스 계정이 이미 있는 경우 이전 명령이 실패할 수 있습니다. `eksctl`에는 이러한 상황에서 제공할 수 있는 다양한 옵션이 있습니다. 자세한 내용을 알아보려면 `eksctl create iamserviceaccount --help`를 실행하세요.

### 역할 생성 및 연결(AWS CLI)
<a name="create_and_associate_role_shared_aws_cli"></a>

IAM 역할을 수임하려는 기존 Kubernetes 서비스 계정이 있는 경우 이 단계를 건너뛸 수 있습니다.

1. Kubernetes 서비스 계정을 생성합니다. 다음 콘텐츠를 디바이스에 복사합니다. *my-service-account*를 원하는 이름으로 바꾸고 필요한 경우 *기본*을 다른 네임스페이스로 바꿉니다. *기본*을 변경하는 경우, 네임스페이스가 이미 존재해야 합니다.

   ```
   cat >my-service-account.yaml <<EOF
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-service-account
     namespace: default
   EOF
   kubectl apply -f my-service-account.yaml
   ```

1. 다음 명령을 사용해 AWS 계정 ID를 환경 변수로 설정합니다.

   ```
   account_id=$(aws sts get-caller-identity --query "Account" --output text)
   ```

1. 다음 명령을 사용해 클러스터의 OIDC ID 제공업체를 환경 변수로 설정합니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.

   ```
   oidc_provider=$(aws eks describe-cluster --name my-cluster --region $AWS_REGION --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")
   ```

1. 서비스 계정의 네임스페이스 및 이름에 대한 변수를 설정합니다. *my-service-account*를 역할을 수임할 Kubernetes 서비스 계정으로 바꿉니다. *기본*을 서비스 계정의 네임스페이스로 바꿉니다.

   ```
   export namespace=default
   export service_account=my-service-account
   ```

1. 다음 명령을 실행하여 IAM 역할에 대한 신뢰 정책 파일을 생성합니다. 네임스페이스 내의 모든 서비스 계정이 역할을 사용하도록 허용하려면 다음 내용을 디바이스에 복사합니다. *StringEquals*를 `StringLike`로 바꾸고 *\$1service\$1account*를 `*`로 바꿉니다. 여러 서비스 계정 또는 네임스페이스가 역할을 수임할 수 있도록 `StringEquals` 또는 `StringLike` 조건에 여러 항목을 추가할 수 있습니다. 클러스터가 속한 계정과 다른 AWS 계정의 역할이 역할을 수임하도록 허용하려면 [IRSA를 사용하여 다른 계정에 인증](cross-account-access.md) 섹션에서 자세한 내용을 참조하세요.

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "arn:aws:iam::123456789012:oidc-provider/$oidc_provider"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "$oidc_provider:aud": "sts.amazonaws.com",
             "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
           }
         }
       }
     ]
   }
   ```

1. 역할을 생성합니다. *my-role*을 IAM 역할의 이름으로 바꾸고, *my-role-description*을 역할에 대한 설명으로 바꿉니다.

   ```
   aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
   ```

1. 역할에 IAM 정책을 연결합니다. *my-role*을 IAM 역할의 이름으로 바꾸고 *my-policy*를 생성한 기존 정책의 이름으로 바꿉니다.

   ```
   aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws:iam::$account_id:policy/my-policy
   ```

1. 서비스 계정이 수임할 IAM 역할의 Amazon 리소스 이름(ARN)을 서비스 계정에 주석으로 답니다. *my-role*을 기존 IAM 역할의 이름으로 바꿉니다. 클러스터가 속한 계정과 다른 AWS 계정의 역할이 이전 단계에서 역할을 수임하도록 허용했다고 가정합니다. 그런 다음 AWS 계정과 다른 계정의 역할을 지정해야 합니다. 자세한 내용은 [IRSA를 사용하여 다른 계정에 인증](cross-account-access.md) 섹션을 참조하세요.

   ```
   kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role
   ```

1. (선택 사항) [서비스 계정에 대한 AWS Security Token Service 엔드포인트를 구성합니다.](configure-sts-endpoint.md) AWS는 글로벌 엔드포인트 대신 리전 AWS STS 엔드포인트를 사용할 것을 권장합니다. 이렇게 하면 지연 시간이 줄고, 중복성이 기본 제공되고, 세션 토큰 유효성이 향상됩니다.

## 3단계: 구성 확인
<a name="irsa-confirm-role-configuration"></a>

1. IAM 역할의 신뢰 정책이 올바르게 구성되었는지 확인합니다.

   ```
   aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
   ```

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

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
               },
               "Action": "sts:AssumeRoleWithWebIdentity",
               "Condition": {
                   "StringEquals": {
                       "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account",
                       "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
                   }
               }
           }
       ]
   }
   ```

1. 이전 단계에서 역할에 연결한 정책이 해당 역할에 연결되었는지 확인합니다.

   ```
   aws iam list-attached-role-policies --role-name my-role --query "AttachedPolicies[].PolicyArn" --output text
   ```

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

   ```
                  arn:aws:iam::111122223333:policy/my-policy
   ```

1. 사용하려는 정책의 Amazon 리소스 이름(ARN)을 저장할 변수를 설정합니다. *my-policy*를 권한을 확인하려는 정책의 이름으로 바꿉니다.

   ```
   export policy_arn=arn:aws:iam::111122223333:policy/my-policy
   ```

1. 정책의 기본 버전을 봅니다.

   ```
   aws iam get-policy --policy-arn $policy_arn
   ```

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

   ```
   {
       "Policy": {
           "PolicyName": "my-policy",
           "PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
           "Arn": "arn:aws:iam::111122223333:policy/my-policy",
           "Path": "/",
           "DefaultVersionId": "v1",
           [...]
       }
   }
   ```

1. 정책 내용을 보고 포드에 필요한 모든 권한이 정책에 포함되어 있는지 확인합니다. 필요한 경우 다음 명령에서 *1*을 이전 출력에서 반환된 버전으로 바꿉니다.

   ```
   aws iam get-policy-version --policy-arn $policy_arn --version-id v1
   ```

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

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

   이전 단계에서 예제 정책을 생성한 경우 출력은 동일합니다. 다른 정책을 생성한 경우 *예제* 내용이 다릅니다.

1. Kubernetes 서비스 계정에 역할이 주석으로 달렸는지 확인합니다.

   ```
   kubectl describe serviceaccount my-service-account -n default
   ```

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

   ```
   Name:                my-service-account
   Namespace:           default
   Annotations:         eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
   Image pull secrets:  <none>
   Mountable secrets:   my-service-account-token-qqjfl
   Tokens:              my-service-account-token-qqjfl
   [...]
   ```

## 다음 단계
<a name="_next_steps"></a>
+  [Kubernetes 서비스 계정을 사용하도록 포드 구성](pod-configuration.md) 

# Kubernetes 서비스 계정을 사용하도록 포드 구성
<a name="pod-configuration"></a>

포드가 AWS 서비스에 액세스해야 하는 경우 Kubernetes 서비스 계정을 사용하도록 구성해야 합니다. 서비스 계정은 AWS 서비스에 액세스할 수 있는 권한이 있는 AWS ID 및 액세스 관리(IAM) 역할에 연결되어야 합니다.
+ 기존 클러스터가 있어야 합니다. 아직 없는 경우 [Amazon EKS 시작하기](getting-started.md) 가이드 중 하나를 사용하여 생성할 수 있습니다.
+ 클러스터에 대한 기존 IAM OpenID Connect(OIDC) 공급자. 이미 있는지 확인하거나 생성하는 방법을 알아보려면 [클러스터에 대한 IAM OIDC 공급자 생성](enable-iam-roles-for-service-accounts.md) 섹션을 참조하세요.
+ IAM 역할과 연결된 기존 Kubernetes 서비스 계정. 서비스 계정에 IAM 역할의 Amazon 리소스 이름(ARN)을 주석으로 달아야 합니다. 포드가 AWS 서비스를 사용하는 데 필요한 권한을 포함하는 연결된 IAM 정책이 역할에 있어야 합니다. 서비스 계정 및 역할을 만들고 구성하는 방법에 대한 자세한 내용을 알아보려면 [Kubernetes 서비스 계정에 IAM 역할 할당](associate-service-account-role.md) 섹션을 참조하세요.
+ 장치에 설치 및 구성된 AWS 명령줄 인터페이스(AWS CLI)의 버전 `2.12.3` 이상 또는 버전 `1.27.160` 이상 또는 AWS CloudShell. 현재 버전을 확인하려면 `aws --version | cut -d / -f2 | cut -d ' ' -f1`을 사용합니다. `yum`, `apt-get` 또는 macOS용 Homebrew와 같은 패키지 관리자는 최신 버전의 AWS CLI 이전에 나온 버전이 몇 가지 있을 때도 있습니다. 최신 버전을 설치하려면 * AWS 명령줄 인터페이스 사용 설명서*에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요. AWS CloudShell에 설치된 AWS CLI 버전도 최신 버전보다 여러 버전 이전일 수도 있습니다. 업데이트하려면 * AWS CloudShell 사용 설명서*의 [홈 디렉터리에 AWS CLI 설치하기](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)를 참조하세요.
+ `kubectl` 명령줄 도구는 장치 또는 AWS CloudShell에 설치됩니다. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. 예를 들어, 클러스터 버전이 `1.29`인 경우 `kubectl` 버전 `1.28`, `1.29` 또는 `1.30`를 함께 사용할 수 있습니다. `kubectl`을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 부분을 참조하세요.
+ 클러스터 구성이 포함된 기존 `kubectl` `config` 파일입니다. `kubectl` `config` 파일을 생성하려면 [Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결](create-kubeconfig.md) 섹션을 참조하세요.

  1. 다음 명령을 사용하여 구성을 확인할 포드를 배포할 수 있는 배포 매니페스트를 생성합니다. 예제 값을 사용자의 값으로 바꿉니다.

     ```
     cat >my-deployment.yaml <<EOF
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: my-app
     spec:
       selector:
         matchLabels:
           app: my-app
       template:
         metadata:
           labels:
             app: my-app
         spec:
           serviceAccountName: my-service-account
           containers:
           - name: my-app
             image: public.ecr.aws/nginx/nginx:X.XX
     EOF
     ```

  1. 클러스터에 매니페스트를 배포합니다.

     ```
     kubectl apply -f my-deployment.yaml
     ```

  1. 포드에 필요한 환경 변수가 있는지 확인합니다.

     1. 이전 단계에서 배포와 함께 배포된 포드를 봅니다.

        ```
        kubectl get pods | grep my-app
        ```

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

        ```
        my-app-6f4dfff6cb-76cv9   1/1     Running   0          3m28s
        ```

     1. 포드가 사용 중인 IAM 역할의 ARN을 봅니다.

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_ROLE_ARN:
        ```

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

        ```
        AWS_ROLE_ARN:                 arn:aws:iam::111122223333:role/my-role
        ```

        역할 ARN이 기존 서비스 계정에 주석으로 단 역할 ARN과 일치해야 합니다. 서비스 계정에 주석 달기에 대한 자세한 내용을 알아보려면 [Kubernetes 서비스 계정에 IAM 역할 할당](associate-service-account-role.md) 섹션을 참조하세요.

     1. 포드에 웹 ID 토큰 파일 탑재가 있는지 확인합니다.

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_WEB_IDENTITY_TOKEN_FILE:
        ```

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

        ```
        AWS_WEB_IDENTITY_TOKEN_FILE:  /var/run/secrets/eks.amazonaws.com/serviceaccount/token
        ```

        `kubelet`은 포드를 대신하여 토큰을 요청하고 저장합니다. 기본적으로 `kubelet`은 총 TTL(Time To Live)의 80% 또는 24시간보다 오래된 토큰을 새로 고칩니다. 포드 사양의 설정을 사용하여 기본 서비스 계정을 제외한 모든 계정의 만료 기간을 수정할 수 있습니다. 자세한 내용은 Kubernetes 문서의 [서비스 계정 토큰 볼륨 예측(Service Account Token Volume Projection)](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection)을 참조하세요.

        클러스터의 [Amazon EKS Pod Identity 웹후크](https://github.com/aws/amazon-eks-pod-identity-webhook#amazon-eks-pod-identity-webhook)는 다음 주석을 이용해 서비스 계정을 사용하는 포드를 관찰합니다.

        ```
        eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
        ```

        웹후크는 이전 환경 변수를 해당 포드에 적용합니다. 클러스터는 환경 변수 및 토큰 파일 탑재를 구성하기 위해 웹후크를 사용할 필요가 없습니다. 이러한 환경 변수를 갖도록 포드를 수동으로 구성할 수 있습니다. [지원되는 AWS SDK 버전](iam-roles-for-service-accounts-minimum-sdk.md)은 자격 증명 체인 제공자에서 이 환경 변수를 먼저 찾습니다. 역할 자격 증명은 이 기준을 충족하는 포드에 사용됩니다.

  1. 역할에 연결된 IAM 정책에서 할당한 권한을 사용하여 포드가 AWS 서비스와 상호 작용할 수 있는지 확인합니다.
**참고**  
포드가 서비스 계정과 연결된 IAM 역할의 AWS 자격 증명을 사용하는 경우 해당 포드의 컨테이너에 있는 AWS CLI나 다른 SDK는 역할이 제공하는 자격 증명을 사용합니다. [Amazon EKS 노드 IAM 역할](create-node-role.md)에 제공된 자격 증명에 대한 액세스를 제한하지 않으면 포드는 계속해서 해당 자격 증명에 액세스할 수 있습니다. 자세한 내용은 [작업자 노드에 할당된 인스턴스 프로필에 대한 액세스 제한](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) 부분을 참조하세요.

     포드가 예상대로 서비스와 상호 작용할 수 없으면 다음 단계를 완료하여 모두 제대로 구성되었는지 확인합니다.

     1. 포드에서 OpenID Connect 웹 ID 토큰 파일을 통해 IAM 역할을 수임할 수 있도록 지원하는 AWS SDK 버전을 사용하는지 확인합니다. 자세한 내용은 [AWS SDK와 함께 IRSA 사용](iam-roles-for-service-accounts-minimum-sdk.md) 섹션을 참조하세요.

     1. 배포에서 서비스 계정을 사용하고 있는지 확인합니다.

        ```
        kubectl describe deployment my-app | grep "Service Account"
        ```

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

        ```
        Service Account:  my-service-account
        ```

     1. 포드가 여전히 서비스에 액세스할 수 없는 경우 [IAM 역할을 쿠버네티스 서비스 계정에 할당하기](associate-service-account-role.md)에 설명된 [단계](associate-service-account-role.md#irsa-confirm-role-configuration)를 검토하여 역할과 서비스 계정이 올바르게 구성되었는지 확인합니다.

# 서비스 계정의 AWS 보안 토큰 서비스 엔드포인트 구성
<a name="configure-sts-endpoint"></a>

[서비스 계정에 대한 IAM 역할](iam-roles-for-service-accounts.md)이 포함된 Kubernetes 서비스 계정을 사용하는 경우 Kubernetes 서비스 계정에서 사용하는 AWS Security Token Service 엔드포인트 유형을 구성할 수 있습니다.

 AWS는 글로벌 엔드포인트 대신 리전별 AWS STS 엔드포인트를 사용할 것을 권장합니다. 이렇게 하면 지연 시간이 줄고, 중복성이 기본 제공되고, 세션 토큰 유효성이 향상됩니다. AWS Security Token Service는 포드가 실행 중인 AWS 리전에서 활성 상태여야 합니다. 또한 AWS 리전에서 서비스 장애가 발생할 경우 다른 AWS 리전에 대한 기본 제공 중복성이 애플리케이션에 있어야 합니다. 자세한 내용은 IAM 사용 설명서의 [AWS 리전에서 AWS STS 관리](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)를 참조하세요.
+ 기존 클러스터가 있어야 합니다. 아직 없는 경우 [Amazon EKS 시작하기](getting-started.md) 가이드 중 하나를 사용하여 생성할 수 있습니다.
+ 클러스터에 대한 기존 IAM OIDC 공급자입니다. 자세한 내용은 [클러스터에 대한 IAM OIDC 공급자 생성](enable-iam-roles-for-service-accounts.md) 섹션을 참조하세요.
+ [서비스 계정에 대한 Amazon EKS IAM](iam-roles-for-service-accounts.md) 기능에서 사용하도록 구성된 기존 Kubernetes 서비스 계정.

다음 예에서는 모두 [Amazon VPC CNI 플러그인](cni-iam-role.md)에서 사용하는 aws-node Kubernetes 서비스 계정을 사용합니다. *예제 값*을 고유 서비스 계정, 포드, 네임스페이스 및 기타 리소스로 바꿀 수 있습니다.

1. 엔드포인트를 변경하려는 서비스 계정을 사용하는 포드를 선택합니다. 포드가 실행되는 AWS 리전을 결정합니다. *aws-node-6mfgv*를 포드 이름으로, *kube-system*을 포드의 네임스페이스로 바꿉니다.

   ```
   kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
   ```

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

   ```
   ip-192-168-79-166.us-west-2/192.168.79.166
   ```

   이전 출력에서 포드는 us-west-2 AWS 리전의 노드에서 실행됩니다.

1. 포드의 서비스 계정이 사용 중인 엔드포인트 유형을 결정합니다.

   ```
   kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
   ```

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

   ```
   AWS_STS_REGIONAL_ENDPOINTS: regional
   ```

   현재 엔드포인트가 전역인 경우 `global`은 출력에서 반환됩니다. 출력이 반환되지 않는 경우 기본 엔드포인트 유형이 재정의되지 않고 사용 중에 있습니다.

1. 클러스터 또는 플랫폼 버전이 표에 나열된 버전과 동일하거나 이후인 경우 다음 명령 중 하나를 사용하여 서비스 계정에서 사용하는 엔드포인트 유형을 기본 유형에서 다른 유형으로 변경할 수 있습니다. *aws-node*를 서비스 계정의 이름으로, *kube-system*을 서비스 계정의 네임스페이스로 바꿉니다.
   + 기본 또는 현재 엔드포인트 유형이 전역이고 다음과 같은 리전으로 변경하려는 경우:

     ```
     kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
     ```

     [서비스 계정에 대한 IAM 역할](iam-roles-for-service-accounts.md)을 사용하여 포드 컨테이너에서 실행 중인 애플리케이션에서 사전 서명된 S3 URL을 생성하는 경우 리전 엔드포인트의 URL 형식은 다음 예제와 유사합니다.

     ```
     https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
     ```
   + 기본 또는 현재 엔드포인트 유형이 리전이고 다음과 같은 전역으로 변경하려는 경우:

     ```
     kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
     ```

     애플리케이션이 AWS STS 글로벌 엔드포인트에 명시적으로 요청하고 Amazon EKS 클러스터에서 리전 엔드포인트를 사용하는 기본 동작을 재정의하지 않는 경우 오류로 인해 요청이 실패합니다. 자세한 내용은 [포드 컨테이너는 다음과 같은 오류가 발생합니다. `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`](security-iam-troubleshoot.md#security-iam-troubleshoot-wrong-sts-endpoint) 섹션을 참조하세요.

     [서비스 계정에 대한 IAM 역할](iam-roles-for-service-accounts.md)을 사용하여 포드 컨테이너에서 실행 중인 애플리케이션에서 사전 서명된 S3 URL을 생성하는 경우 글로벌 엔드포인트의 URL 형식은 다음 예제와 유사합니다.

     ```
     https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
     ```

   사전 서명된 URL을 특정 형식으로 예상하는 자동화가 있거나 사전 서명된 URL을 사용하는 애플리케이션 또는 다운스트림 종속성이 대상 지정된 AWS 리전을 예상하는 경우, 필요한 변경을 수행하여 적절한 AWS STS 엔드포인트를 사용합니다.

1. 서비스 계정에 연결된 기존 포드를 삭제하고 다시 생성하여 자격 증명 환경 변수를 적용합니다. 변형 웹후크는 이미 실행 중인 포드에 이 변수를 적용하지 않습니다. *Pods*, *kube-system* 및 *-l k8s-app=aws-node*를 주석을 설정한 포드에 대한 정보로 바꿀 수 있습니다.

   ```
   kubectl delete Pods -n kube-system -l k8s-app=aws-node
   ```

1. 모든 포드가 다시 시작되었는지 확인합니다.

   ```
   kubectl get Pods -n kube-system -l k8s-app=aws-node
   ```

1. 포드 중 하나에 대한 환경 변수를 봅니다. `AWS_STS_REGIONAL_ENDPOINTS` 값이 이전 단계에서 설정한 값인지 확인합니다.

   ```
   kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
   ```

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

   ```
   AWS_STS_REGIONAL_ENDPOINTS=regional
   ```

# IRSA를 사용하여 다른 계정에 인증
<a name="cross-account-access"></a>

다른 계정의 클러스터에서 ID 공급자를 생성하거나 연결된 `AssumeRole` 작업을 사용하여 크로스 계정 IAM 권한을 구성할 수 있습니다. 다음 예에서 *계정 A*는 서비스 계정에 대해 IAM 역할을 지원하는 Amazon EKS 클러스터를 소유합니다. 이 클러스터에서 실행되는 포드는 *계정 B*의 IAM 권한을 수임해야 합니다.
+  **옵션 1**은 더 간단하지만 계정 B가 계정 A의 클러스터에 대한 OIDC ID 제공업체를 생성하고 관리해야 합니다.
+  **옵션 2**는 계정 A에서 OIDC 관리를 유지하지만 두 번의 `AssumeRole` 직접 호출을 통해 역할을 연결해야 합니다.

## 옵션 1: 다른 계정의 클러스터에서 ID 제공업체 생성
<a name="_option_1_create_an_identity_provider_from_another_accounts_cluster"></a>

이 예제에서 계정 A는 계정 B에 클러스터의 OpenID Connect(OIDC) 발행자 URL을 제공합니다. 계정 B는 계정 A의 클러스터에서 OIDC 발급자 URL을 사용하여 [클러스터에 대한 IAM OIDC 제공자 만들기](enable-iam-roles-for-service-accounts.md) 및 [Kubernetes 서비스 계정에 IAM 역할 할당](associate-service-account-role.md)의 지침을 따릅니다. 그런 다음 클러스터 관리자는 계정 B(*444455556666*)의 역할을 사용할 계정 A의 클러스터에 있는 서비스 계정에 주석을 답니다.

```
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role
```

## 옵션 2: 연결된 `AssumeRole` 작업 사용
<a name="_option_2_use_chained_assumerole_operations"></a>

이 접근 방식에서 각 계정은 IAM 역할을 생성합니다. 계정 B의 역할은 계정 A를 신뢰하고 계정 A의 역할은 OIDC 페더레이션을 사용하여 클러스터에서 자격 증명을 가져옵니다. 그런 다음 포드는 AWS CLI 프로파일을 사용하여 두 역할을 함께 연결합니다.

### 1단계: 계정 B에서 대상 역할 생성
<a name="_step_1_create_the_target_role_in_account_b"></a>

계정 B(*444455556666*)는 계정 A의 클러스터에 있는 포드에 필요한 권한을 가진 IAM 역할을 생성합니다. 계정 B는 원하는 권한 정책을 이 역할에 연결한 후 다음 신뢰 정책을 추가합니다.

 **계정 B의 역할에 대한 신뢰 정책** - 이 정책은 계정 A의 특정 IRSA 역할이 이 역할을 수임하도록 허용합니다.

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}
```

**중요**  
최소 권한을 위해 계정 루트(`arn:aws:iam::111122223333:root`)를 사용하는 대신 `Principal` ARN을 계정 A의 특정 역할 ARN으로 바꿉니다. 계정 루트를 사용하면 계정 A의 *모든* IAM 위탁자가 이 역할을 수임할 수 있습니다.

### 2단계: 계정 A에서 IRSA 역할 생성
<a name="_step_2_create_the_irsa_role_in_account_a"></a>

계정 A(*111122223333*)는 클러스터의 OIDC 발행자 주소로 생성된 ID 제공업체의 자격 증명을 가져오는 신뢰 정책을 이용해 역할을 생성합니다.

 **계정 A의 역할에 대한 신뢰 정책(OIDC 페더레이션)** - 이 정책은 EKS 클러스터의 OIDC 공급자가 이 역할에 대한 자격 증명을 발급하도록 허용합니다.

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}
```

**중요**  
최소 권한을 위해 이 역할을 특정 Kubernetes 서비스 계정으로 제한하도록 `sub` 클레임에 대한 `StringEquals` 조건을 추가합니다. `sub` 조건이 없으면 클러스터의 모든 서비스 계정이 이 역할을 수임할 수 있습니다. `sub` 값은 `system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME ` 형식을 사용합니다. 예를 들어 `default` 네임스페이스에 이름이 `my-service-account`인 서비스 계정으로 제한하려면 다음을 사용합니다.  

```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```

### 3단계: 계정 A의 역할에 AssumeRole 권한 연결
<a name="_step_3_attach_the_assumerole_permission_to_account_as_role"></a>

계정 A는 2단계에서 생성한 역할에 권한 정책을 연결합니다. 이 정책에서는 역할이 계정 B의 역할을 수임하도록 허용합니다.

 **계정 A의 역할에 대한 권한 정책** - 이 정책은 계정 B의 대상 역할에 `sts:AssumeRole` 권한을 부여합니다.

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::444455556666:role/account-b-role"
        }
    ]
}
```

### 4단계: 역할을 연결하도록 포드 구성
<a name="_step_4_configure_the_pod_to_chain_roles"></a>

포드가 계정 B의 역할을 수임할 수 있게 하는 애플리케이션 코드에서는 두 가지 프로필, 즉 `account_b_role` 및 `account_a_role`을 사용합니다. `account_b_role` 프로필에서는 `account_a_role` 프로필을 소스로 사용합니다. AWS CLI의 경우 `~/.aws/config` 파일은 다음과 유사합니다.

```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws:iam::444455556666:role/account-b-role

[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws:iam::111122223333:role/account-a-role
```

연결된 프로필을 다른 AWS SDK에 지정하려면 사용 중인 SDK에 대한 설명서를 참조하세요. 자세한 내용은 [AWS 기반의 도구](https://aws.amazon.com/developer/tools/)를 참조하세요.

# AWS SDK와 함께 IRSA 사용
<a name="iam-roles-for-service-accounts-minimum-sdk"></a>

**보안 인증 정보 사용**  
서비스 계정(IRSA)에 대한 IAM 역할의 자격 증명을 사용하려면 코드에서 임의의 AWS SDK를 사용하여 SDK가 포함된 AWS 서비스에 대한 클라이언트를 만들 수 있고, 기본적으로 SDK는 일련의 위치에서 사용할 AWS Identity and Access Management ID를 검색합니다. 클라이언트를 생성하거나 SDK를 초기화했을 때 보안 인증 정보 공급자를 지정하지 않으면 서비스 계정에 대한 IAM 역할 보안 인증 정보가 사용됩니다.

이는 서비스 계정에 대한 IAM 역할이 기본 보안 인증 정보 체인의 한 단계로 추가되었기 때문에 작동합니다. 워크로드가 현재 보안 인증 정보 체인의 이전 단계에 있는 보안 인증 정보를 사용하는 경우 동일한 워크로드에 대해 서비스 계정에 대한 IAM 역할을 구성하더라도 해당 보안 인증 정보는 계속 사용됩니다.

SDK는 `AssumeRoleWithWebIdentity` 작업을 사용하여 AWS Security Token Service에서 임시 자격 증명에 대한 서비스 계정 OIDC 토큰을 자동 교환합니다. Amazon EKS와 이 SDK 작업은 만료되기 전에 갱신하여 임시 보안 인증 정보를 계속 교체합니다.

[서비스 계정에 IAM 역할](iam-roles-for-service-accounts.md)을 사용할 때 포드에 있는 컨테이너에서는 OpenID Connect 웹 ID 토큰 파일을 통해 IAM 역할을 수임할 수 있도록 지원하는 AWS SDK 버전을 사용해야 합니다. AWS SDK에 대해 다음과 같은 버전 또는 이후 버전을 사용해야 합니다.
+ Java(버전 2) - [2.10.11](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11) 
+ Java – [1.12.782](https://github.com/aws/aws-sdk-java/releases/tag/1.12.782) 
+  AWS SDK for Go v1 – [1.23.13](https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13) 
+  AWS SDK for Go v2 - 모든 버전 지원
+ Python(Boto3) - [1.9.220](https://github.com/boto/boto3/releases/tag/1.9.220) 
+ Python(botocore) - [1.12.200](https://github.com/boto/botocore/releases/tag/1.12.200) 
+  AWS CLI – [1.16.232](https://github.com/aws/aws-cli/releases/tag/1.16.232) 
+ 노드 – [2.525.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.525.0) 및 [3.27.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.27.0) 
+ Ruby - [3.58.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#3580-2019-07-01) 
+ C\$1\$1 - [1.7.174](https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174) 
+ .NET – [3.3.659.1](https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1) – `AWSSDK.SecurityToken`도 포함해야 합니다.
+ PHP - [3.110.7](https://github.com/aws/aws-sdk-php/releases/tag/3.110.7) 

[클러스터 자동 확장 처리](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), [AWS Load Balancer Controller를 사용한 인터넷 트래픽 라우팅](aws-load-balancer-controller.md), [Kubernetes용 Amazon VPC CNI 플러그인](cni-iam-role.md) 등 많은 인기 있는 Kubernetes 추가 기능이 서비스 계정에 대한 IAM 역할을 지원합니다.

지원되는 SDK를 사용 중인지 확인하려면 컨테이너를 빌드할 때 [AWS에서의 구축을 위한 도구](https://aws.amazon.com/tools/)에서 선호하는 SDK에 대한 설치 지침을 따르세요.

## 고려 사항
<a name="_considerations"></a>

### Java
<a name="_java"></a>

Java를 사용할 때는 클래스 경로에 **`sts` 모듈을 포함해야 합니다. 자세한 내용은 Java SDK 문서의 [WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html)를 참조하세요.

# 서명 키를 가져와서 OIDC 토큰 검증
<a name="irsa-fetch-keys"></a>

Kubernetes는 각 Kubernetes 서비스 계정에 `ProjectedServiceAccountToken`을 발급합니다. 이 토큰은 JSON 웹 토큰(JWT)의 한 유형인 OIDC 토큰입니다. Amazon EKS는 외부 시스템에서 토큰을 검증할 수 있도록 토큰에 대한 서명 키가 포함된 각 클러스터에 대해 퍼블릭 OIDC 엔드포인트를 호스트합니다.

`ProjectedServiceAccountToken`을 검증하려면 JSON Web Key Set(JWKS)라고도 하는 OIDC 퍼블릭 서명 키를 가져와야 합니다. 애플리케이션에서 이러한 키를 사용하여 토큰을 검증합니다. 예를 들어, [PyJWT Python 라이브러리](https://pyjwt.readthedocs.io/en/latest/)를 사용하여 이러한 키로 토큰을 검증할 수 있습니다. `ProjectedServiceAccountToken`에 대한 자세한 내용은 [IAM, Kubernetes 및 OpenID Connect(OIDC) 백그라운드 정보](iam-roles-for-service-accounts.md#irsa-oidc-background) 섹션을 참조하세요.

## 사전 조건
<a name="_prerequisites"></a>
+ 클러스터에 대한 기존 AWS Identity and Access Management(IAM) OpenID Connect(OIDC) 제공자입니다. 이미 있는지 아니면 생성해야 하는지 확인하려면 [클러스터에 대한 IAM OIDC 공급자 생성](enable-iam-roles-for-service-accounts.md) 부분을 참조하세요.
+  ** AWS CLI **- Amazon EKS를 비롯한 AWS 서비스를 사용한 작업을 위한 명령줄 도구입니다. 자세한 내용은 AWS 명령줄 인터페이스 사용 설명서에서 [설치하기](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)를 참조하세요. AWS CLI 설치 후, 구성 작업도 수행하는 것이 좋습니다. 자세한 내용은 AWS 명령줄 인터페이스 사용 설명서에서 [aws config를 사용한 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요.

## 절차
<a name="_procedure"></a>

1. AWS CLI를 사용하여 Amazon EKS 클러스터의 OIDC URL을 검색합니다.

   ```
   $ aws eks describe-cluster --name my-cluster --query 'cluster.identity.oidc.issuer'
   "https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE"
   ```

1. curl 또는 유사한 도구를 사용하여 공개 서명 키를 검색합니다. 그 결과, [JSON 웹 키 세트(JWKS)](https://www.rfc-editor.org/rfc/rfc7517#section-5)가 생성됩니다.
**중요**  
Amazon EKS는 OIDC 엔드포인트에 대한 직접 호출을 스로틀링합니다. 공개 서명 키를 캐시해야 합니다. 응답에 포함된 `cache-control` 헤더를 준수합니다.
**중요**  
Amazon EKS는 7일마다 OIDC 서명 키를 교체합니다.

   ```
   $ curl https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE/keys
   {"keys":[{"kty":"RSA","kid":"2284XXXX4a40","use":"sig","alg":"RS256","n":"wklbXXXXMVfQ","e":"AQAB"}]}
   ```

# EKS Pod Identity가 포드에 AWS 서비스에 대한 액세스 권한을 부여하는 방법 알아보기
<a name="pod-identities"></a>

포드의 컨테이너에 있는 애플리케이션은 AWS SDK 또는 AWS CLI를 사용하여 AWS ID 및 액세스 관리(IAM) 권한을 사용하여 AWS 서비스에 API 요청을 할 수 있다. 애플리케이션은 AWS 자격 증명으로 AWS API 요청에 서명해야 합니다.

 **EKS Pod Identity는 Amazon EC2 인스턴스 프로필이 Amazon EC2 인스턴스에 자격 증명을 제공하는 것과 비슷한 방식으로 애플리케이션에 대한 자격 증명을 관리하는 기능을 제공합니다. AWS 자격 증명을 생성하여 컨테이너에 배포하거나 Amazon EC2 인스턴스의 역할을 사용하는 대신에 IAM 역할을 Kubernetes 서비스 계정과 연결하고 서비스 계정을 사용하도록 포드를 구성합니다.

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/aUjJSorBE70?rel=0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0)


각 EKS Pod Identity 연결은 역할을 지정된 클러스터의 네임스페이스에 있는 서비스 계정에 매핑합니다. 여러 클러스터에 동일한 애플리케이션이 있는 경우 역할의 신뢰 정책을 수정하지 않고 각 클러스터에서 동일한 연결을 생성할 수 있습니다.

포드가 연결이 있는 서비스 계정을 사용하는 경우 Amazon EKS는 포드의 컨테이너에 환경 변수를 설정합니다. 환경 변수는 AWS CLI를 포함한 AWS SDK를 구성하여 EKS Pod Identity 보안 인증 정보를 사용합니다.

## EKS Pod Identity의 이점
<a name="pod-id-benefits"></a>

EKS Pod Identity는 다음 이점을 제공합니다.
+  **최소 권한** – IAM 권한의 범위를 서비스 계정으로 지정할 수 있습니다. 그러면 해당 서비스 계정을 사용하는 포드만 이 권한에 액세스할 수 있습니다. 또한 이 기능을 사용하면 `kiam`, `kube2iam` 같은 타사 솔루션이 필요 없습니다.
+  **자격 증명 격리** - [Amazon EC2 인스턴스 메타데이터 서비스(IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)에 대한 액세스가 제한되면 포드의 컨테이너는 컨테이너가 사용하는 서비스 계정과 연결된 IAM 역할에 대한 자격 증명만 검색할 수 있습니다. 컨테이너는 다른 포드의 다른 컨테이너에서 사용하는 자격 증명에 액세스할 수 없습니다. IMDS가 제한되지 않으면 포드의 컨테이너도 [Amazon EKS 노드 IAM 역할](create-node-role.md)에 액세스할 수 있으며 컨테이너는 동일한 노드에 있는 다른 포드의 IAM 역할 자격 증명에 액세스할 수도 있습니다. 자세한 내용은 [작업자 노드에 할당된 인스턴스 프로필에 대한 액세스 제한](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations) 부분을 참조하세요.

**참고**  
`hostNetwork: true`로 구성된 포드는 항상 IMDS 액세스 권한이 있지만 AWS SDK와 CLI는 활성화된 경우 Pod Identity 자격 증명을 사용합니다.
+  **감사** - 소급적 감사를 위해 AWS CloudTrail을 통해 액세스 및 이벤트 로깅이 가능합니다.

**중요**  
컨테이너는 보안 경계가 아니며 Pod Identity를 사용해도 이는 변경되지 않습니다. 동일한 노드에 할당된 포드는 커널과 포드 구성에 따라 잠재적으로 다른 리소스를 공유하게 됩니다. 별도의 노드에서 실행되는 포드는 컴퓨팅 계층에서 격리되지만, 개별 인스턴스의 범위를 넘어서는 추가 권한이 있는 노드 애플리케이션이 Kubernetes API에 있습니다. 몇 가지 예로 `kubelet`, `kube-proxy`, CSI 스토리지 드라이버 또는 자체 Kubernetes 애플리케이션이 있습니다.

EKS Pod Identity는 OIDC ID 제공업체를 사용하지 않으므로 [서비스 계정에 대한 IAM 역할](iam-roles-for-service-accounts.md)에 비해 간단한 방법입니다. EKS Pod Identity의 개선 사항:
+  **독립적 운영** - 많은 조직에서 OIDC ID 제공업체를 만드는 것은 Kubernetes 클러스터를 관리하는 팀이 아닌 다른 팀의 책임입니다. EKS Pod Identity는 업무가 분명히 분리되어 있어 EKS Pod Identity 연결의 모든 구성은 Amazon EKS에서, IAM 권한의 모든 구성은 IAM에서 이루어집니다.
+  **재사용 가능성** - EKS Pod Identity는 서비스 계정에 대한 IAM 역할이 사용하는 각 클러스터에 대해 별도의 보안 주체 대신 단일 IAM 보안 주체를 사용합니다. IAM 관리자는 모든 역할의 신뢰 정책에 다음 보안 주체를 추가하여 EKS Pod Identity에서 사용할 수 있도록 합니다.

  ```
              "Principal": {
                  "Service": "pods.eks.amazonaws.com"
              }
  ```
+  **확장성** - 각 임시 자격 증명 세트는 각 포드에서 실행하는 각 AWS SDK 대신 EKS Pod Identity의 EKS Auth 서비스에서 수임합니다. 그러면 각 노드에서 실행되는 Amazon EKS Pod Identity 에이전트가 SDK에 보안 인증 정보를 발급합니다. 따라서 부하가 각 노드당 한 번으로 줄어들고 각 포드에 중복되지 않습니다. 프로세스의 자세한 내용은 [EKS Pod Identity 작동 방식 이해](pod-id-how-it-works.md) 섹션을 참조하세요.

두 대안의 비교에 대한 자세한 내용은 [Kubernetes 서비스 계정을 사용하여 Kubernetes 워크로드에 AWS에 대한 액세스 권한 부여](service-accounts.md) 섹션을 참조하세요.

## EKS Pod Identity 설정 개요
<a name="pod-id-setup-overview"></a>

다음 절차를 완료하여 EKS Pod Identity를 활성화합니다.

1.  [Amazon EKS Pod Identity 에이전트 설정](pod-id-agent-setup.md) - 각 클러스터에 대해 한 번만 이 절차를 완료합니다. 클러스터에서 EKS Auto Mode가 활성화된 경우 이 단계를 완료할 필요가 없습니다.

1.  [Kubernetes 서비스 계정에 IAM 역할 할당](pod-id-association.md) - 애플리케이션에 부여하려는 고유한 권한 세트에 대해 이 절차를 완료합니다.

1.  [서비스 계정으로 AWS 서비스에 액세스하도록 포드 구성](pod-id-configure-pods.md) - AWS 서비스에 액세스해야 하는 각 포드에 대해 이 절차를 완료합니다.

1.  [AWS SDK와 함께 Pod Identity 사용](pod-id-minimum-sdk.md) - 워크로드가 지원되는 버전의 AWS SDK를 사용하고 워크로드가 기본 보안 인증 정보 체인을 사용하는지 확인합니다.

## Limits
<a name="pod-id-limits"></a>
+ Kubernetes 서비스 계정에 IAM 역할 매핑을 위해 클러스터당 최대 5,000개의 EKS Pod Identity 연결이 지원됩니다.

## 고려 사항
<a name="pod-id-considerations"></a>
+  **IAM 역할 연결**: 클러스터의 각 Kubernetes 서비스 계정은 클러스터와 동일한 AWS 계정에서 하나의 IAM 역할과 연결할 수 있습니다. 역할을 변경하려면 EKS Pod Identity 연결을 편집합니다. 교차 계정 액세스의 경우 IAM 역할을 사용하여 역할에 대한 액세스 권한을 위임합니다. 자세한 내용은 *IAM 사용 설명서*의 [튜토리얼: IAM 역할을 사용한 AWS 계정 간 액세스 권한 위임](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)을 참조하세요.
+  **EKS Pod Identity 에이전트**: EKS Pod Identity를 사용하려면 Pod Identity 에이전트가 필요합니다. 에이전트는 클러스터 노드에서 Kubernetes `DaemonSet`로 실행되어 동일한 노드의 포드에만 자격 증명을 제공합니다. 또한 링크-로컬 주소(IPv4의 경우 `169.254.170.23`, IPv6의 경우 `[fd00:ec2::23]`)에서 포트 `80`과 `2703`을 사용하는 노드의 `hostNetwork`를 이용합니다. 클러스터에서 IPv6가 비활성화된 경우 Pod Identity 에이전트에 대해 IPv6를 비활성화하세요. 자세한 내용은 [EKS Pod Identity 에이전트에서 IPv6 비활성화](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html)를 참조하세요.
+  **궁극의 일관성**: EKS Pod Identity 연결은 궁극적으로 일관성을 유지하지만 API 직접 호출 후 몇 초의 지연이 발생할 수 있습니다. 중요하고 가용성이 높은 코드 경로에서 연결을 생성하거나 업데이트하지 마세요. 대신, 빈도가 낮은 별도의 초기화 또는 설정 루틴에서 이러한 작업을 수행하세요. 자세한 내용은 *EKS 모범 사례 가이드*의 [Security Groups Per Pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html)를 참조하세요.
+  **프록시 및 보안 그룹 고려 사항**: 프록시를 사용하는 포드의 경우 `no_proxy/NO_PROXY` 환경 변수에 `169.254.170.23`(IPv4)과 `[fd00:ec2::23]`(IPv6)를 추가하여 EKS Pod Identity 에이전트에 대한 요청 실패를 방지하세요. AWS VPC CNI와 함께 포드의 보안 그룹을 사용하는 경우 `ENABLE_POD_ENI` 플래그를 'true'로 설정하고 `POD_SECURITY_GROUP_ENFORCING_MODE` 플래그를 'standard'로 설정합니다. 자세히 알아보려면 [개별 포드에 보안 그룹 할당](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html)을 참조하세요.

### EKS Pod Identity 클러스터 버전
<a name="pod-id-cluster-versions"></a>

EKS Pod Identity를 사용하려면 클러스터의 플랫폼 버전이 다음 표에 나열된 버전과 동일한 버전 또는 이후 버전이거나 Kubernetes 버전이 표에 나열된 버전보다 이후 버전이어야 합니다. Kubernetes 버전용 Amazon EKS Pod Identity 에이전트의 권장 버전을 찾으려면 [Amazon EKS 추가 기능 버전의 클러스터와의 호환성 확인](addon-compat.md) 섹션을 참조하세요.


| Kubernetes 버전 | 플랫폼 버전 | 
| --- | --- | 
|  나열되지 않은 Kubernetes 버전  |  모든 플랫폼 버전 지원  | 
|   `1.28`   |   `eks.4`   | 

### EKS Pod Identity 제한 사항
<a name="pod-id-restrictions"></a>

EKS Pod Identity는 다음에서 사용 가능합니다.
+ 이전 주제 [EKS Pod Identity 클러스터 버전](#pod-id-cluster-versions)에 나열된 Amazon EKS 클러스터 버전.
+ Linux Amazon EC2 인스턴스인 클러스터의 워커 노드.

EKS Pod Identity는 다음에서 사용할 수 없습니다.
+  AWS Outposts
+ Amazon EKS Anywhere.
+ Amazon EC2에서 생성하고 실행하는 Kubernetes 클러스터. EKS Pod Identity 구성 요소는 Amazon EKS에서만 사용할 수 있습니다.

다음에서는 EKS Pod Identity를 사용할 수 없습니다.
+ Linux Amazon EC2 인스턴스를 제외한 모든 위치에서 실행되는 포드. AWS Fargate(Fargate)에서 실행되는 Linux 및 Windows 포드는 지원되지 않습니다. Windows Amazon EC2 인스턴스에서 실행되는 포드는 지원되지 않습니다.

# EKS Pod Identity 작동 방식 이해
<a name="pod-id-how-it-works"></a>

Amazon EKS Pod Identity는 Amazon EC2 인스턴스 프로필이 Amazon EC2 인스턴스에 자격 증명을 제공하는 것과 비슷한 방식으로 애플리케이션에 대한 자격 증명을 관리하는 기능을 제공합니다.

Amazon EKS Pod Identity는 추가 **EKS Auth API와 각 노드에서 실행되는 에이전트 포드를 통해 워크로드에 보안 인증 정보를 제공합니다.

**Amazon EKS 추가 기능 및 자체 관리형 컨트롤러, 운영자 및 기타 추가 기능과 같은 추가 기능에서 작성자는 최신 AWS SDK를 사용하도록 소프트웨어를 업데이트해야 합니다. EKS Pod Identity와 Amazon EKS에서 만든 추가 기능 간의 호환성 목록은 이전 섹션([EKS Pod Identity 제한 사항](pod-identities.md#pod-id-restrictions))을 참조하세요.

## 코드에서 EKS Pod Identity 사용
<a name="pod-id-credentials"></a>

코드에서 AWS SDK를 사용하여 AWS 서비스에 액세스할 수 있습니다. 코드를 작성하여 SDK가 포함된 AWS 서비스에 대한 클라이언트를 만들고, 기본적으로 SDK는 일련의 위치에서 사용할 AWS ID 및 액세스 관리 보안 인증 정보를 검색합니다. 유효한 보안 인증 정보를 찾은 후에는 검색이 중지됩니다. 사용되는 기본 위치에 대한 자세한 내용은 AWS SDK 및 도구 참조 가이드의 [보안 인증 정보 공급자 체인](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)을 참조하세요.

기본 보안 인증 정보 체인의 한 단계에서 검색되는 **컨테이너 보안 인증 정보 공급자에 EKS Pod Identity가 추가되었습니다. 워크로드가 현재 보안 인증 정보 체인의 이전 단계에 있는 보안 인증 정보를 사용하는 경우 동일한 워크로드에 대해 EKS Pod Identity 연결을 구성하더라도 해당 보안 인증 정보는 계속 사용됩니다. 이렇게 하면 이전 보안 인증 정보를 제거하기 전에 먼저 연결을 생성하여 다른 유형의 보안 인증 정보에서 안전하게 마이그레이션할 수 있습니다.

컨테이너 보안 인증 정보 공급자는 각 노드에서 실행되는 에이전트의 임시 보안 인증 정보를 제공합니다. Amazon EKS에서 에이전트는 Amazon EKS Pod Identity 에이전트이고 Amazon Elastic Container Service에서 에이전트는 `amazon-ecs-agent`입니다. SDK는 환경 변수를 사용하여 연결할 에이전트를 찾습니다.

반면 *서비스 계정에 대한 IAM 역할*은 AWS SDK가 `AssumeRoleWithWebIdentity`를 사용하여 AWS 보안 토큰 서비스와 교환해야 하는 *웹 ID* 토큰을 제공합니다.

## EKS Pod Identity 에이전트와 포드의 작동 방식
<a name="pod-id-agent-pod"></a>

1. Amazon EKS가 EKS Pod Identity 연결이 있는 서비스 계정을 사용하는 새 포드를 시작하면 클러스터는 포드 매니페스트에 다음 콘텐츠를 추가합니다.

   ```
       env:
       - name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
         value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
       - name: AWS_CONTAINER_CREDENTIALS_FULL_URI
         value: "http://169.254.170.23/v1/credentials"
       volumeMounts:
       - mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
         name: eks-pod-identity-token
     volumes:
     - name: eks-pod-identity-token
       projected:
         defaultMode: 420
         sources:
         - serviceAccountToken:
             audience: pods.eks.amazonaws.com
             expirationSeconds: 86400 # 24 hours
             path: eks-pod-identity-token
   ```

1. Kubernetes는 포드를 실행할 노드를 선택합니다. 그러면 노드의 Amazon EKS Pod Identity 에이전트는 [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) 작업을 사용하여 EKS Auth API에서 임시 보안 인증 정보를 검색합니다.

1. EKS Pod Identity 에이전트는 컨테이너 내에서 실행하는 AWS SDK에 이러한 보안 인증 정보를 사용할 수 있도록 합니다.

1. 기본 보안 인증 정보 체인을 사용하도록 보안 인증 정보 공급자를 지정하지 않고도 애플리케이션에서 SDK를 사용할 수 있습니다. 또는 컨테이너 보안 인증 정보 공급자를 지정합니다. 사용되는 기본 위치에 대한 자세한 내용은 AWS SDK 및 도구 참조 가이드의 [보안 인증 정보 공급자 체인](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)을 참조하세요.

1. SDK는 환경 변수를 사용하여 EKS Pod Identity 에이전트에 연결하고 보안 인증 정보를 검색합니다.
**참고**  
워크로드가 현재 보안 인증 정보 체인의 이전 단계에 있는 보안 인증 정보를 사용하는 경우 동일한 워크로드에 대해 EKS Pod Identity 연결을 구성하더라도 해당 보안 인증 정보는 계속 사용됩니다.

# Amazon EKS Pod Identity 에이전트 설정
<a name="pod-id-agent-setup"></a>

Amazon EKS Pod Identity는 Amazon EC2 인스턴스 프로필이 Amazon EC2 인스턴스에 자격 증명을 제공하는 것과 비슷한 방식으로 애플리케이션에 대한 자격 증명을 관리하는 기능을 제공합니다.

Amazon EKS Pod Identity는 추가 **EKS Auth API와 각 노드에서 실행되는 에이전트 포드를 통해 워크로드에 보안 인증 정보를 제공합니다.

**작은 정보**  
EKS Auto Mode 클러스터에 EKS Pod Identity 에이전트를 설치할 필요가 없습니다. 이 기능은 EKS Auto Mode에 내장되어 있습니다.

## 고려 사항
<a name="pod-id-agent-considerations"></a>
+ 기본적으로 EKS Pod Identity Agent는 EKS Auto Mode 클러스터에 사전 설치되어 있습니다. 자세한 내용은 [EKS Auto Mode를 사용하여 클러스터 인프라 자동화](automode.md)를 참조하세요.
+ 기본적으로 EKS Pod Identity 에이전트는 포드의 `IPv4` 및 `IPv6` 주소에서 수신 대기하여 자격 증명을 요청합니다. 에이전트는 `IPv4`의 경우, 루프백(localhost) IP 주소 `169.254.170.23`을 사용하고 `IPv6`의 경우, localhost IP 주소 `[fd00:ec2::23]`을 사용합니다.
+ `IPv6` 주소를 비활성화하거나 localhost `IPv6` IP 주소를 차단하는 경우 에이전트를 시작할 수 없습니다. `IPv6`을 사용할 수 없는 노드에서 에이전트를 시작하려면 [EKS Pod Identity 에이전트에서 `IPv6` 비활성화](pod-id-agent-config-ipv6.md)의 단계에 따라 `IPv6` 구성을 비활성화합니다.

## Amazon EKS Pod Identity 에이전트 생성
<a name="pod-id-agent-add-on-create"></a>

### 에이전트 필수 조건
<a name="pod-id-agent-prereqs"></a>
+ 기존 Amazon EKS 클러스터. 배포하려면 [Amazon EKS 시작하기](getting-started.md) 섹션을 참조하세요. 클러스터 버전 및 플랫폼 버전은 [EKS pod identity 클러스터 버전](pod-identities.md#pod-id-cluster-versions)에 나열된 버전과 동일한 버전 또는 이후 버전이어야 합니다.
+ 노드 역할에는 에이전트가 EKS Auth API에서 `AssumeRoleForPodIdentity` 작업을 수행할 수 있는 권한이 있습니다. [AWS 관리형 정책: AmazonEKSWorkerNodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy)를 사용하거나 다음과 유사한 사용자 지정 정책을 추가할 수 있습니다.

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

  이 작업은 태그로 제한하여 에이전트를 사용하는 포드가 맡을 수 있는 역할을 제한할 수 있습니다.
+ 노드는 Amazon ECR에 연결하여 이미지를 다운로드할 수 있습니다. 추가 기능의 컨테이너 이미지는 [Amazon EKS 추가 기능의 Amazon 컨테이너 이미지 레지스트리 보기](add-ons-images.md)에 나열된 레지스트리에 있습니다.

  AWS Management Console의 **선택적 구성 설정**, 그리고 AWS CLI의 `--configuration-values`에서 이미지 위치를 변경하고 EKS 추가 기능에 대해 `imagePullSecrets`를 제공할 수 있습니다.
+ 노드는 Amazon EKS Auth API에 연결할 수 있습니다. 프라이빗 클러스터의 경우 AWS 프라이빗 링크의 `eks-auth` 엔드포인트가 필요합니다.

### AWS 콘솔을 사용하여 에이전트 설정
<a name="setup_agent_with_shared_aws_console"></a>

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

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

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

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

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

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

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

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

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

1. EKS Pod Identity 에이전트 포드가 클러스터에서 실행 중인지 확인합니다.

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

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

   ```
   eks-pod-identity-agent-gmqp7                                          1/1     Running   1 (24h ago)   24h
   eks-pod-identity-agent-prnsh                                          1/1     Running   1 (24h ago)   24h
   ```

   이제 클러스터에서 EKS Pod Identity 연결을 사용할 수 있습니다. 자세한 내용은 [Kubernetes 서비스 계정에 IAM 역할 할당](pod-id-association.md) 섹션을 참조하세요.

### AWS CLI를 사용하여 에이전트 설정
<a name="setup_agent_with_shared_aws_cli"></a>

1. 다음 AWS CLI 명령을 실행합니다. `my-cluster`를 클러스터 이름으로 바꿉니다.

   ```
   aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
   ```
**참고**  
EKS Pod Identity 에이전트는 *서비스 계정에 대한 IAM 역할*에 `service-account-role-arn`을 사용하지 않습니다. EKS Pod Identity 에이전트에 노드 역할의 권한을 제공해야 합니다.

1. EKS Pod Identity 에이전트 포드가 클러스터에서 실행 중인지 확인합니다.

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

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

   ```
   eks-pod-identity-agent-gmqp7                                          1/1     Running   1 (24h ago)   24h
   eks-pod-identity-agent-prnsh                                          1/1     Running   1 (24h ago)   24h
   ```

   이제 클러스터에서 EKS Pod Identity 연결을 사용할 수 있습니다. 자세한 내용은 [Kubernetes 서비스 계정에 IAM 역할 할당](pod-id-association.md) 섹션을 참조하세요.

# Kubernetes 서비스 계정에 IAM 역할 할당
<a name="pod-id-association"></a>

이 주제에서는 EKS Pod Identity 관련 AWS Identity and Access Management(IAM) 역할을 수임하도록 Kubernetes 서비스 계정을 구성하는 방법을 다룹니다. 서비스 계정을 사용하도록 구성된 모든 포드는 해당 역할에 액세스 권한이 있는 모든 AWS 서비스에 액세스할 수 있습니다.

EKS Pod Identity 연결을 생성하려면 한 단계만 거치면 됩니다. AWS Management Console, AWS CLI, AWS SDK, AWS CloudFormation 및 기타 도구를 통해 EKS에서 연결을 생성하면 됩니다. 임의 Kubernetes 객체의 클러스터 내부에 연결에 대한 데이터나 메타데이터가 없으므로 서비스 계정에 주석을 추가하지 않습니다.

 **사전 조건** 
+ 기존 클러스터가 있어야 합니다. 아직 없는 경우 [Amazon EKS 시작하기](getting-started.md) 안내서 중 하나에 따라 생성할 수 있습니다.
+ 연결을 생성하는 IAM 보안 주체에 `iam:PassRole`이 있어야 합니다.
+ AWS CLI의 최신 버전이 디바이스나 AWS CloudShell에 설치 및 구성되어 있어야 합니다. `aws --version | cut -d / -f2 | cut -d ' ' -f1`을 사용하여 현재 버전을 확인할 수 있습니다. `yum`, `apt-get` 또는 macOS용 Homebrew와 같은 패키지 관리자는 최신 버전의 AWS CLI 이전에 나온 버전이 몇 가지 있을 때도 있습니다. 최신 버전을 설치하려면 AWS 명령줄 인터페이스 사용 설명서에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요. AWS CloudShell에 설치된 AWS CLI 버전도 최신 버전보다 여러 버전 이전일 수도 있습니다. 업데이트하려면 AWS CloudShell 사용 설명서의 [홈 디렉터리에 AWS CLI 설치하기](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)를 참조하세요.
+ `kubectl` 명령줄 도구는 장치 또는 AWS CloudShell에 설치됩니다. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. 예를 들어, 클러스터 버전이 `1.29`인 경우 `kubectl` 버전 `1.28`, `1.29` 또는 `1.30`를 함께 사용할 수 있습니다. `kubectl`을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 부분을 참조하세요.
+ 클러스터 구성이 포함된 기존 `kubectl` `config` 파일입니다. `kubectl` `config` 파일을 생성하려면 [Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결](create-kubeconfig.md) 섹션을 참조하세요.

## pod identity 연결 생성(AWS 콘솔)
<a name="pod-id-association-create"></a>

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

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

1. **액세스** 탭을 선택합니다.

1. **Pod Identity 연결**에서 **생성**을 선택합니다.

1. **IAM 역할**의 경우 워크로드에 부여하려는 권한이 있는 IAM 역할을 선택합니다.
**참고**  
이 목록에는 EKS Pod Identity에서의 사용을 허용하는 다음 신뢰 정책이 있는 역할만 포함되어 있습니다.

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

    `sts:AssumeRole` - EKS Pod Identity는 `AssumeRole`을 사용하여 임시 보안 인증 정보를 포드에 전달하기 전에 IAM 역할을 맡습니다.

    `sts:TagSession` - EKS Pod Identity는 `TagSession`을 사용하여 *세션 태그*를 AWS STS 요청에 포함합니다.

   신뢰 정책의 *조건 키*에서 이러한 태그를 사용하여 이 역할을 사용할 수 있는 서비스 계정, 네임스페이스, 클러스터를 제한할 수 있습니다.

   Amazon EKS 조건 키 목록을 보려면 *서비스 인증 참조*의 [Amazon Elastic Kubernetes Service의 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys)를 참조하세요. 조건 키를 사용할 수 있는 작업과 리소스를 알아보려면 [Amazon Elastic Kubernetes Service에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)을 참조하세요.

1. **Kubernetes 네임스페이스**에서 서비스 계정 및 워크로드가 포함된 Kubernetes 네임스페이스를 선택합니다. 클러스터에 없는 네임스페이스를 이름으로 지정할 수 있습니다.

1. **Kubernetes 서비스 계정**에서 사용할 Kubernetes 서비스 계정을 선택합니다. Kubernetes 워크로드의 매니페스트에서 이 서비스 계정을 지정해야 합니다. 클러스터에 없는 서비스 계정을 이름으로 지정할 수 있습니다.

1. (선택 사항) Pod Identity가 역할을 수임할 때 자동으로 추가하는 기본 세션 태그를 비활성화하려면 **세션 태그 비활성화**를 선택하세요.

1. (선택 사항) IAM 역할에 연결된 IAM 정책에 정의된 권한 외에 이 Pod Identity 연결에 추가 제한 사항을 적용하도록 IAM 정책을 구성하려면 **세션 정책 구성**을 전환하세요.
**참고**  
세션 정책은 **세션 태그 비활성화** 설정이 선택된 경우에만 적용할 수 있습니다.

1. (선택사항) **태그**의 경우, **태그 추가**를 선택하여 키-값 페어에 메타데이터를 추가합니다. 이러한 태그는 연결에 적용되며 IAM 정책에서 사용할 수 있습니다.

   이 단계를 반복하여 여러 개의 태그를 추가할 수 있습니다.

1. **생성**을 선택합니다.

## pod identity 연결 생성(AWS CLI)
<a name="create_a_pod_identity_association_shared_aws_cli"></a>

1. IAM 역할에 기존 IAM 정책을 연결하려면 다음 단계로 건너뜁니다.

   IAM 정책을 생성합니다. 자체 정책을 생성하거나 필요한 권한 중 일부를 이미 부여하는 AWS 관리형 정책을 복사하여 특정 요구 사항에 맞게 사용자 지정할 수 있습니다. 자세한 내용은 **IAM 사용 설명서에서 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)을 참조하세요.

   1. 포드가 액세스할 AWS 서비스에 대한 권한이 포함된 파일을 생성합니다. 모든 AWS 서비스에 대한 모든 작업 목록은 [서비스 승인 참조](https://docs.aws.amazon.com/service-authorization/latest/reference/)에서 확인하세요.

      다음 명령을 실행하여 Amazon S3 버킷에 대한 읽기 전용 액세스를 허용하는 예제 정책 파일을 생성할 수 있습니다. 이 버킷에 구성 정보 또는 부트스트랩 스크립트를 저장할 수도 있고, 의 컨테이너는 이 버킷에서 파일을 읽어 애플리케이션으로 로드할 수 있습니다. 이 예제 정책을 생성하려면 다음 내용을 디바이스에 복사합니다. *my-pod-secrets-bucket*을 버킷 이름으로 바꾸고 명령을 실행합니다.

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": "s3:GetObject",
                  "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
              }
          ]
      }
      ```

   1. IAM 정책을 생성합니다.

      ```
      aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
      ```

1. IAM 역할을 생성하고 Kubernetes 서비스 계정에 연결합니다.

   1. IAM 역할을 수임하려는 기존 Kubernetes 서비스 계정이 있는 경우 이 단계를 건너뛸 수 있습니다.

      Kubernetes 서비스 계정을 생성합니다. 다음 콘텐츠를 디바이스에 복사합니다. *my-service-account*를 원하는 이름으로 바꾸고 필요한 경우 *기본*을 다른 네임스페이스로 바꿉니다. *기본*을 변경하는 경우, 네임스페이스가 이미 존재해야 합니다.

      ```
      cat >my-service-account.yaml <<EOF
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: my-service-account
        namespace: default
      EOF
      kubectl apply -f my-service-account.yaml
      ```

      다음 명령을 실행합니다.

      ```
      kubectl apply -f my-service-account.yaml
      ```

   1. 다음 명령을 실행하여 IAM 역할에 대한 신뢰 정책 파일을 생성합니다.

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

   1. 역할을 생성합니다. *my-role*을 IAM 역할의 이름으로 바꾸고, *my-role-description*을 역할에 대한 설명으로 바꿉니다.

      ```
      aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
      ```

   1. 역할에 IAM 정책을 연결합니다. *my-role*을 IAM 역할의 이름으로 바꾸고 *my-policy*를 생성한 기존 정책의 이름으로 바꿉니다.

      ```
      aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws:iam::111122223333:policy/my-policy
      ```
**참고**  
서비스 계정에 대한 IAM 역할과 달리 EKS Pod Identity는 서비스 계정의 주석을 사용하지 않습니다.

   1. 다음 명령을 실행하여 연결을 생성합니다. `my-cluster`를 클러스터 이름으로 바꾸고, 필요한 경우 *my-service-account*를 원하는 이름으로 바꾸고 *기본*을 다른 네임스페이스로 바꿉니다.

      ```
      aws eks create-pod-identity-association --cluster-name my-cluster --role-arn arn:aws:iam::111122223333:role/my-role --namespace default --service-account my-service-account
      ```

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

      ```
      {
          "association": {
              "clusterName": "my-cluster",
              "namespace": "default",
              "serviceAccount": "my-service-account",
              "roleArn": "arn:aws:iam::111122223333:role/my-role",
              "associationArn": "arn:aws::111122223333:podidentityassociation/my-cluster/a-abcdefghijklmnop1",
              "associationId": "a-abcdefghijklmnop1",
              "tags": {},
              "createdAt": 1700862734.922,
              "modifiedAt": 1700862734.922
          }
      }
      ```
**참고**  
클러스터에 없는 네임스페이스와 서비스 계정을 이름으로 지정할 수 있습니다. EKS Pod Identity 연결이 작동하려면 네임스페이스, 서비스 계정 및 서비스 계정을 사용하는 워크로드를 생성해야 합니다.

## 구성 확인
<a name="pod-id-confirm-role-configuration"></a>

1. IAM 역할의 신뢰 정책이 올바르게 구성되었는지 확인합니다.

   ```
   aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
   ```

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

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "Allow EKS Auth service to assume this role for Pod Identities",
               "Effect": "Allow",
               "Principal": {
                   "Service": "pods.eks.amazonaws.com"
               },
               "Action": [
                   "sts:AssumeRole",
                   "sts:TagSession"
               ]
           }
       ]
   }
   ```

1. 이전 단계에서 역할에 연결한 정책이 해당 역할에 연결되었는지 확인합니다.

   ```
   aws iam list-attached-role-policies --role-name my-role --query 'AttachedPolicies[].PolicyArn' --output text
   ```

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

   ```
                  arn:aws:iam::111122223333:policy/my-policy
   ```

1. 사용하려는 정책의 Amazon 리소스 이름(ARN)을 저장할 변수를 설정합니다. *my-policy*를 권한을 확인하려는 정책의 이름으로 바꿉니다.

   ```
   export policy_arn=arn:aws:iam::111122223333:policy/my-policy
   ```

1. 정책의 기본 버전을 봅니다.

   ```
   aws iam get-policy --policy-arn $policy_arn
   ```

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

   ```
   {
       "Policy": {
           "PolicyName": "my-policy",
           "PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
           "Arn": "arn:aws:iam::111122223333:policy/my-policy",
           "Path": "/",
           "DefaultVersionId": "v1",
           [...]
       }
   }
   ```

1. 정책 내용을 보고 포드에 필요한 모든 권한이 정책에 포함되어 있는지 확인합니다. 필요한 경우 다음 명령에서 *1*을 이전 출력에서 반환된 버전으로 바꿉니다.

   ```
   aws iam get-policy-version --policy-arn $policy_arn --version-id v1
   ```

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

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

   이전 단계에서 예제 정책을 생성한 경우 출력은 동일합니다. 다른 정책을 생성한 경우 *예제* 내용이 다릅니다.

## 다음 단계
<a name="_next_steps"></a>

 [서비스 계정으로 AWS 서비스에 액세스하도록 포드 구성](pod-id-configure-pods.md) 

# EKS Pod Identity 대상 IAM 역할을 사용하여 AWS 리소스에 액세스
<a name="pod-id-assign-target-role"></a>

Amazon Elastic Kubernetes Service(Amazon EKS)에서 애플리케이션을 실행할 때 다른 AWS 계정에 있는 AWS 리소스에 액세스해야 할 수 있습니다. 이 설명서에서는 Kubernetes 포드가 대상 역할을 사용하여 다른 AWS 리소스에 액세스할 수 있도록 EKS Pod Identity를 사용하여 교차 계정 액세스를 설정하는 방법을 보여줍니다.

## 사전 조건
<a name="_prerequisites"></a>

시작하기 전에 다음 단계를 완료합니다.
+  [Amazon EKS Pod Identity 에이전트 설정](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) 
+  [EKS Pod Identity 역할 생성](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) 

## 작동 방식
<a name="_how_it_works"></a>

Pod Identity를 사용하면 역할 체이닝이라는 프로세스를 통해 EKS 클러스터의 애플리케이션이 계정 전체에서 AWS 리소스에 액세스할 수 있습니다.

Pod Identity 연결을 생성할 때 두 가지 IAM 역할, 즉 EKS 클러스터와 동일한 계정의 [EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)과 액세스하고자 하는 AWS 리소스(예: S3 버킷 또는 RDS 데이터베이스)가 포함된 계정의 대상 IAM 역할을 제공할 수 있습니다. [EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)은 [IAM PassRole](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html) 요구 사항으로 인해 EKS 클러스터의 계정에 있어야 하는 반면, 대상 IAM 역할은 모든 AWS 계정에 있을 수 있습니다. PassRole을 사용하면 AWS 엔터티가 역할 수임을 다른 서비스에 위임할 수 있습니다. EKS Pod Identity는 PassRole을 사용하여 역할을 Kubernetes 서비스 계정에 연결하므로 역할을 전달하는 ID와 역할이 모두 EKS 클러스터와 동일한 AWS 계정에 있어야 합니다. 애플리케이션 포드가 AWS 리소스에 액세스해야 하는 경우 Pod Identity에서 자격 증명을 요청합니다. 그런 다음 Pod Identity는 두 가지 역할 가정을 순서대로 자동으로 수행합니다. 먼저 [EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)을 수임한 다음 해당 자격 증명을 사용하여 대상 IAM 역할을 수임합니다. 이 프로세스는 포드에 대상 역할에 정의된 권한이 있는 임시 자격 증명을 제공하여 다른 AWS 계정의 리소스에 대한 보안 액세스를 허용합니다.

## 캐싱 고려 사항
<a name="_caching_considerations"></a>

캐싱 메커니즘으로 인해 기존 Pod Identity 연결의 IAM 역할에 대한 업데이트는 EKS 클러스터에서 실행되는 포드에 즉시 적용되지 않을 수 있습니다. Pod Identity Agent는 자격 증명을 가져올 때 연결의 구성을 기반으로 IAM 자격 증명을 캐싱합니다. 연결에 [EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)만 포함되어 있고 대상 IAM 역할이 없는 경우 캐시된 자격 증명은 6시간 동안 지속됩니다. 연결에 [EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN과 대상 IAM 역할이 모두 포함된 경우 캐시된 자격 증명은 59분 동안 지속됩니다. [EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN 업데이트 또는 대상 IAM 역할 추가와 같은 기존 연결을 수정해도 기존 캐시는 재설정되지 않습니다. 따라서 에이전트는 캐시된 자격 증명이 새로 고쳐질 때까지 업데이트를 인식하지 못합니다. 변경 사항을 더 빨리 적용하려면 기존 포드를 다시 생성할 수 있습니다. 그렇지 않으면 캐시가 만료될 때까지 기다려야 합니다.

## 1단계: 대상 IAM 역할 생성 및 연결
<a name="_step_1_create_and_associate_a_target_iam_role"></a>

이 단계에서는 대상 IAM 역할을 생성하고 구성하여 보안 신뢰 체인을 설정합니다. 데모를 위해 두 AWS 계정 간에 신뢰 체인을 구축하기 위해 새로운 대상 IAM 역할을 생성합니다. EKS 클러스터의 AWS 계정에 있는 [EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)(예: `eks-pod-identity-primary-role`)은 대상 계정에서 대상 IAM 역할(예: `eks-pod-identity-aws-resources`)을 수행할 수 있는 권한을 얻어 Amazon S3 버킷과 같은 AWS 리소스에 액세스할 수 있습니다.

### 대상 IAM 역할 생성
<a name="_create_the_target_iam_role"></a>

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

1. 상단 탐색 모음에서 대상 IAM 역할에 대한 AWS 리소스(예: S3 버킷 또는 DynamoDB 테이블)가 포함된 계정에 로그인했는지 확인합니다.

1. 왼쪽 탐색 창에서 **역할**을 선택합니다.

1. **역할 생성** 버튼을 선택하고 ‘신뢰할 수 있는 엔터티 유형’ 아래에서 **AWS 계정**을 선택합니다.

1. **다른 AWS 계정**을 선택하고 AWS 계정 번호([EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)이 있는 계정)를 입력한 후 **다음**을 선택합니다.

1. 역할에 연결하려는 권한 정책(예: AmazonS3FullAccess)을 추가하고 **다음**을 선택합니다.

1. `MyCustomIAMTargetRole` 등의 역할 이름을 입력하고 **역할 생성**을 선택합니다.

### 대상 IAM 역할 신뢰 정책 업데이트
<a name="_update_the_target_iam_role_trust_policy"></a>

1. 역할을 생성한 후 **역할** 목록으로 돌아갑니다. 이전 단계에서 생성한 새 역할(`MyCustomIAMTargetRole`)을 찾아 선택합니다.

1. **신뢰 관계** 탭을 선택합니다.

1. 오른쪽에서 **신뢰 정책 편집**을 클릭합니다.

1. 정책 편집기에서 기본 JSON을 신뢰 정책으로 바꿉니다. IAM 역할 ARN의 역할 이름 및 `111122223333`에 대한 자리 표시자 값을 EKS 클러스터를 호스팅하는 AWS 계정 ID로 바꿉니다. 역할 신뢰 정책에서 PrincipalTags를 사용하여 지정된 클러스터 및 네임스페이스의 특정 서비스 계정만 대상 역할을 수임할 수 있도록 권한을 부여할 수도 있습니다. 예제:

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
          "aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
          "aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
        },
        "ArnEquals": {
          "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
        }
      }
    }
  ]
}
```

위의 정책에서는 관련 [EKS Pod Identity 세션 태그](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html)가 있는 AWS 계정 111122223333의 `eks-pod-identeity-primary-role` 역할이 이 역할을 수임하도록 허용합니다.

EKS Pod Identity에서 [세션 태그를 비활성화](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags)한 경우 EKS Pod Identity는 대상 역할을 수임할 때 포드의 클러스터, 네임스페이스 및 서비스 계정에 대한 정보로 `sts:ExternalId` 역시 설정합니다.

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
        },
        "ArnEquals": {
          "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:TagSession"
    }
  ]
}
```

위의 정책은 올바른 클러스터, 네임스페이스 및 서비스 계정만 대상 역할을 수임할 수 있도록 하는 데 도움이 됩니다.

### EKS Pod Identity 역할에 대한 권한 정책 업데이트
<a name="_update_the_permission_policy_for_eks_pod_identity_role"></a>

이 단계에서는 대상 IAM 역할 ARN을 리소스로 추가하여 Amazon EKS 클러스터와 연결된 [EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)의 권한 정책을 업데이트합니다.

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

1. 왼쪽 탐색 창에서 **클러스터**를 선택하고 EKS 클러스터의 이름을 선택합니다.

1. **액세스** 탭을 선택합니다.

1. **Pod Identity 연결**에서 [EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)을 선택합니다.

1. **권한**, **권한 추가**, **인라인 정책 생성**을 차례로 선택합니다.

1. 오른쪽에서 **JSON**을 선택합니다.

1. 정책 편집기에서 기본 JSON을 권한 정책으로 바꿉니다. IAM 역할 ARN의 역할 이름 및 `222233334444`에 대한 자리 표시자 값을 대상 IAM 역할로 바꿉니다. 예제:

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
        }
    ]
}
```

## 2단계: Kubernetes 서비스 계정에 대상 IAM 역할 연결
<a name="_step_2_associate_the_target_iam_role_to_a_kubernetes_service_account"></a>

이 단계에서는 대상 IAM 역할과 EKS 클러스터의 Kubernetes 서비스 계정 간에 연결을 생성합니다.

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

1. 왼쪽 탐색 창에서 **클러스터**를 선택하고 연결을 추가할 클러스터의 이름을 선택합니다.

1. **액세스** 탭을 선택합니다.

1. **Pod Identity 연결**에서 **생성**을 선택합니다.

1. 워크로드가 수임할 **IAM 역할**에서 [EKS Pod Identity 역할](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)을 선택합니다.

1. **대상 IAM 역할**에서 [EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) 역할이 수임할 대상 IAM 역할을 선택합니다.

1. **Kubernetes 네임스페이스** 필드에 연결을 생성하려는 네임스페이스의 이름(예: `my-app-namespace`)을 입력합니다. 이는 서비스 계정이 상주하는 위치를 정의합니다.

1. **Kubernetes 서비스 계정** 필드에 IAM 자격 증명을 사용할 서비스 계정의 이름(예: `my-service-account`)을 입력합니다. 이렇게 하면 IAM 역할이 서비스 계정에 연결됩니다.

1. (선택 사항) Pod Identity가 역할을 수임할 때 자동으로 추가하는 기본 세션 태그를 비활성화하려면 **세션 태그 비활성화**를 선택하세요.

1. (선택 사항) **eotkd IAM 역할**에 연결된 IAM 정책에 정의된 권한 외에 이 Pod Identity 연결에 추가 제한 사항을 적용하도록 IAM 정책을 구성하려면 **세션 정책 구성**을 전환하세요.
**참고**  
1. 세션 정책은 **세션 태그 비활성화** 설정이 선택된 경우에만 적용할 수 있습니다. 2. 세션 정책을 지정하면 정책 제한 사항은 이 Pod Identity 연결에 연결된 **IAM 역할**이 아닌 **대상 IAM 역할**의 권한에 적용됩니다.

1. **생성**을 선택하여 연결을 생성합니다.

# 서비스 계정으로 AWS 서비스에 액세스하도록 포드 구성
<a name="pod-id-configure-pods"></a>

포드가 AWS 서비스에 액세스해야 하는 경우 Kubernetes 서비스 계정을 사용하도록 구성해야 합니다. 서비스 계정은 AWS 서비스에 액세스할 수 있는 권한이 있는 AWS ID 및 액세스 관리(IAM) 역할에 연결되어야 합니다.
+ 기존 클러스터가 있어야 합니다. 아직 없는 경우 [Amazon EKS 시작하기](getting-started.md) 가이드 중 하나를 사용하여 생성할 수 있습니다.
+ 기존 Kubernetes 서비스 계정 및 서비스 계정을 IAM 역할에 연결하는 EKS Pod Identity 연결 포드가 AWS 서비스를 사용하는 데 필요한 권한을 포함하는 연결된 IAM 정책이 역할에 있어야 합니다. 서비스 계정 및 역할을 만들고 구성하는 방법에 대한 자세한 내용을 알아보려면 [Kubernetes 서비스 계정에 IAM 역할 할당](pod-id-association.md) 섹션을 참조하세요.
+ AWS CLI의 최신 버전이 디바이스나 AWS CloudShell에 설치 및 구성되어 있어야 합니다. `aws --version | cut -d / -f2 | cut -d ' ' -f1`을 사용하여 현재 버전을 확인할 수 있습니다. `yum`, `apt-get` 또는 macOS용 Homebrew와 같은 패키지 관리자는 최신 버전의 AWS CLI 이전에 나온 버전이 몇 가지 있을 때도 있습니다. 최신 버전을 설치하려면 AWS 명령줄 인터페이스 사용 설명서에서 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 및 [aws config를 사용하여 빠른 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)을 참조하세요. AWS CloudShell에 설치된 AWS CLI 버전도 최신 버전보다 여러 버전 이전일 수도 있습니다. 업데이트하려면 AWS CloudShell 사용 설명서의 [홈 디렉터리에 AWS CLI 설치하기](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)를 참조하세요.
+ `kubectl` 명령줄 도구는 장치 또는 AWS CloudShell에 설치됩니다. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. 예를 들어, 클러스터 버전이 `1.29`인 경우 `kubectl` 버전 `1.28`, `1.29` 또는 `1.30`를 함께 사용할 수 있습니다. `kubectl`을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.md) 부분을 참조하세요.
+ 클러스터 구성이 포함된 기존 `kubectl` `config` 파일입니다. `kubectl` `config` 파일을 생성하려면 [Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결](create-kubeconfig.md) 섹션을 참조하세요.

  1. 다음 명령을 사용하여 구성을 확인할 포드를 배포할 수 있는 배포 매니페스트를 생성합니다. 예제 값을 사용자의 값으로 바꿉니다.

     ```
     cat >my-deployment.yaml <<EOF
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: my-app
     spec:
       selector:
         matchLabels:
           app: my-app
       template:
         metadata:
           labels:
             app: my-app
         spec:
           serviceAccountName: my-service-account
           containers:
           - name: my-app
             image: public.ecr.aws/nginx/nginx:X.XX
     EOF
     ```

  1. 클러스터에 매니페스트를 배포합니다.

     ```
     kubectl apply -f my-deployment.yaml
     ```

  1. 포드에 필요한 환경 변수가 있는지 확인합니다.

     1. 이전 단계에서 배포와 함께 배포된 포드를 봅니다.

        ```
        kubectl get pods | grep my-app
        ```

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

        ```
        my-app-6f4dfff6cb-76cv9   1/1     Running   0          3m28s
        ```

     1. 포드에 서비스 계정 토큰 파일 탑재가 있는지 확인합니다.

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE:
        ```

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

        ```
        AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE:  /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token
        ```

  1. 역할에 연결된 IAM 정책에서 할당한 권한을 사용하여 포드가 AWS 서비스와 상호 작용할 수 있는지 확인합니다.
**참고**  
포드가 서비스 계정과 연결된 IAM 역할의 AWS 자격 증명을 사용하는 경우 해당 포드의 컨테이너에 있는 AWS CLI나 다른 SDK는 역할이 제공하는 자격 증명을 사용합니다. [Amazon EKS 노드 IAM 역할](create-node-role.md)에 제공된 자격 증명에 대한 액세스를 제한하지 않으면 포드는 계속해서 해당 자격 증명에 액세스할 수 있습니다. 자세한 내용은 [작업자 노드에 할당된 인스턴스 프로필에 대한 액세스 제한](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) 부분을 참조하세요.

     포드가 예상대로 서비스와 상호 작용할 수 없으면 다음 단계를 완료하여 모두 제대로 구성되었는지 확인합니다.

     1. 포드에서 EKS Pod Identity 연결을 통해 IAM 역할을 수임할 수 있도록 지원하는 AWS SDK 버전을 사용하는지 확인합니다. 자세한 내용은 [AWS SDK와 함께 Pod Identity 사용](pod-id-minimum-sdk.md) 섹션을 참조하세요.

     1. 배포에서 서비스 계정을 사용하고 있는지 확인합니다.

        ```
        kubectl describe deployment my-app | grep "Service Account"
        ```

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

        ```
        Service Account:  my-service-account
        ```

# 태그를 기반으로 포드에 AWS 리소스에 대한 액세스 권한 부여
<a name="pod-id-abac"></a>

속성 기반 액세스 제어(ABAC)는 속성을 함께 결합하는 정책을 통해 사용자에게 권한을 부여합니다. EKS Pod Identity는 클러스터 이름, 네임스페이스, 서비스 계정 이름 등의 속성을 사용하여 각 포드의 임시 자격 증명에 태그를 연결합니다. 관리자는 이러한 역할 세션 태그를 사용하여 일치하는 태그를 기반으로 AWS 리소스에 대한 액세스를 허용하여 여러 서비스 계정에서 작업할 수 있는 단일 역할을 작성할 수 있습니다. 역할 세션 태그에 대한 지원을 추가함으로써 동일한 IAM 역할과 IAM 정책을 재사용하면서 클러스터 간 및 클러스터 내 워크로드 간에 더 엄격한 보안 경계를 적용할 수 있습니다.

## 태그가 있는 샘플 정책
<a name="_sample_policy_with_tags"></a>

다음은 해당 객체에 EKS 클러스터 이름으로 태그가 지정되었을 때 `s3:GetObject` 권한을 부여하는 IAM 정책 예제입니다.

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectTagging"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
                }
            }
        }
    ]
}
```

## 세션 태그 활성화 또는 비활성화
<a name="pod-id-abac-tags"></a>

EKS Pod Identity는 역할을 수임할 때 사전 정의된 세션 태그 세트를 추가합니다. 관리자는 이러한 세션 태그를 사용하여 일치하는 태그를 기반으로 AWS 리소스에 대한 액세스를 허용하여 여러 리소스에서 작업할 수 있는 단일 역할을 작성할 수 있습니다.

### 세션 태그 활성화
<a name="_enable_session_tags"></a>

세션 태그는 EKS Pod Identity에서 자동으로 활성화되므로 사용자가 별도의 조치를 취할 필요가 없습니다. 기본적으로 EKS Pod Identity는 미리 정의된 태그 세트를 세션에 연결합니다. 정책에서 이러한 태그를 참조하려면 구문 `${aws:PrincipalTag/`와 태그 키를 사용합니다. 예를 들어 `${aws:PrincipalTag/kubernetes-namespace}`입니다.
+  `eks-cluster-arn` 
+  `eks-cluster-name` 
+  `kubernetes-namespace` 
+  `kubernetes-service-account` 
+  `kubernetes-pod-name` 
+  `kubernetes-pod-uid` 

### 세션 태그 비활성화
<a name="_disable_session_tags"></a>

 AWS는 인라인 세션 정책, 관리형 정책 ARN 및 세션 태그를 별도의 제한이 있는 압축된 바이너리 형식으로 압축합니다. 압축된 바이너리 형식이 크기 제한을 초과했다는 `PackedPolicyTooLarge` 오류가 발생하면 EKS Pod Identity에서 추가한 세션 태그를 비활성화하여 크기를 줄여볼 수 있습니다. 이러한 세션 태그를 비활성화하려면 다음 단계를 따르세요.

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

1. 왼쪽 탐색 창에서 **클러스터**를 선택한 다음 수정할 클러스터의 이름을 선택합니다.

1. **액세스** 탭을 선택합니다.

1. **Pod Identity 연결**의 **연결 ID**에서 수정하려는 연결 ID를 선택하고 **편집**을 선택합니다.

1. **세션 태그**에서 **세션 태그 비활성화**를 선택합니다.

1. **변경 사항 저장**을 선택합니다.

## 교차 계정 태그
<a name="pod-id-abac-chaining"></a>

EKS Pod Identity에서 추가한 모든 세션 태그는 **전이적이며, 워크로드가 역할을 다른 계정으로 전환하는 데 사용하는 모든 `AssumeRole` 작업에 태그 키와 값이 전달됩니다. 다른 계정의 정책에 이러한 태그를 사용하여 교차 계정 시나리오에서 액세스를 제한할 수 있습니다. 자세한 내용은 IAM 사용 설명서의 [세션 태그를 사용하는 역할 체인](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining)을 참조하세요.**

## 사용자 지정 태그
<a name="pod-id-abac-custom-tags"></a>

EKS Pod Identity는 수행하는 `AssumeRole` 작업에 사용자 지정 태그를 추가할 수 없습니다. 하지만 IAM 역할에 적용하는 태그는 항상 동일한 형식(`${aws:PrincipalTag/` 다음에 키 사용)을 통해 사용 가능합니다(예: `${aws:PrincipalTag/MyCustomTag}`).

**참고**  
`sts:AssumeRole` 요청을 통해 세션에 추가된 태그가 충돌하는 경우 우선시됩니다. 예를 들어, 다음 내용을 가정해 봅니다.  
예를 들어, EKS가 고객 역할을 수임할 때 Amazon EKS가 세션에 `eks-cluster-name` 키와 `my-cluster` 값을 추가한다고 가정하고
IAM 역할에 `my-own-cluster` 값이 있는 `eks-cluster-name` 태그를 추가합니다.
이 경우 전자가 우선하여 `eks-cluster-name` 태그의 값은 `my-cluster`입니다.

# AWS SDK와 함께 Pod Identity 사용
<a name="pod-id-minimum-sdk"></a>

## EKS Pod Identity 보안 인증 정보 사용
<a name="pod-id-using-creds"></a>

EKS Pod Identity 연결의 보안 인증 정보를 사용하려면 코드에서 임의의 AWS SDK를 사용하여 SDK가 포함된 AWS 서비스에 대한 클라이언트를 만들 수 있고, 기본적으로 SDK는 일련의 위치에서 사용할 AWS ID 및 액세서 관리 보안 인증 정보를 검색합니다. 클라이언트를 생성하거나 SDK를 초기화했을 때 보안 인증 정보 공급자를 지정하지 않으면 EKS Pod Identity 보안 인증 정보가 사용됩니다.

이는 기본 보안 인증 정보 체인의 한 단계에서 검색되는 **컨테이너 보안 인증 정보 공급자에 EKS Pod Identity가 추가되기 때문에 가능합니다. 워크로드가 현재 보안 인증 정보 체인의 이전 단계에 있는 보안 인증 정보를 사용하는 경우 동일한 워크로드에 대해 EKS Pod Identity 연결을 구성하더라도 해당 보안 인증 정보는 계속 사용됩니다.

EKS Pod Identity 작동 방식에 대한 자세한 내용은 [EKS Pod Identity 작동 방식 이해](pod-id-how-it-works.md) 섹션을 참조하세요.

[EKS Pod Identity가 포드에 AWS 서비스 액세스 권한을 부여하는 방법 알아보기](pod-identities.md) 사용 시 포드의 컨테이너는 EKS Pod Identity 에이전트에서 IAM 역할을 수임하는 것을 지원하는 AWS SDK 버전을 사용해야 합니다. AWS SDK에 대해 다음과 같은 버전 또는 이후 버전을 사용해야 합니다.
+ Java(버전 2) – [2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30) 
+ Java – [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746) 
+ Go v1 – [v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11) 
+ Go v2 – [release-2023-11-14](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14) 
+ Python(Boto3) – [1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41) 
+ Python(botocore) - [1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41) 
+  AWS CLI – [1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0) 

   AWS CLI – [2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0) 
+ JavaScript v2 – [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0) 
+ JavaScript v3 - [v3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0) 
+ Kotlin - [v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1) 
+ Ruby – [3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22) 
+ Rust - [release-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13) 
+ C\$1\$1 - [1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263) 
+ .NET - [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0) 
+ PowerShell - [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502) 
+ PHP – [3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.287.1) 

지원되는 SDK를 사용 중인지 확인하려면 컨테이너를 빌드할 때 [AWS에서의 구축을 위한 도구](https://aws.amazon.com/tools/)에서 선호하는 SDK에 대한 설치 지침을 따르세요.

EKS Pod Identity를 지원하는 추가 기능 목록은 [Pod Identity 지원 참조](retreive-iam-info.md#pod-id-add-on-versions) 섹션을 참조하세요.

# EKS Pod Identity 에이전트에서 `IPv6` 비활성화
<a name="pod-id-agent-config-ipv6"></a>

## AWS Management Console
<a name="pod-id-console"></a>

1. EKS Pod Identity 에이전트에서 `IPv6`를 비활성화하려면 EKS 추가 기능의 **선택적 구성 설정**에 다음 구성을 추가합니다.

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

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

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

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

   1. **EKS Pod Identity 에이전트 구성** 페이지에서

      1. 사용할 **버전**을 선택합니다. 이전 단계와 동일한 버전을 유지하고 별도의 작업으로 버전과 구성을 업데이트하는 것이 좋습니다.

      1. **선택적 구성 설정**을 확장합니다.

      1. **구성 값**에 중첩 JSON 객체의 JSON 키 `"agent":` 및 값과 키 `"additionalArgs":`를 입력합니다. 결과 텍스트는 유효한 JSON 객체여야 합니다. 이 키와 값이 텍스트 상자의 유일한 데이터인 경우, 키와 값을 중괄호(`{ }`)로 둘러쌉니다. 다음 예시는 네트워크 정책이 활성화된 것을 보여줍니다.

         ```
         {
             "agent": {
                 "additionalArgs": {
                     "-b": "169.254.170.23"
                 }
             }
         }
         ```

         이 구성은 `IPv4` 주소를 에이전트가 사용하는 유일한 주소로 설정합니다.

   1. EKS Pod Identity 에이전트 포드를 바꿔서 새 구성을 적용하려면 **변경 사항 저장**을 선택합니다.

      Amazon EKS는 EKS Pod Identity 에이전트용 Kubernetes `DaemonSet`의 *롤아웃*을 사용하여 EKS 추가 기능에 변경 사항을 적용합니다. AWS Management Console의 추가 기능 **업데이트 기록**과 `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`을 사용하여 롤아웃 상태를 추적할 수 있습니다.

       `kubectl rollout`에는 다음 명령이 있습니다.

      ```
      $ kubectl rollout
      
      history  -- View rollout history
      pause    -- Mark the provided resource as paused
      restart  -- Restart a resource
      resume   -- Resume a paused resource
      status   -- Show the status of the rollout
      undo     -- Undo a previous rollout
      ```

      롤아웃이 너무 오래 걸리면 Amazon EKS가 롤아웃을 취소하고 유형이 **추가 기능 업데이트**이고 상태가 **실패**인 메시지가 추가 기능의 **업데이트 기록**에 추가됩니다. 문제를 조사하려면 롤아웃 기록부터 시작하고 EKS Pod Identity 에이전트 포드에서 `kubectl logs`를 실행하여 EKS Pod Identity 에이전트의 로그를 확인합니다.

1. **업데이트 기록**의 새 항목 상태가 **성공**이면 롤아웃이 완료되었으며 추가 기능이 모든 EKS Pod Identity 에이전트 포드에서 새 구성을 사용하고 있는 것입니다.

## AWS CLI
<a name="pod-id-cli"></a>

1. EKS Pod Identity 에이전트에서 `IPv6`를 비활성화하려면 EKS 추가 기능의 **구성 값**에 다음 구성을 추가합니다.

   다음 AWS CLI 명령을 실행합니다. `my-cluster`를 본인의 클러스터 이름으로 바꾸고 IAM 역할 ARN을 사용 중인 역할로 바꿉니다.

   ```
   aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \
       --resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}'
   ```

   이 구성은 `IPv4` 주소를 에이전트가 사용하는 유일한 주소로 설정합니다.

   Amazon EKS는 EKS Pod Identity 에이전트용 Kubernetes DaemonSet의 *롤아웃*을 사용하여 EKS 추가 기능에 변경 사항을 적용합니다. AWS Management Console의 추가 기능 **업데이트 기록**과 `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`을 사용하여 롤아웃 상태를 추적할 수 있습니다.

    `kubectl rollout`에는 다음 명령이 있습니다.

   ```
   kubectl rollout
   
   history  -- View rollout history
   pause    -- Mark the provided resource as paused
   restart  -- Restart a resource
   resume   -- Resume a paused resource
   status   -- Show the status of the rollout
   undo     -- Undo a previous rollout
   ```

   롤아웃이 너무 오래 걸리면 Amazon EKS가 롤아웃을 취소하고 유형이 **추가 기능 업데이트**이고 상태가 **실패**인 메시지가 추가 기능의 **업데이트 기록**에 추가됩니다. 문제를 조사하려면 롤아웃 기록부터 시작하고 EKS Pod Identity 에이전트 포드에서 `kubectl logs`를 실행하여 EKS Pod Identity 에이전트의 로그를 확인합니다.

# EKS Pod Identity에서 요구하는 신뢰 정책으로 IAM 역할 생성
<a name="pod-id-role"></a>

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

 ** `sts:AssumeRole` **   
EKS Pod Identity는 `AssumeRole`을 사용하여 임시 보안 인증 정보를 포드에 전달하기 전에 IAM 역할을 맡습니다.

 ** `sts:TagSession` **   
EKS Pod Identity는 `TagSession`을 사용하여 **세션 태그를 AWS STS 요청에 포함합니다.

 **조건 설정**   
신뢰 정책의 *조건 키*에서 이러한 태그를 사용하여 이 역할을 사용할 수 있는 서비스 계정, 네임스페이스, 클러스터를 제한할 수 있습니다. Pod Identity가 추가하는 요청 태그 목록은 [세션 태그 활성화 또는 비활성화](pod-id-abac.md#pod-id-abac-tags) 섹션을 참조하세요.  
예를 들어, `Condition`이 추가된 다음 신뢰 정책을 사용하여 Pod Identity IAM 역할을 수임할 수 있는 포드를 특정 `ServiceAccount` 및 `Namespace`로 제한할 수 있습니다.

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/kubernetes-namespace": [
                        "Namespace"
                    ],
                    "aws:RequestTag/kubernetes-service-account": [
                        "ServiceAccount"
                    ]
                }
            }
        }
    ]
}
```

Amazon EKS 조건 키 목록을 보려면 *서비스 인증 참조*의 [Amazon Elastic Kubernetes Service의 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys)를 참조하세요. 조건 키를 사용할 수 있는 작업과 리소스를 알아보려면 [Amazon Elastic Kubernetes Service에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)을 참조하세요.