**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# Amazon EKS에서 액세스 제어가 작동하는 방식 알아보기
Amazon EKS 클러스터에 대한 액세스를 관리하는 방법을 알아봅니다. Amazon EKS를 사용하려면 Kubernetes 및 AWS Identity and Access Management(AWS IAM) 액세스 처리 방법을 모두 알고 있어야 합니다.
**이 섹션에는 다음 내용이 포함되어 있습니다.**
** [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](grant-k8s-access.md) ** - 애플리케이션 또는 사용자가 Kubernetes API에 인증할 수 있도록 설정하는 방법을 알아봅니다. 액세스 항목, aws-auth ConfigMap 또는 외부 OIDC 공급자를 사용할 수 있습니다.
** [AWS Management Console에서 Kubernetes 리소스 보기](view-kubernetes-resources.md) ** - Amazon EKS 클러스터와 통신하도록 AWS Management Console을 구성하는 방법을 알아봅니다. 콘솔을 사용하여 클러스터의 Kubernetes 리소스(예: 네임스페이스, 노드 및 포드)를 확인합니다.
**[Kubernetes API에 대한 쓰기 액세스 권한을 AWS 서비스에 부여](mutate-kubernetes-resources.md)** - Kubernetes 리소스를 수정하는 데 필요한 권한에 대해 알아봅니다.
** [Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결](create-kubeconfig.md) ** - Amazon EKS 클러스터와 통신하도록 kubectl을 구성하는 방법을 알아봅니다. AWS CLI를 사용하여 kubeconfig 파일을 생성할 수 있습니다.
** [Kubernetes 서비스 계정을 사용하여 Kubernetes 워크로드에 AWS에 대한 액세스 권한 부여](service-accounts.md) ** - Kubernetes 서비스 계정과 AWS IAM 역할을 연결하는 방법을 알아봅니다. Pod Identity 또는 서비스 계정에 대한 IAM 역할(IRSA)을 사용할 수 있습니다.
## 일반적인 작업
+ 개발자에게 Kubernetes API에 대한 액세스 권한을 부여합니다. AWS Management Console에서 Kubernetes 리소스를 봅니다.
+ 해결 방법: [액세스 항목을 사용](access-entries.md)하여 Kubernetes RBAC 권한을 AWS IAM 사용자 또는 역할과 연결합니다.
+ AWS 자격 증명을 사용하여 Amazon EKS 클러스터와 통신하도록 kubectl을 구성합니다.
+ 해결 방법: AWS CLI를 사용하여[ kubeconfig 파일을 생성](create-kubeconfig.md)합니다.
+ Ping Identity와 같은 외부 ID 제공업체를 사용하여 Kubernetes API에 대해 사용자를 인증합니다.
+ 해결 방법: [외부 OIDC 공급자를 연결](authenticate-oidc-identity-provider.md)합니다.
+ Kubernetes 클러스터의 워크로드에 AWS API를 직접적으로 직접 호출하는 기능을 부여합니다.
+ 해결 방법: [Pod Identity를 사용](pod-identities.md)하여 AWS IAM 역할을 Kubernetes 서비스 계정에 연결합니다.
## 배경
+ [Kubernetes 서비스 계정의 작동 방식을 알아봅니다.](https://kubernetes.io/docs/concepts/security/service-accounts/)
+ [Kubernetes 역할 기반 액세스 제어(RBAC) 모델 검토](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+ AWS 리소스에 대한 액세스를 관리하는 방법에 자세한 내용은 [AWS IAM 사용 설명서](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html)를 참조하세요. 또는 [AWS IAM 사용에 대한 무료 입문 교육](https://explore.skillbuilder.aws/learn/course/external/view/elearning/120/introduction-to-aws-identity-and-access-management-iam)을 수강할 수도 있습니다.
## EKS Auto Mode 고려 사항
EKS Auto Mode는 EKS Pod Identity 및 EKS EKS 액세스 항목과 통합됩니다.
+ EKS Auto Mode는 액세스 항목을 사용하여 EKS 컨트롤 플레인 Kubernetes 권한을 부여합니다. 예를 들어 액세스 정책은 EKS Auto Mode가 네트워크 엔드포인트 및 서비스에 대한 정보를 읽을 수 있게 합니다.
+ EKS Auto Mode 클러스터에서는 액세스 항목을 비활성화할 수 없습니다.
+ 선택적으로 `aws-auth` `ConfigMap`을 활성화할 수 있습니다.
+ EKS Auto Mode의 액세스 항목은 자동으로 구성됩니다. 이러한 액세스 항목은 볼 수 있지만 수정할 수는 없습니다.
+ NodeClass를 사용하여 사용자 지정 노드 IAM 역할을 생성하는 경우 AmazonEKSAutoNodePolicy 액세스 정책을 사용하여 역할에 대한 액세스 항목을 생성해야 합니다.
+ AWS 서비스에 대한 워크로드 권한을 부여하려면 EKS Pod Identity를 사용합니다.
+ EKS Auto Mode 클러스터에 Pod Identity 에이전트를 설치할 필요가 없습니다.
# IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여
클러스터에는 Kubernetes API 엔드포인트가 있습니다. Kubectl은 이 API를 사용합니다. 다음 두 유형의 ID를 사용하여 이 API에 인증할 수 있습니다.
+ **AWS ID 및 액세스 관리(IAM) *보안 주체*(역할 또는 사용자)** - 이 유형에는 IAM에 대한 인증이 필요합니다. 자격 증명 소스를 통해 제공된 보안 인증 정보를 사용하여 [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 사용자 또는 [페더레이션 ID](https://aws.amazon.com/identity/federation/)로 AWS에 로그인할 수 있습니다. 관리자가 이전에 IAM 역할을 사용하여 ID 페더레이션을 설정한 경우 페더레이션형 ID로만 로그인할 수 있습니다. 페더레이션을 사용하여 AWS에 액세스하면 간접적으로 [역할을 수임](https://docs.aws.amazon.com/IAM/latest/UserGuide/when-to-use-iam.html#security-iam-authentication-iamrole)합니다. 이 유형의 ID를 사용하는 경우 다음을 수행할 수 있습니다.
+ 클러스터의 Kubernetes 객체에서 작업할 수 있도록 Kubernetes 권한을 할당할 수 있습니다. 클러스터의 Kubernetes 객체에 액세스할 수 있도록 IAM 위탁자에 권한을 할당하는 방법에 대한 자세한 내용은 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 섹션을 참조하세요.
+ Amazon EKS API, AWS CLI, AWS CloudFormation, AWS Management Console 또는 `eksctl`을 사용하여 Amazon EKS 클러스터 및 해당 리소스에서 작업할 수 있도록 IAM 권한을 할당할 수 있습니다. 자세한 내용은 서비스 권한 부여 참조에서 [Amazon Elastic Kubernetes Service에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)을 참조하세요.
+ 노드는 IAM 역할을 수임하여 클러스터에 조인합니다. IAM 보안 주체를 사용하는 클러스터에 액세스하는 기능은 [Kubernetes용 AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme)에서 제공되며, Amazon EKS 컨트롤 플레인에서 실행됩니다.
+ **자체 OpenID Connect(OIDC) 제공자의 사용자** - 이 유형은 [OIDC](https://openid.net/connect/) 제공자에 대한 인증이 필요합니다. Amazon EKS 클러스터에서 자체 OIDC 제공자를 설정하는 방법에 대한 자세한 내용은 [외부 OIDC 제공자를 통해 사용자에게 Kubernetes에 대한 액세스 권한 부여](authenticate-oidc-identity-provider.md) 섹션을 참조하세요. 이 유형의 ID를 사용하는 경우 다음을 수행할 수 있습니다.
+ 클러스터의 Kubernetes 객체에서 작업할 수 있도록 Kubernetes 권한을 할당할 수 있습니다.
+ Amazon EKS API, AWS CLI, AWS CloudFormation, AWS Management Console 또는 `eksctl`을 사용하여 Amazon EKS 클러스터 및 해당 리소스에서 작업할 수 있도록 IAM 권한을 할당할 수 없습니다.
클러스터에서는 두 가지 유형의 ID를 모두 사용할 수 있습니다. IAM 인증 방법은 비활성화할 수 없습니다. OIDC 인증 방법은 선택 사항입니다.
## IAM 자격 증명을 Kubernetes 권한과 연결
[Kubernetes용 AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme)는 클러스터의 컨트롤 플레인에 설치됩니다. [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)(IAM) 위탁자(역할 및 사용자)가 클러스터의 Kubernetes 리소스에 액세스할 수 있습니다. 다음 방법 중 하나를 사용하여 IAM 위탁자가 클러스터의 Kubernetes 객체에 액세스하도록 허용할 수 있습니다.
+ **액세스 항목 생성** - 클러스터가 클러스터의 Kubernetes 버전의 [사전 조건](access-entries.md) 섹션에 나열된 플랫폼 버전 이상인 경우 이 옵션을 사용하는 것이 좋습니다.
*액세스 항목*을 사용하여 클러스터 외부에서 IAM 위탁자의 Kubernetes 권한을 관리합니다. EKS API, AWS 명령줄 인터페이스, AWS SDK, AWS CloudFormation 및 AWS Management Console를 사용하여 클러스터에 대한 액세스를 추가하고 관리할 수 있습니다. 즉, 클러스터를 생성할 때 사용한 것과 동일한 도구로 사용자를 관리할 수 있습니다.
시작하려면 [인증 모드를 액세스 항목을 사용하도록 변경](setting-up-access-entries.md)에 따라 [기존 aws-auth ConfigMap 항목을 액세스 항목으로 마이그레이션](migrating-access-entries.md)합니다.
+ **`aws-auth` `ConfigMap`에 항목 추가**-클러스터의 플랫폼 버전이 [사전 조건](access-entries.md) 섹션에 나열된 버전 이하인 경우 이 옵션을 사용해야 합니다. 클러스터의 플랫폼 버전이 클러스터의 Kubernetes 버전의 [사전 조건](access-entries.md) 섹션에 나열된 플랫폼 버전 이상이고 `ConfigMap`에 항목을 추가한 경우 해당 항목을 액세스 항목으로 마이그레이션하는 것이 좋습니다. 그러나 관리형 노드 그룹 또는 Fargate 프로필과 함께 사용되는 IAM 역할 항목과 같이 Amazon EKS가 `ConfigMap`에 추가한 항목은 마이그레이션할 수 없습니다. 자세한 내용은 [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](#grant-k8s-access) 섹션을 참조하세요.
+ `aws-auth` `ConfigMap` 옵션을 사용해야 하는 경우 `eksctl create iamidentitymapping` 명령을 사용하여 `ConfigMap`에 항목을 추가할 수 있습니다. 자세한 내용은 `eksctl` 설명서의 [IAM 사용자 및 역할 관리](https://eksctl.io/usage/iam-identity-mappings/)를 참조하세요.
## 클러스터 인증 모드 설정
각 클러스터에는 *인증 모드*가 있습니다. 인증 모드는 IAM 위탁자가 클러스터의 Kubernetes 객체에 액세스하도록 허용하는 데 사용할 수 있는 방법을 결정합니다. 세 가지 인증 모드가 있습니다.
**중요**
액세스 항목 방법을 활성화한 후에는 비활성화할 수 없습니다.
클러스터 생성 중에 `ConfigMap` 방법을 활성화하지 않으면 나중에 활성화할 수 없습니다. 액세스 항목이 도입되기 전에 생성된 모든 클러스터에는 `ConfigMap` 메서드가 활성화되어 있습니다.
클러스터에서 하이브리드 노드를 사용하는 경우 `API` 또는 `API_AND_CONFIG_MAP` 클러스터 인증 모드를 사용해야 합니다.
**클러스터 내부 `aws-auth` `ConfigMap` **
Amazon EKS 클러스터의 원래 인증 모드입니다. 클러스터를 생성한 IAM 보안 주체는 `kubectl`을 사용하여 클러스터에 액세스할 수 있는 초기 사용자입니다. 초기 사용자는 `aws-auth` `ConfigMap`에서 목록에 다른 사용자를 추가하고 클러스터 내 다른 사용자에게 영향을 주는 권한을 할당해야 합니다. `ConfigMap`에 관리할 항목이 없기 때문에 이러한 다른 사용자는 초기 사용자를 관리하거나 제거할 수 없습니다.
**`ConfigMap` 및 액세스 항목 모두**
이 인증 모드에서는 두 가지 방법을 모두 사용하여 클러스터에 IAM 보안 주체를 추가할 수 있습니다. 각 방법에서는 별도의 항목을 저장합니다. 예를 들어, AWS CLI에서 액세스 항목을 추가하는 경우 `aws-auth` `ConfigMap`이 업데이트되지 않습니다.
**액세스 항목만**
이 인증 모드에서는 EKS API, AWS 명령줄 인터페이스, AWS SDK, AWS CloudFormation 및 AWS Management Console을 사용하여 IAM 보안 주체의 클러스터에 대한 액세스를 관리할 수 있습니다.
각 액세스 항목에는 *유형*이 있으며, 보안 주체를 특정 네임스페이스로 제한하는 *액세스 범위*와 사전 구성된 재사용 가능한 권한 정책을 설정하는 *액세스 정책*을 조합하여 사용할 수 있습니다. 또는 STANDARD 유형 및 Kubernetes RBAC 그룹을 사용하여 사용자 지정 권한을 할당할 수 있습니다.
| 인증 모드 | 메서드 |
| --- | --- |
| `ConfigMap`만 해당(`CONFIG_MAP`) | `aws-auth` `ConfigMap` |
| EKS API 및 `ConfigMap`(`API_AND_CONFIG_MAP`) | EKS API, AWS 명령줄 인터페이스, AWS SDKs, AWS CloudFormation 및 AWS Management Console 및 `aws-auth` `ConfigMap`의 액세스 항목 |
| EKS API만 해당(`API`) | EKS API, AWS 명령줄 인터페이스, AWS SDKs, AWS CloudFormation 및 AWS Management Console의 액세스 항목 |
**참고**
Amazon EKS Auto Mode에는 액세스 항목이 필요합니다.
# EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여
이 섹션은 액세스 항목 및 정책을 사용하여 Amazon EKS(Elastic Kubernetes Service)의 Kubernetes 클러스터에 대한 IAM 보안 주체 액세스를 관리하는 방법을 보여주도록 설계되었습니다. 인증 모드 변경, 레거시 `aws-auth` ConfigMap 항목에서의 마이그레이션, 액세스 항목 생성, 업데이트 및 삭제, 정책과 항목 연결, 사전 정의된 정책 권한 검토, 보안 액세스 관리의 주요 사전 조건 및 고려 사항과 관련된 세부 정보를 확인할 수 있습니다.
## 개요
EKS 액세스 항목은 사용자에게 Kubernetes API에 대한 액세스 권한을 부여하는 가장 좋은 방법입니다. 예를 들어 액세스 항목을 사용하여 개발자에게 kubectl을 사용할 수 있는 액세스 권한을 부여할 수 있습니다. 기본적으로 EKS 액세스 항목은 Kubernetes 권한 세트를 IAM 역할과 같은 IAM 자격 증명에 연결합니다. 예를 들어 개발자는 IAM 역할을 수임하고 이를 사용하여 EKS 클러스터에 대해 인증할 수 있습니다.
## Features
+ **중앙 집중식 인증 및 권한 부여**: Amazon EKS API를 통해 Kubernetes 클러스터 액세스를 직접 제어하므로 사용자 권한에 있어 AWS와 Kubernetes API 간에 전환할 필요가 없습니다.
+ **세분화된 권한 관리**: 생성자로부터 클러스터 관리자 액세스 수정 또는 취소를 비롯해 AWS IAM 보안 주체의 세분화된 권한을 정의하는 액세스 항목 및 정책을 사용합니다.
+ **IaC 도구 통합**: AWS CloudFormation, Terraform 및 AWS CDK와 같은 코드형 인프라 도구와의 통합으로 클러스터 생성 도중 액세스 구성 정의가 지원됩니다.
+ **잘못된 구성 복구**: 직접 Kubernetes API 액세스 없이 Amazon EKS API를 통해 클러스터 액세스를 복원할 수 있습니다.
+ **오버헤드 감소 및 보안 강화**: CloudTrail 감사 로깅 및 다중 인증과 같은 AWS IAM 기능을 활용하면서 작업을 중앙 집중화하여 오버헤드를 줄입니다.
## 권한 연결 방법
두 가지 방법으로 액세스 항목에 Kubernetes 권한을 연결할 수 있습니다.
+ 액세스 정책을 추가합니다. 액세스 정책은 AWS에서 유지 관리하는 사전 정의된 Kubernetes 권한 템플릿입니다. 자세한 내용은 [액세스 정책 권한 검토](access-policy-permissions.md) 섹션을 참조하세요.
+ Kubernetes 그룹을 참조합니다. IAM 자격 증명을 Kubernetes 그룹에 연결하는 경우 그룹 권한을 부여하는 Kubernetes 리소스를 생성할 수 있습니다. 자세한 내용은 Kubernetes 문서의 [Using RBAC Authorization(RBAC 승인 사용)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 참조하세요.
## 고려 사항
기존 클러스터에서 EKS 액세스 항목을 활성화할 때 유의해야 할 사항:
+ **레거시 클러스터 동작**: 액세스 항목 도입 전에 생성된 클러스터(초기 플랫폼 버전이 [플랫폼 버전 요구 사항](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)에 지정된 버전보다 낮은 클러스터)의 경우 EKS는 기존 권한을 반영하는 액세스 항목을 자동으로 생성합니다. 이 항목에는 기존 클러스터를 생성한 IAM ID와 클러스터 생성 중에 해당 ID에 부여된 관리 권한이 포함됩니다.
+ **레거시 `aws-auth` ConfigMap 처리**: 클러스터가 액세스 관리에 레거시 `aws-auth` ConfigMap을 사용하는 경우 액세스 항목을 활성화하면 기존 클러스터 생성자의 액세스 항목만 자동으로 생성됩니다. ConfigMap에 추가된 추가 역할 또는 권한(예: 개발자 또는 서비스에 대한 사용자 지정 IAM 역할)은 자동으로 마이그레이션되지 않습니다. 이 문제를 해결하려면 해당 액세스 항목을 수동으로 생성합니다.
## 시작
1. 사용할 IAM 자격 증명 및 액세스 정책을 결정하세요.
+ [액세스 정책 권한 검토](access-policy-permissions.md)
1. 클러스터에서 EKS 액세스 항목을 활성화하세요. 지원되는 플랫폼 버전이 있는지 확인하세요.
+ [액세스 항목을 사용하도록 인증 모드 변경](setting-up-access-entries.md)
1. IAM 자격 증명을 Kubernetes 권한에 연결하는 액세스 항목을 생성하세요.
+ [액세스 항목 생성](creating-access-entries.md)
1. IAM 자격 증명을 사용하여 클러스터에 대해 인증하세요.
+ [AWS CLI 설정](install-awscli.md)
+ [`kubectl` 및 `eksctl` 설정](install-kubectl.md)
# 액세스 정책을 액세스 항목과 연결
`STANDARD` *유형*의 *액세스 항목*에 하나 이상의 액세스 정책을 할당할 수 있습니다. Amazon EKS는 클러스터에서 제대로 작동하는 데 필요한 권한을 다른 유형의 액세스 항목에 자동으로 부여합니다. Amazon EKS 액세스 정책에는 IAM 권한이 아니라 Kubernetes 권한이 포함됩니다. 액세스 정책을 액세스 항목에 연결하기 전에 각 액세스 정책에 포함된 Kubernetes 권한에 친숙해야 합니다. 자세한 내용은 [액세스 정책 권한 검토](access-policy-permissions.md) 단원을 참조하십시오. 요구 사항을 충족하는 액세스 정책이 없는 경우 액세스 정책을 액세스 항목에 연결하지 않습니다. 대신 액세스 항목에 대해 하나 이상의 *그룹 이름*을 지정하고 Kubernetes 역할 기반 액세스 제어 객체를 생성하고 관리합니다. 자세한 내용은 [액세스 항목 생성](creating-access-entries.md) 단원을 참조하십시오.
+ 기존 액세스 항목. 파일을 만들려면 [액세스 항목 생성](creating-access-entries.md) 섹션을 참조하세요.
+ `ListAccessEntries`, `DescribeAccessEntry`, `UpdateAccessEntry`, `ListAccessPolicies`, `AssociateAccessPolicy`, `DisassociateAccessPolicy` 권한을 보유한 AWS ID 및 액세서 관리 역할 또는 사용자. 자세한 내용은 *서비스 권한 부여 참조*에서 [Amazon Elastic Kubernetes Service에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)을 참조하세요.
액세스 정책을 액세스 항목에 연결하기 전에 다음 요구 사항을 고려하세요.
+ 각 액세스 항목에 여러 액세스 정책을 연결할 수 있지만 각 정책은 액세스 항목에 한 번만 연결할 수 있습니다. 여러 액세스 정책을 연결하는 경우 액세스 항목의 IAM 보안 주체는 연결된 모든 액세스 정책에 모든 권한을 포함합니다.
+ 클러스터의 모든 리소스에 대한 액세스 정책 범위를 지정하거나 하나 이상의 Kubernetes 네임스페이스 이름을 지정하여 범위를 지정할 수 있습니다. 네임스페이스 이름에 와일드카드 문자를 사용할 수 있습니다. 예를 들어, `dev-`로 시작하는 모든 네임스페이스로 액세스 정책 범위를 지정하려는 경우 네임스페이스 이름으로 `dev-*`를 지정할 수 있습니다. 클러스터에 네임스페이스가 존재하고 철자가 클러스터의 실제 네임스페이스 이름과 일치하는지 확인합니다. Amazon EKS는 클러스터에 있는 네임스페이스의 철자나 존재 여부를 확인하지 않습니다.
+ 액세스 항목에 연결한 후에 액세스 정책의 *액세스 범위*를 변경할 수 있습니다. 액세스 정책의 범위를 Kubernetes 네임스페이스로 지정한 경우 필요에 따라 연결을 위해 네임스페이스를 추가 및 제거할 수 있습니다.
+ *그룹 이름*도 지정된 액세스 항목에 액세스 정책을 연결하는 경우 IAM 보안 주체는 연결된 모든 액세스 정책에 모든 권한을 보유합니다. 또한 그룹 이름을 지정하는 Kubernetes `Role` 및 `RoleBinding` 객체에 지정된 Kubernetes `Role` 또는 `ClusterRole` 객체에 모든 권한을 보유합니다.
+ `kubectl auth can-i --list` 명령을 실행하면 명령을 실행할 때 사용한 IAM 위탁자의 액세스 항목에 연결된 액세스 정책에서 할당한 Kubernetes 권한이 표시되지 않습니다. 이 명령은 액세스 항목에 지정한 그룹 이름 또는 사용자 이름에 바인딩하는 `Role` 또는 `ClusterRole` 객체에 Kubernetes 권한을 부여하는 경우에만 권한을 표시합니다.
+ `kubectl` 명령을 `--as username ` 또는 `--as-group group-name `과 함께 사용하는 등 클러스터에서 Kubernetes 객체와 상호 작용할 때 Kubernetes 사용자 또는 그룹을 가장하면 Kubernetes RBAC 인증을 강제로 사용합니다. 따라서 IAM 보안 주체는 액세스 항목에 연결된 액세스 정책에서 할당한 권한을 보유하지 않습니다. IAM 위탁자가 가장하는 사용자 또는 그룹에 있는 유일한 Kubernetes 권한은 해당 그룹 이름 또는 사용자 이름에 바인딩하는 Kubernetes `Role` 또는 `ClusterRole` 객체에 부여한 Kubernetes 권한입니다. IAM 위탁자가 연결된 액세스 정책의 권한을 보유하려면 Kubernetes 사용자 또는 그룹을 가장하지 않습니다. 또한 IAM 위탁자는 액세스 항목에 지정한 그룹 이름 또는 사용자 이름에 바인딩하는 Kubernetes `Role` 또는 `ClusterRole` 객체에 부여한 권한도 계속 보유합니다. 자세한 내용은 Kubernetes Documentation의 [User impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation)을 참조하세요.
AWS Management Console 또는 AWS CLI를 사용하여 액세스 정책을 액세스 항목에 연결할 수 있습니다.
## AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 액세스 정책을 연결할 액세스 항목이 있는 클러스터 이름을 선택합니다.
1. **액세스** 탭을 선택합니다.
1. 액세스 항목 유형이 **표준**인 경우 Amazon EKS **액세스 정책**을 연결하거나 연결을 해제할 수 있습니다. 액세스 항목 유형이 **표준** 이외의 항목인 경우 이 옵션을 사용할 수 없습니다.
1. **액세스 정책 연결**을 선택합니다.
1. **정책 이름**에서 IAM 보안 주체에 부여하려는 권한이 있는 정책을 선택합니다. 이러한 권한이 포함된 정책을 보려면 [액세스 정책 권한 검토](access-policy-permissions.md) 섹션을 참조하세요.
1. **액세스 범위**에서 액세스 범위를 선택합니다. **클러스터**를 선택하면 액세스 정책의 권한이 모든 Kubernetes 네임스페이스의 리소스에 대한 IAM 위탁자에 부여됩니다. **Kubernetes 네임스페이스**를 선택한 경우 **새 네임스페이스 추가**를 선택할 수 있습니다. 나타나는 **네임스페이스** 필드에 클러스터의 Kubernetes 네임스페이스 이름을 입력할 수 있습니다. IAM 보안 주체가 여러 네임스페이스에 대한 권한을 보유하게 하려면 네임스페이스를 여러 개 입력하면 됩니다.
1. **액세스 정책 추가**를 선택합니다.
## AWS CLI
1. 장치에 설치 및 구성된 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)를 참조하세요.
1. 사용 가능한 액세스 정책을 봅니다.
```
aws eks list-access-policies --output table
```
예제 출력은 다음과 같습니다.
```
---------------------------------------------------------------------------------------------------------
| ListAccessPolicies |
+-------------------------------------------------------------------------------------------------------+
|| accessPolicies ||
|+---------------------------------------------------------------------+-------------------------------+|
|| arn | name ||
|+---------------------------------------------------------------------+-------------------------------+|
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSAdminPolicy | AmazonEKSAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy | AmazonEKSClusterAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSEditPolicy | AmazonEKSEditPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSViewPolicy | AmazonEKSViewPolicy ||
|+---------------------------------------------------------------------+-------------------------------+|
```
이러한 권한이 포함된 정책을 보려면 [액세스 정책 권한 검토](access-policy-permissions.md) 섹션을 참조하세요.
1. 기존 액세스 항목을 확인합니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.
```
aws eks list-access-entries --cluster-name my-cluster
```
예제 출력은 다음과 같습니다.
```
{
"accessEntries": [
"arn:aws:iam::111122223333:role/my-role",
"arn:aws:iam::111122223333:user/my-user"
]
}
```
1. 액세스 정책을 액세스 항목에 연결합니다. 다음 예제에서는 `AmazonEKSViewPolicy` 액세스 정책을 액세스 항목에 연결합니다. *my-role* IAM 역할이 클러스터의 Kubernetes 객체에 액세스를 시도할 때마다 Amazon EKS는 정책에 있는 권한을 사용하여 *my-namespace1* 및 *my-namespace2* Kubernetes 네임스페이스의 Kubernetes 객체에만 액세스할 수 있는 권한을 역할에 부여합니다. *my-cluster*를 클러스터 이름으로, *111122223333*을 AWS 계정 ID로, *my-role*을 Amazon EKS가 Kubernetes 클러스터 객체에 대한 액세스를 승인하려는 IAM 역할의 이름으로 바꿉니다.
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy
```
IAM 보안 주체가 클러스터 전체 권한을 갖게 하려면 `type=namespace,namespaces=my-namespace1,my-namespace2 `를 `type=cluster`로 바꿉니다. 여러 액세스 정책을 액세스 항목에 연결하려면 각각 고유한 액세스 정책을 사용하여 명령을 여러 번 실행합니다. 연결된 각 액세스 정책의 범위는 고유합니다.
**참고**
나중에 연결된 액세스 정책의 범위를 변경하려면 새 범위를 사용하여 이전 명령을 다시 실행합니다. 예를 들어, *my-namespace2*를 제거하려는 경우 `type=namespace,namespaces=my-namespace1 `만 사용하여 명령을 다시 실행합니다. 범위를 `namespace`에서 `cluster`로 변경하려면 `type=cluster`를 사용하여 다시 명령을 실행해 `type=namespace,namespaces=my-namespace1,my-namespace2 `를 제거합니다.
1. 액세스 항목에 연결된 액세스 정책을 결정합니다.
```
aws eks list-associated-access-policies --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
예제 출력은 다음과 같습니다.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333",
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster",
"namespaces": []
},
"associatedAt": "2023-04-17T15:25:21.675000-04:00",
"modifiedAt": "2023-04-17T15:25:21.675000-04:00"
},
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
"accessScope": {
"type": "namespace",
"namespaces": [
"my-namespace1",
"my-namespace2"
]
},
"associatedAt": "2023-04-17T15:02:06.511000-04:00",
"modifiedAt": "2023-04-17T15:02:06.511000-04:00"
}
]
}
```
이전 예제에서 이 액세스 항목의 IAM 위탁자는 클러스터의 모든 네임스페이스에 대한 보기 권한과 두 Kubernetes 네임스페이스에 대한 관리자 권한을 보유합니다.
1. 액세스 항목에서 액세스 정책 연결을 해제합니다. 이 예제에서 `AmazonEKSAdminPolicy` 정책은 액세스 항목과 연결이 해제되었습니다. 하지만 IAM 보안 주체는 *my-namespace1* 및 *my-namespace2* 네임스페이스의 객체에 대한 `AmazonEKSViewPolicy` 액세스 정책에 있는 권한을 보유합니다. 해당 액세스 정책이 액세스 항목과 연결 해제되지 않았기 때문입니다.
```
aws eks disassociate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy
```
사용 가능한 액세스 정책을 나열하려면 [액세스 정책 권한 검토](access-policy-permissions.md) 섹션을 참조하세요.
# 기존 `aws-auth ConfigMap` 항목을 액세스 항목으로 마이그레이션
클러스터의 `aws-auth` `ConfigMap`에 항목을 추가한 경우 `aws-auth` `ConfigMap`의 기존 항목에 대한 액세스 항목을 생성하는 것이 좋습니다. 액세스 항목을 생성한 후 해당 항목을 `ConfigMap`에서 제거할 수 있습니다. [액세스 정책](access-policies.md)을 `aws-auth` `ConfigMap`의 항목에 연결할 수 없습니다. 액세스 정책을 IAM 보안 주체에 연결하려면 액세스 항목을 생성합니다.
**중요**
클러스터가 `API_AND_CONFIGMAP` 인증 모드에 있고 `aws-auth` `ConfigMap`과 액세스 항목 모두에 동일한 IAM 역할에 대한 매핑이 있는 경우 역할은 인증을 위해 액세스 항목의 매핑을 사용합니다. 액세스 항목은 동일한 IAM 위탁자의 `ConfigMap` 항목보다 우선합니다.
클러스터에 대한 [관리형 노드 그룹](managed-node-groups.md)이나 [Fargate 프로필](fargate-profile.md)을 위해 Amazon EKS에서 생성한 기존 `aws-auth` `ConfigMap` 구성 맵 항목을 제거하기 전에 해당 특정 리소스에 대한 올바른 액세스 항목이 Amazon EKS 클러스터에 존재하는지 다시 확인하세요. 동등한 액세스 항목 없이 Amazon EKS가 `ConfigMap`에서 생성한 항목을 제거하면 클러스터가 제대로 작동하지 않습니다.
## 사전 조건
+ 액세스 항목 및 액세스 정책에 익숙해야 합니다. 자세한 내용은 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 및 [액세스 정책을 액세스 항목과 연결](access-policies.md)(을)를 참조하세요.
+ 기존 클러스터의 플랫폼 버전이 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 주제의 전제 조건에 나열된 버전 이상입니다.
+ 장치에 설치된 `eksctl` 명령줄 도구의 버전 `0.215.0` 이상 또는 AWS CloudShell이 필요합니다. `eksctl`을 설치 또는 업그레이드하려면 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요.
+ `kube-system` 네임스페이스에서 `aws-auth` `ConfigMap`을 수정할 Kubernetes 권한.
+ `CreateAccessEntry` 및 `ListAccessEntries` 권한을 보유한 AWS ID 및 액세서 관리 역할 또는 사용자. 자세한 내용은 서비스 권한 부여 참조에서 [Amazon Elastic Kubernetes Service에서 정의한 작업](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)을 참조하세요.
## `eksctl`
1. `aws-auth ConfigMap`에서 기존 항목을 봅니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.
```
eksctl get iamidentitymapping --cluster my-cluster
```
예제 출력은 다음과 같습니다.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/EKS-my-cluster-Admins Admins system:masters
arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers my-namespace-Viewers Viewers
arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:user/my-user my-user
arn:aws:iam::111122223333:role/EKS-my-cluster-fargateprofile1 system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
arn:aws:iam::111122223333:role/EKS-my-cluster-managed-ng system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. 생성 후 이전 출력에서 반환된 모든 `ConfigMap` 항목에 대해 [액세스 항목 생성](creating-access-entries.md)합니다. 액세스 항목을 생성하는 경우 출력에서 반환된 `ARN`, `USERNAME`, `GROUPS` 및 `ACCOUNT`에 대해 동일한 값을 지정해야 합니다. 예제 출력에서는 Amazon EKS가 Fargate 프로필 및 관리형 노드 그룹에 대한 액세스 항목을 생성했기 때문에 마지막 두 항목을 제외한 모든 항목에 대한 액세스 항목을 생성합니다.
1. 생성한 모든 액세스 항목에 대한 항목을 `ConfigMap`에서 삭제합니다. `ConfigMap`에서 항목을 삭제하지 않으면 IAM 보안 주체 ARN의 액세스 항목 설정이 `ConfigMap` 항목보다 우선합니다. *111122223333*을 사용자 AWS 계정 ID로, *EKS-my-cluster-my-namespace-Viewers*를 `ConfigMap` 항목의 역할 이름으로 바꿉니다. IAM 역할이 아닌 IAM 사용자에 대한 항목을 제거하는 경우 `role`을 `user`로, *EKS-my-cluster-my-namespace-Viewers*를 사용자 이름으로 바꿉니다.
```
eksctl delete iamidentitymapping --arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --cluster my-cluster
```
# 액세스 정책 권한 검토
액세스 정책에는 Kubernetes `verbs`(권한) 및 `resources`가 포함된 `rules`가 있습니다. 액세스 정책에는 IAM 권한 또는 리소스가 없습니다. Kubernetes `Role` 및 `ClusterRole` 객체와 마찬가지로 액세스 정책에는 `allow` `rules`만 포함됩니다. 액세스 정책의 콘텐츠는 수정할 수 없습니다. 자체 액세스 정책을 생성할 수 없습니다. 액세스 정책의 권한이 요구 사항에 맞지 않는 경우 Kubernetes RBAC 객체를 생성하고 액세스 항목의 *그룹 이름*을 지정합니다. 자세한 내용은 [액세스 항목 생성](creating-access-entries.md) 섹션을 참조하세요. 액세스 정책에 포함된 권한은 Kubernetes 사용자 대면 클러스터 역할의 권한과 유사합니다. 자세한 내용은 Kubernetes Documentation의 [User-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)를 참조하세요.
## 모든 정책 나열
이 페이지에 나열된 액세스 정책 중 하나를 사용하거나 AWS CLI를 사용하여 사용 가능한 모든 액세스 정책 목록 검색:
```
aws eks list-access-policies
```
예상되는 출력(편의상 간략하게 축소):
```
{
"accessPolicies": [
{
"name": "AmazonAIOpsAssistantPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonAIOpsAssistantPolicy"
},
{
"name": "AmazonARCRegionSwitchScalingPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy"
},
{
"name": "AmazonEKSAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
},
{
"name": "AmazonEKSAdminViewPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy"
},
{
"name": "AmazonEKSAutoNodePolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy"
}
// Additional policies omitted
]
}
```
## AmazonEKSAdminPolicy
이 액세스 정책에는 리소스에 대한 대부분의 권한을 IAM 보안 주체에 부여하는 권한이 포함됩니다. 액세스 항목에 연결된 경우 액세스 범위는 일반적으로 하나 이상의 Kubernetes 네임스페이스입니다. IAM 보안 주체가 클러스터의 모든 리소스에 대한 관리자 액세스 권한을 보유하려면 대신 [AmazonEKSClusterAdminPolicy](#access-policy-permissions-amazoneksclusteradminpolicy) 액세스 정책을 액세스 항목에 연결합니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy`
| Kubernetes API 그룹 | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `authorization.k8s.io` | `localsubjectaccessreviews` | `create` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| `rbac.authorization.k8s.io` | `rolebindings`, `roles` | `create`, `delete`, `deletecollection`, `get`, `list`, `patch`, `update`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`,`list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `serviceaccounts` | `impersonate` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`,`list`, `watch` |
## AmazonEKSClusterAdminPolicy
이 액세스 정책에는 클러스터에 대한 액세스 권한을 IAM 보안 주체 관리자에게 부여하는 권한이 포함됩니다. 액세스 항목에 연결된 경우 액세스 범위는 일반적으로 Kubernetes 네임스페이스가 아닌 클러스터입니다. IAM 보안 주체의 관리 범위를 더 제한하려면 대신 [AmazonEKSAdminPolicy](#access-policy-permissions-amazoneksadminpolicy) 액세스 정책을 액세스 항목에 연결하는 방법을 고려합니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`
| Kubernetes API 그룹 | Kubernetes nonResourceURLs | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- | --- |
| `*` | | `*` | `*` |
| | `*` | | `*` |
## AmazonEKSAdminViewPolicy
이 액세스 정책에는 클러스터의 모든 리소스를 나열하고 볼 수 있는 권한을 IAM 보안 주체에 부여하는 권한이 포함되어 있습니다. 여기에는 [Kubernetes 보안 암호](https://kubernetes.io/docs/concepts/configuration/secret/)가 포함됩니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy`
| Kubernetes API 그룹 | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- |
| `*` | `*` | `get`, `list`, `watch` |
## AmazonEKSEditPolicy
이 액세스 정책에는 IAM 위탁자가 대부분의 Kubernetes 리소스를 편집할 수 있는 권한이 포함되어 있습니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy`
| Kubernetes API 그룹 | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `serviceaccounts` | `impersonate` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
## AmazonEKSViewPolicy
이 액세스 정책에는 IAM 위탁자가 대부분의 Kubernetes 리소스를 볼 수 있는 권한이 포함되어 있습니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy`
| Kubernetes API 그룹 | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, r`esourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
## AmazonEKSSecretReaderPolicy
이 액세스 정책에는 IAM 위탁자가 [Kubernetes 보안 암호](https://kubernetes.io/docs/concepts/configuration/secret/)를 읽을 수 있는 권한이 포함되어 있습니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy`
| Kubernetes API 그룹 | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- |
| | `secrets` | `get`, `list`, `watch` |
## AmazonEKSAutoNodePolicy
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy`
이 정책에는 Amazon EKS 구성 요소가 다음 태스크를 완료할 수 있도록 허용하는 다음과 같은 권한이 포함되어 있습니다.
+ `kube-proxy`-네트워크 엔드포인트 및 서비스를 모니터링하고 관련 이벤트를 관리합니다. 이렇게 하면 클러스터 전반의 네트워크 프록시 기능이 활성화됩니다.
+ `ipamd` - AWS VPC 네트워킹 리소스 및 컨테이너 네트워크 인터페이스(CNI)를 관리합니다. 이렇게 하면 IP 주소 관리 대몬이 포드 네트워킹을 처리할 수 있습니다.
+ `coredns`-엔드포인트 및 서비스와 같은 서비스 검색 리소스에 액세스합니다. 이렇게 하면 클러스터 내에서 DNS 확인이 활성화됩니다.
+ `ebs-csi-driver`-Amazon EBS 볼륨에 대한 스토리지 관련 리소스를 사용합니다. 이를 통해 영구 볼륨의 동적 프로비저닝 및 연결이 가능합니다.
+ `neuron` - AWS Neuron 디바이스의 노드 및 포드를 모니터링합니다. 이를 통해 AWS Inferentia 및 Trainium 액셀러레이터를 관리할 수 있습니다.
+ `node-monitoring-agent`-노드 진단 및 이벤트에 액세스합니다. 이렇게 하면 클러스터 상태 모니터링 및 진단 수집이 활성화됩니다.
각 구성 요소는 전용 서비스 계정을 사용하며 특정 함수에 필요한 권한으로만 제한됩니다.
NodeClass에서 노드 IAM 역할을 수동으로 지정하는 경우 새 노드 IAM 역할을 이 액세스 정책에 연결하는 액세스 항목을 생성해야 합니다.
## AmazonEKSBlockStoragePolicy
**참고**
이 정책은 AWS 서비스 연결 역할에만 지정되며 고객 관리형 역할에는 사용할 수 없습니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSBlockStoragePolicy`
이 정책에는 Amazon EKS가 스토리지 작업에 대한 리더 선택 및 조정 리소스를 관리하는 권한이 포함되어 있습니다.
+ `coordination.k8s.io`-리더 선택을 위해 임대 객체를 생성하고 관리합니다. 이에 따라 EKS 스토리지 구성 요소는 리더 선택 메커니즘을 통해 클러스터 전체에서 활동을 조정할 수 있습니다.
이 정책은 클러스터의 다른 조정 리소스에 대한 액세스 충돌을 방지하기 위해 EKS 스토리지 구성 요소가 사용하는 특정 임대 리소스로 범위가 지정됩니다.
Amazon EKS는 Auto Mode가 활성화되면 클러스터 IAM 역할에 대한 이 액세스 정책으로 액세스 항목을 자동으로 생성하여 블록 스토리지 기능이 제대로 작동하는 데 필요한 권한이 있는지 확인합니다.
## AmazonEKSLoadBalancingPolicy
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSLoadBalancingPolicy`
이 정책에는 Amazon EKS가 로드 밸런싱을 위한 리더 선택 리소스를 관리하는 권한이 포함되어 있습니다.
+ `coordination.k8s.io`-리더 선택을 위해 임대 객체를 생성하고 관리합니다. 이를 통해 EKS 로드 밸런싱 구성 요소는 리더를 선택하여 여러 복제본에서 활동을 조정할 수 있습니다.
이 정책은 특히 로드 밸런싱 임대 리소스에 적용되어 클러스터의 다른 임대 리소스에 대한 액세스를 방지하면서 적절한 조정을 보장합니다.
Amazon EKS는 Auto Mode가 활성화되면 클러스터 IAM 역할에 대한 이 액세스 정책으로 액세스 항목을 자동으로 생성하여 네트워킹 기능이 제대로 작동하는 데 필요한 권한이 있는지 확인합니다.
## AmazonEKSNetworkingPolicy
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSNetworkingPolicy`
이 정책에는 Amazon EKS가 네트워킹을 위한 리더 선택 리소스를 관리하는 권한이 포함되어 있습니다.
+ `coordination.k8s.io`-리더 선택을 위해 임대 객체를 생성하고 관리합니다. 이를 통해 EKS 네트워킹 구성 요소는 리더를 선택하여 IP 주소 할당 활동을 조정할 수 있습니다.
이 정책은 특히 네트워킹 임대 리소스에 적용되어 클러스터의 다른 임대 리소스에 대한 액세스를 방지하면서 적절한 조정을 보장합니다.
Amazon EKS는 Auto Mode가 활성화되면 클러스터 IAM 역할에 대한 이 액세스 정책으로 액세스 항목을 자동으로 생성하여 네트워킹 기능이 제대로 작동하는 데 필요한 권한이 있는지 확인합니다.
## AmazonEKSComputePolicy
**참고**
이 정책은 AWS 서비스 연결 역할에만 지정되며 고객 관리형 역할에는 사용할 수 없습니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSComputePolicy`
이 정책에는 Amazon EKS가 컴퓨팅 작업을 위한 리더 선택 리소스를 관리하는 권한이 포함되어 있습니다.
+ `coordination.k8s.io`-리더 선택을 위해 임대 객체를 생성하고 관리합니다. 이를 통해 EKS 컴퓨팅 구성 요소는 리더를 선택하여 노드 조정 활동을 조율할 수 있습니다.
이 정책은 클러스터의 모든 임대 리소스에 대한 기본 읽기 액세스(`get`, `watch`)를 허용하는 동시에 컴퓨팅 관리 임대 리소스에 특별히 적용됩니다.
Amazon EKS는 Auto Mode가 활성화되면 클러스터 IAM 역할에 대한 이 액세스 정책으로 액세스 항목을 자동으로 생성하여 네트워킹 기능이 제대로 작동하는 데 필요한 권한이 있는지 확인합니다.
## AmazonEKSBlockStorageClusterPolicy
**참고**
이 정책은 AWS 서비스 연결 역할에만 지정되며 고객 관리형 역할에는 사용할 수 없습니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSBlockStorageClusterPolicy`
이 정책은 Amazon EKS Auto Mode의 블록 스토리지 기능에 필요한 권한을 부여합니다. 이를 통해 Amazon EKS 클러스터 내에서 블록 스토리지 리소스를 효율적으로 관리할 수 있습니다. 정책에는 다음 권한이 포함됩니다.
CSI 드라이버 관리:
+ 특히 블록 스토리지를 위한 CSI 드라이버를 생성, 읽기, 업데이트 및 삭제합니다.
볼륨 관리:
+ 영구 볼륨을 나열, 감시, 생성, 업데이트, 패치, 삭제합니다.
+ 영구 볼륨 클레임을 나열, 감시, 업데이트합니다.
+ 영구 볼륨 클레임 상태를 패치합니다.
노드 및 포드 상호 작용:
+ 노드 및 포드 정보를 읽습니다.
+ 스토리지 작업과 관련된 이벤트를 관리합니다.
스토리지 클래스 및 속성:
+ 스토리지 클래스 및 CSI 노드를 읽습니다.
+ 볼륨 속성 클래스를 읽습니다.
볼륨 연결:
+ 볼륨 연결 및 해당 상태를 나열, 감시, 수정합니다.
스냅샷 작업:
+ 볼륨 스냅샷, 스냅샷 콘텐츠, 스냅샷 클래스를 관리합니다.
+ 볼륨 그룹 스냅샷 및 관련 리소스에 대한 작업을 처리합니다.
이 정책은 Auto Mode에서 실행되는 Amazon EKS 클러스터 내에서 포괄적인 블록 스토리지 관리를 지원하도록 설계되었습니다. 블록 스토리지 볼륨의 프로비저닝, 연결, 크기 조정, 스냅샷 생성 등 다양한 작업에 대한 권한을 결합합니다.
Amazon EKS는 Auto Mode가 활성화되면 클러스터 IAM 역할에 대한 이 액세스 정책으로 액세스 항목을 자동으로 생성하여 블록 스토리지 기능이 제대로 작동하는 데 필요한 권한이 있는지 확인합니다.
## AmazonEKSComputeClusterPolicy
**참고**
이 정책은 AWS 서비스 연결 역할에만 지정되며 고객 관리형 역할에는 사용할 수 없습니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSComputeClusterPolicy`
이 정책은 Amazon EKS Auto Mode의 컴퓨팅 관리 기능에 필요한 권한을 부여합니다. Amazon EKS 클러스터 내에서 컴퓨팅 리소스를 효율적으로 오케스트레이션하고 확장할 수 있습니다. 정책에는 다음 권한이 포함됩니다.
노드 관리:
+ NodePools 및 NodeClaims의 상태를 생성, 읽기, 업데이트, 삭제, 관리합니다.
+ 생성, 수정, 삭제를 포함하여 NodeClasses를 관리합니다.
예약 및 리소스 관리:
+ 포드, 노드, 영구 볼륨, 영구 볼륨 클레임, 복제 컨트롤러, 네임스페이스에 대한 읽기 액세스입니다.
+ 스토리지 클래스, CSI 노드, 볼륨 연결에 대한 읽기 액세스입니다.
+ 배포, 대몬 세트, 복제본 세트, 상태 저장 세트를 나열하고 감시합니다.
+ 포드 중단 예산을 읽습니다.
이벤트 처리:
+ 클러스터 이벤트를 생성, 읽기, 관리합니다.
노드 디프로비저닝 및 포드 제거:
+ 노드를 업데이트, 패치, 삭제합니다.
+ 포드 제거를 생성하고 필요한 경우 포드를 삭제합니다.
사용자 지정 리소스 정의(CRD) 관리:
+ 새 CRD를 생성합니다.
+ 노드 관리와 관련된 특정 CRD(NodeClasses, NodePools, NodeClaims, NodeDiagnostics)를 관리합니다.
이 정책은 Auto Mode에서 실행되는 Amazon EKS 클러스터 내에서 포괄적인 컴퓨팅 관리를 지원하도록 설계되었습니다. 노드 프로비저닝, 예약, 조정, 리소스 최적화를 비롯한 다양한 작업에 대한 권한을 결합합니다.
Amazon EKS는 Auto Mode가 활성화되면 클러스터 IAM 역할에 대한 이 액세스 정책으로 액세스 항목을 자동으로 생성하여 컴퓨팅 관리 기능이 제대로 작동하는 데 필요한 권한이 있는지 확인합니다.
## AmazonEKSLoadBalancingClusterPolicy
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSLoadBalancingClusterPolicy`
이 정책은 Amazon EKS Auto Mode의 로드 밸런싱 기능에 필요한 권한을 부여합니다. Amazon EKS 클러스터 내에서 로드 밸런싱 리소스를 효율적으로 관리하고 구성할 수 있습니다. 정책에는 다음 권한이 포함됩니다.
이벤트 및 리소스 관리:
+ 이벤트를 생성하고 패치합니다.
+ 포드, 노드, 엔드포인트, 네임스페이스에 대한 읽기 액세스입니다.
+ 포드 상태를 업데이트합니다.
서비스 및 수신 관리:
+ 서비스 및 해당 상태를 전체적으로 관리합니다.
+ 수신 및 상태를 포괄적으로 제어합니다.
+ 엔드포인트 조각 및 수신 클래스에 대한 읽기 액세스입니다.
대상 그룹 바인딩:
+ 대상 그룹 바인딩과 해당 상태를 생성하고 수정합니다.
+ 수신 클래스 파라미터에 대한 읽기 액세스입니다.
사용자 지정 리소스 정의(CRD) 관리:
+ 모든 CRD를 생성하고 읽습니다.
+ targetgroupbindings.eks.amazonaws.com 및 ingressclassparams.eks.amazonaws.com CRD에 대한 특정 관리입니다.
웹후크 구성:
+ 웹후크의 변경 및 검증 구성을 생성하고 읽습니다.
+ eks-load-balancing-webhook 구성을 관리합니다.
이 정책은 Auto Mode에서 실행되는 Amazon EKS 클러스터 내에서 포괄적인 로드 밸런싱 관리를 지원하도록 설계되었습니다. 서비스 노출, 수신 라우팅, AWS 로드 밸런싱 서비스와의 통합을 비롯한 다양한 작업에 대한 권한을 결합합니다.
Amazon EKS는 Auto Mode가 활성화되면 클러스터 IAM 역할에 대한 이 액세스 정책으로 액세스 항목을 자동으로 생성하여 로드 밸런싱 기능이 제대로 작동하는 데 필요한 권한이 있는지 확인합니다.
## AmazonEKSNetworkingClusterPolicy
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSNetworkingClusterPolicy`
AmazonEKSNetworkingClusterPolicy
이 정책은 Amazon EKS Auto Mode의 네트워킹 기능에 필요한 권한을 부여합니다. Amazon EKS 클러스터 내에서 네트워킹 리소스를 효율적으로 관리하고 구성할 수 있습니다. 정책에는 다음 권한이 포함됩니다.
노드 및 포드 관리:
+ NodeClasses 및 해당 상태에 대한 읽기 액세스입니다.
+ NodeClaims 및 해당 상태에 대한 읽기 액세스입니다.
+ 포드에 대한 읽기 액세스입니다.
CNI 노드 관리:
+ 생성, 읽기, 업데이트, 삭제, 패치를 포함한 CNINodes 및 해당 상태에 대한 권한입니다.
사용자 지정 리소스 정의(CRD) 관리:
+ 모든 CRD를 생성하고 읽습니다.
+ cninodes.eks.amazonaws.com CRD에 대한 특정 관리(업데이트, 패치, 삭제)입니다.
이벤트 관리:
+ 이벤트를 생성하고 패치합니다.
이 정책은 Auto Mode에서 실행되는 Amazon EKS 클러스터 내에서 포괄적인 네트워킹 관리를 지원하도록 설계되었습니다. 노드 네트워킹 구성, CNI(컨테이너 네트워크 인터페이스) 관리, 관련 사용자 지정 리소스 처리를 비롯한 다양한 작업에 대한 권한을 결합합니다.
이 정책은 네트워킹 구성 요소가 노드 관련 리소스와 상호 작용하고, CNI별 노드 구성을 관리하고, 클러스터의 네트워킹 작업에 중요한 사용자 지정 리소스를 처리하도록 허용합니다.
Amazon EKS는 Auto Mode가 활성화되면 클러스터 IAM 역할에 대한 이 액세스 정책으로 액세스 항목을 자동으로 생성하여 네트워킹 기능이 제대로 작동하는 데 필요한 권한이 있는지 확인합니다.
## AmazonEKSHybridPolicy
**참고**
이 정책은 AWS 서비스 연결 역할에만 지정되며 고객 관리형 역할에는 사용할 수 없습니다.
이 액세스 정책에는 클러스터의 노드에 대한 EKS 액세스 권한을 부여하는 권한이 포함되어 있습니다. 액세스 항목에 연결된 경우 액세스 범위는 일반적으로 Kubernetes 네임스페이스가 아닌 클러스터입니다. 이 정책은 Amazon EKS Hybrid Nodes에서 사용됩니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSHybridPolicy`
| Kubernetes API 그룹 | Kubernetes nonResourceURLs | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- | --- |
| `*` | | `nodes` | `list` |
## AmazonEKSClusterInsightsPolicy
**참고**
이 정책은 AWS 서비스 연결 역할에만 지정되며 고객 관리형 역할에는 사용할 수 없습니다.
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterInsightsPolicy`
이 정책은 Amazon EKS Cluster Insights 기능에 대한 읽기 전용 권한을 부여합니다. 정책에는 다음 권한이 포함됩니다.
노드 액세스: - 클러스터 노드 나열 및 보기 - 노드 상태 정보 읽기
DaemonSet 액세스: - kube-proxy 구성에 대한 읽기 액세스
이 정책은 Cluster Insights용 EKS 서비스에 의해 자동으로 관리됩니다. 자세한 내용은 [클러스터 인사이트를 사용한 Kubernetes 버전 업그레이드 준비 및 잘못된 구성 문제 해결](cluster-insights.md) 섹션을 참조하세요.
## AWSBackupFullAccessPolicyForBackup
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForBackup`
AWSBackupFullAccessPolicyForBackup
이 정책은 AWS Backup이 EKS 클러스터의 백업을 관리 및 생성하는 데 필요한 권한을 부여합니다. 이 정책에는 다음 권한이 포함되어 있습니다.
| Kubernetes API 그룹 | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- |
| `*` | `*` | `list`, `get` |
## AWSBackupFullAccessPolicyForRestore
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForRestore`
AWSBackupFullAccessPolicyForRestore
이 정책은 AWS Backup이 EKS 클러스터의 백업을 관리 및 복원하는 데 필요한 권한을 부여합니다. 이 정책에는 다음 권한이 포함되어 있습니다.
| Kubernetes API 그룹 | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- |
| `*` | `*` | `list`, `get`, `create` |
## AmazonEKSACKPolicy
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`
이 정책은 AWS Controllers for Kubernetes(ACK) 기능이 Kubernetes에서 AWS 리소스를 관리하는 데 필요한 권한을 부여합니다. 정책에는 다음 권한이 포함됩니다.
ACK 사용자 지정 리소스 관리:
+ S3, RDS, DynamoDB, Lambda, EC2 등 50개 이상의 AWS 서비스에서 모든 ACK 서비스 사용자 지정 리소스에 대한 전체 액세스 권한.
+ ACK 사용자 지정 리소스 정의를 생성하고 읽으며 업데이트하고 삭제합니다.
네임스페이스 액세스:
+ 리소스 조직의 네임스페이스에 대한 읽기 액세스 권한.
리더 선정:
+ 리더 선정을 위한 조정 리스를 생성하고 읽습니다.
+ 특정 ACK 서비스 컨트롤러 리스를 업데이트하고 삭제합니다.
이벤트 관리:
+ ACK 작업에 대한 이벤트를 생성하고 패치를 적용합니다.
이 정책은 Kubernetes API를 통한 포괄적인 AWS 리소스 관리를 지원하도록 설계되었습니다. Amazon EKS는 ACK 기능이 생성될 때 사용자가 제공하는 기능 IAM 역할에 대해 이 액세스 정책을 사용하여 액세스 항목을 자동으로 생성합니다.
| Kubernetes API 그룹 | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- |
| | `namespaces` | `get`, `watch`, `list` |
| `services.k8s.aws`, `acm.services.k8s.aws`, `acmpca.services.k8s.aws`, `apigateway.services.k8s.aws`, `apigatewayv2.services.k8s.aws`, `applicationautoscaling.services.k8s.aws`, `athena.services.k8s.aws`, `bedrock.services.k8s.aws`, `bedrockagent.services.k8s.aws`, `bedrockagentcorecontrol.services.k8s.aws`, `cloudfront.services.k8s.aws`, `cloudtrail.services.k8s.aws`, `cloudwatch.services.k8s.aws`, `cloudwatchlogs.services.k8s.aws`, `codeartifact.services.k8s.aws`, `cognitoidentityprovider.services.k8s.aws`, `documentdb.services.k8s.aws`, `dynamodb.services.k8s.aws`, `ec2.services.k8s.aws`, `ecr.services.k8s.aws`, `ecrpublic.services.k8s.aws`, `ecs.services.k8s.aws`, `efs.services.k8s.aws`, `eks.services.k8s.aws`, `elasticache.services.k8s.aws`, `elbv2.services.k8s.aws`, `emrcontainers.services.k8s.aws`, `eventbridge.services.k8s.aws`, `iam.services.k8s.aws`, `kafka.services.k8s.aws`, `keyspaces.services.k8s.aws`, `kinesis.services.k8s.aws`, `kms.services.k8s.aws`, `lambda.services.k8s.aws`, `memorydb.services.k8s.aws`, `mq.services.k8s.aws`, `networkfirewall.services.k8s.aws`, `opensearchservice.services.k8s.aws`, `organizations.services.k8s.aws`, `pipes.services.k8s.aws`, `prometheusservice.services.k8s.aws`, `ram.services.k8s.aws`, `rds.services.k8s.aws`, `recyclebin.services.k8s.aws`, `route53.services.k8s.aws`, `route53resolver.services.k8s.aws`, `s3.services.k8s.aws`, `s3control.services.k8s.aws`, `sagemaker.services.k8s.aws`, `secretsmanager.services.k8s.aws`, `ses.services.k8s.aws`, `sfn.services.k8s.aws`, `sns.services.k8s.aws`, `sqs.services.k8s.aws`, `ssm.services.k8s.aws`, `wafv2.services.k8s.aws` | `*` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`(특정 ACK 서비스 컨트롤러 리스만 해당) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
## AmazonEKSArgoCDClusterPolicy
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`
이 정책은 Argo CD 기능이 리소스를 검색하고 클러스터 범위의 객체를 관리하는 데 필요한 클러스터 수준 권한을 부여합니다. 정책에는 다음 권한이 포함됩니다.
네임스페이스 관리:
+ 애플리케이션 네임스페이스 관리를 위해 네임스페이스를 생성하고 읽으며 업데이트하고 삭제합니다.
사용자 지정 리소스 정의 관리:
+ Argo CD 특정 CRD(Application, AppProject, ApplicationSet)를 관리합니다.
API 검색:
+ 리소스 검색을 위한 Kubernetes API 엔드포인트에 대한 읽기 액세스 권한.
이 정책은 네임스페이스 관리 및 CRD 설치를 포함한 클러스터 수준의 Argo CD 작업을 지원하도록 설계되었습니다. Amazon EKS는 Argo CD 기능이 생성될 때 사용자가 제공하는 기능 IAM 역할에 대해 이 액세스 정책을 사용하여 액세스 항목을 자동으로 생성합니다.
| Kubernetes API 그룹 | Kubernetes nonResourceURLs | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- | --- |
| | | `namespaces` | `create`, `get`, `update`, `patch`, `delete` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` | `create` |
| `apiextensions.k8s.io` | | `customresourcedefinitions`(Argo CD CRD만 해당) | `get`, `update`, `patch`, `delete` |
| | `/api`, `/api/*`, `/apis`, `/apis/*` | | `get` |
## AmazonEKSArgoCDPolicy
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`
이 정책은 Argo CD 기능이 애플리케이션을 배포하고 관리하는 데 필요한 네임스페이스 수준 권한을 부여합니다. 정책에는 다음 권한이 포함됩니다.
보안 암호 관리:
+ Git 자격 증명의 보안 암호 및 클러스터 보안 암호에 대한 전체 액세스 권한.
ConfigMap 액세스:
+ 고객이 지원되지 않는 Argo CD ConfigMaps를 사용하려는 경우 경고를 보내기 위한 ConfigMaps에 대한 읽기 액세스 권한.
이벤트 관리:
+ 애플리케이션 수명 주기 추적을 위한 이벤트를 읽고 생성합니다.
Argo CD 리소스 관리:
+ Application, ApplicationSet 및 AppProject에 대한 전체 액세스 권한.
+ Argo CD 리소스의 파이널라이저 및 상태를 관리합니다.
이 정책은 애플리케이션 배포 및 관리를 포함한 네임스페이스 수준의 Argo CD 작업을 지원하도록 설계되었습니다. Amazon EKS는 Argo CD 기능이 생성될 때(Argo CD 네임스페이스 범위) 사용자가 제공하는 기능 IAM 역할에 대해 이 액세스 정책을 사용하여 액세스 항목을 자동으로 생성합니다.
| Kubernetes API 그룹 | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- |
| | `secrets` | `*` |
| | `configmaps` | `get`, `list`, `watch` |
| | `events` | `get`, `list`, `watch`, `patch`, `create` |
| `argoproj.io` | `applications`, `applications/finalizers`, `applications/status`, `applicationsets`, `applicationsets/finalizers`, `applicationsets/status`, `appprojects`, `appprojects/finalizers`, `appprojects/status` | `*` |
## AmazonEKSKROPolicy
**ARN**-` arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`
이 정책은 Kube Resource Orchestrator(kro) 기능이 사용자 지정 Kubernetes API를 생성하고 관리하는 데 필요한 권한을 부여합니다. 정책에는 다음 권한이 포함됩니다.
kro 리소스 관리:
+ ResourceGraphDefinitions 및 사용자 지정 리소스 인스턴스를 포함한 모든 kro 리소스에 대한 전체 액세스 권한.
사용자 지정 리소스 정의 관리:
+ ResourceGraphDefinitions에서 정의한 사용자 지정 API에 대한 CRD를 생성하고 읽으며 업데이트하고 삭제합니다.
리더 선정:
+ 리더 선정을 위한 조정 리스를 생성하고 읽습니다.
+ kro 컨트롤러 리스를 업데이트하고 삭제합니다.
이벤트 관리:
+ kro 작업에 대한 이벤트를 생성하고 패치를 적용합니다.
이 정책은 kro를 통한 포괄적인 리소스 구성 및 사용자 지정 API 관리를 지원하도록 설계되었습니다. Amazon EKS는 kro 기능이 생성될 때 사용자가 제공하는 기능 IAM 역할에 대해 이 액세스 정책을 사용하여 액세스 항목을 자동으로 생성합니다.
| Kubernetes API 그룹 | Kubernetes 리소스 | Kubernetes 동사(권한) |
| --- | --- | --- |
| `kro.run` | `*` | `*` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`(kro 컨트롤러 리스만 해당) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
## 액세스 정책 업데이트
액세스 정책이 도입된 이후 액세스 정책에 대한 업데이트 세부 정보를 확인합니다. 이 페이지의 변경 사항에 대한 자동 알림을 받아보려면 [문서 기록](doc-history.md)에서 RSS 피드를 구독하세요.
| 변경 | 설명 | 날짜 |
| --- | --- | --- |
| EKS 기능에 대한 정책 추가 | EKS 기능 관리를 위해 `AmazonEKSACKPolicy`, `AmazonEKSArgoCDClusterPolicy`, `AmazonEKSArgoCDPolicy`, `AmazonEKSKROPolicy` 게시 | 2025년 11월 22일 |
| `AmazonEKSSecretReaderPolicy` 추가 | 보안 암호에 대한 읽기 전용 액세스 권한을 위해 새 정책 추가 | 2025년 11월 6일 |
| EKS Cluster Insights에 대한 정책 추가 | `AmazonEKSClusterInsightsPolicy` 게시 | 2024년 12월 2일 |
| Amazon EKS 하이브리드에 대한 정책 추가 | `AmazonEKSHybridPolicy` 게시 | 2024년 12월 2일 |
| Amazon EKS Auto Mode에 대한 정책 추가 | 이러한 액세스 정책은 클러스터 IAM 역할 및 노드 IAM 역할에 Kubernetes API를 직접 호출할 권한을 부여합니다. AWS는 이를 사용하여 스토리지, 컴퓨팅, 네트워킹 리소스에 대한 일상적인 작업을 자동화합니다. | 2024년 12월 2일 |
| `AmazonEKSAdminViewPolicy` 추가 | 비밀과 같은 리소스를 포함하여 확장된 보기 액세스에 대한 새 정책을 추가합니다. | 2024년 4월 23일 |
| 액세스 정책이 도입되었습니다. | Amazon EKS에서 액세스 정책을 도입했습니다. | 2023년 5월 29일 |
# 액세스 항목을 사용하도록 인증 모드 변경
액세스 항목 사용을 시작하려면 클러스터의 인증 모드를 `API_AND_CONFIG_MAP` 또는 `API` 모드로 변경해야 합니다. 그러면 액세스 항목에 대한 API가 추가됩니다.
## AWS 콘솔
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 관리형 노드 그룹을 생성하려는 클러스터의 이름을 선택합니다.
1. **액세스** 탭을 선택합니다.
1. **인증 모드**는 클러스터의 현재 인증 모드를 표시합니다. EKS API 모드로 표시되면 이미 액세스 항목을 추가할 수 있으며 나머지 단계는 건너뛰어도 됩니다.
1. **액세스 관리**를 선택합니다.
1. **클러스터 인증 모드**에서 EKS API로 모드를 선택합니다. EKS API 및 액세스 항목을 제거한 모드로 인증 모드를 다시 변경할 수 없습니다.
1. **변경 사항 저장**을 선택합니다. Amazon EKS가 클러스터 업데이트를 시작하고 클러스터가 업데이트 중 상태로 변경되며 변경 사항은 **업데이트 기록** 탭에 기록됩니다.
1. 클러스터가 활성 상태로 돌아갈 때까지 기다립니다. 클러스터가 활성 상태이면 [액세스 항목 생성](creating-access-entries.md)의 단계에 따라 IAM 위탁자에서 클러스터에 대한 액세스를 추가할 수 있습니다.
## AWS CLI
1. *AWS 명령줄 인터페이스 사용 설명서*의 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)에 설명된 대로 AWS CLI를 설치합니다.
1. 다음 명령을 실행합니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다. 이 `ConfigMap` 방법을 영구적으로 비활성화하려면 `API_AND_CONFIG_MAP`을 `API`으로 바꿉니다.
Amazon EKS가 클러스터 업데이트를 시작하고 클러스터가 UPDATING 상태로 변경되며 변경 사항은 ** aws eks list-updates **에 기록됩니다.
```
aws eks update-cluster-config --name my-cluster --access-config authenticationMode=API_AND_CONFIG_MAP
```
1. 클러스터가 활성 상태로 돌아갈 때까지 기다립니다. 클러스터가 활성 상태이면 [액세스 항목 생성](creating-access-entries.md)의 단계에 따라 IAM 위탁자에서 클러스터에 대한 액세스를 추가할 수 있습니다.
## 필요한 플랫폼 버전
*액세스 항목*을 사용하려면 클러스터의 플랫폼 버전이 다음 표에 나열된 버전과 동일한 버전 또는 이후 버전이거나 Kubernetes 버전이 표에 나열된 버전보다 이후 버전이어야 합니다. Kubernetes 버전이 나열되지 않은 경우 모든 플랫폼 버전이 액세스 항목을 지원합니다.
| Kubernetes 버전 | 플랫폼 버전 |
| --- | --- |
| 나열되지 않음 | 모두 지원됨 |
| `1.30` | `eks.2` |
| `1.29` | `eks.1` |
| `1.28` | `eks.6` |
자세한 내용은 [플랫폼 버전](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)을 참조하세요.
# 액세스 항목 생성
액세스 항목을 생성하기 전에 다음을 고려합니다.
+ 올바르게 설정된 인증 모드입니다. [액세스 항목을 사용하도록 인증 모드 변경](setting-up-access-entries.md)을(를) 참조하세요.
+ *액세스 항목*에는 기존 IAM 보안 주체 하나의 Amazon 리소스 이름(ARN)만 포함됩니다. IAM 보안 주체는 둘 이상의 액세스 항목에 포함될 수 없습니다. 지정하는 ARN에 대한 추가 고려 사항:
+ IAM 모범 사례에서는 장기 보안 인증 정보를 보유한 IAM *사용자* 대신, 단기 보안 인증 정보를 보유한 IAM *역할*을 사용하여 클러스터에 액세스하도록 권장합니다. 자세한 내용은 *IAM 사용 설명서*에서 [임시 자격 증명을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 공급자와의 페더레이션을 사용하도록 요구](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)를 참조하세요.
+ IAM 역할에 대한 ARN인 경우 경로를 *포함*할 수 있습니다. `aws-auth` `ConfigMap` 항목의 ARN은 경로를 포함할 수 *없습니다*. 예를 들어, ARN은 ` arn:aws:iam::<111122223333>:role/` 또는 ` arn:aws:iam::<111122223333>:role/`일 수 있습니다.
+ 액세스 항목 유형이 `STANDARD` 이외의 유형인 경우,(유형에 대한 다음 고려 사항 참조) ARN은 클러스터가 속한 같은 AWS 계정에 있어야 합니다. 유형이 `STANDARD`인 경우 ARN은 클러스터가 있는 계정과 같거나 다른 AWS 계정에 있을 수 있습니다.
+ 액세스 항목이 생성된 후에는 IAM 보안 주체를 변경할 수 없습니다.
+ 이 ARN으로 IAM 보안 주체를 삭제해도 액세스 항목은 자동으로 삭제되지 않습니다. 삭제하는 IAM 보안 주체에 대한 ARN을 사용하여 액세스 항목을 삭제하는 것이 좋습니다. 액세스 항목을 삭제하지 않고 IAM 보안 주체를 다시 생성하면 ARN이 같아도 액세스 항목이 작동하지 않습니다. 다시 생성된 IAM 보안 주체에서 ARN이 동일하더라도 `roleID` 또는 `userID`(`aws sts get-caller-identity` AWS CLI 명령으로 확인할 수 있음)는 다시 생성된 IAM 보안 주체의 해당 항목과 다릅니다(원래 IAM 보안 주체의 항목임). 액세스 항목의 IAM 보안 주체 `roleID` 또는 `userID`가 표시되지 않더라도 Amazon EKS는 액세스 항목과 함께 이를 저장합니다.
+ 각 액세스 항목에는 *유형*이 있습니다. 액세스 항목의 유형은 연결된 리소스의 유형에 따라 달라지며, 권한을 정의하지 않습니다. 유형을 지정하지 않으면 Amazon EKS에서 자동으로 유형을 `STANDARD`로 설정합니다.
+ `EC2_LINUX` - Linux 또는 Bottlerocket 자체 관리형 노드와 함께 사용되는 IAM 역할의 경우
+ `EC2_WINDOWS` - Windows 자체 관리형 노드와 함께 사용되는 IAM 역할의 경우
+ `FARGATE_LINUX` - AWS Fargate(Fargate)와 함께 사용되는 IAM 역할의 경우
+ `HYBRID_LINUX` - 하이브리드 노드와 함께 사용되는 IAM 역할의 경우
+ `STANDARD` - 지정되지 않은 경우 기본 유형
+ `EC2` - EKS 자동 모드 사용자 지정 노드 클래스의 경우. 자세한 내용은 [노드 클래스 액세스 항목 생성](create-node-class.md#auto-node-access-entry) 섹션을 참조하세요.
+ 액세스 항목을 생성한 후에는 유형을 변경할 수 없습니다.
+ 관리형 노드 그룹 또는 Fargate 프로파일에 사용되는 IAM 역할에 대한 액세스 항목을 생성하지 않아도 됩니다. EKS는 액세스 항목을 생성하거나(활성화된 경우) 인증 구성 맵을 업데이트합니다(액세스 항목을 사용할 수 없는 경우).
+ 액세스 항목 유형이 `STANDARD`인 경우 액세스 항목의 *사용자 이름*을 지정할 수 있습니다. 사용자 이름 값을 지정하지 않는 경우, Amazon EKS는 지정한 IAM 보안 주체(IAM 역할 또는 IAM 사용자) 및 액세스 항목의 유형에 따라 다음 값 중 하나를 자동으로 설정합니다. 고유한 사용자 이름을 지정해야 하는 특별한 이유가 없는 한, 사용자 이름을 지정하지 말고 Amazon EKS에서 자동으로 생성하게 두는 것이 좋습니다. 고유한 사용자 이름을 지정하는 경우:
+ `system:`, `eks:`, `aws:`, `amazon:` 또는 `iam:`으로 시작할 수 없습니다.
+ IAM 역할에 대한 사용자 이름인 경우 사용자 이름 끝에 `{{SessionName}}` 또는 `{{SessionNameRaw}}`를 추가하는 것이 좋습니다. 사용자 이름에 `{{SessionName}}` 또는 `{{SessionNameRaw}}`를 추가하는 경우 사용자 이름에서 \$1\$1SessionName\$1\$1 *앞에* 콜론을 포함해야 합니다. 이 역할을 수임하면 역할을 수임할 때 지정한 AWS STS 세션 이름이 클러스터에 자동으로 전달되고 CloudTrail 로그에 표시됩니다. 예를 들어, `john{{SessionName}}`의 사용자 이름을 포함할 수 없습니다. 사용자 이름은 `:john{{SessionName}}` 또는 `jo:hn{{SessionName}}`이어야 합니다. 콜론은 `{{SessionName}}` 앞에 와야 합니다. 다음 테이블에서 Amazon EKS가 생성한 사용자 이름에는 ARN이 포함됩니다. ARN에는 콜론이 포함되므로 이 요구 사항을 충족합니다. 사용자 이름에 `{{SessionName}}`을 포함하지 않는 경우 콜론은 필요하지 않습니다. `{{SessionName}}`에서는 세션 이름의 특수 문자 ‘@’가 ‘-’로 대체됩니다. `{{SessionNameRaw}}`는 세션 이름의 모든 특수 문자를 유지합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/creating-access-entries.html)
액세스 항목을 생성한 후 사용자 이름을 변경할 수 있습니다.
+ 액세스 항목 유형이 `STANDARD`이고 Kubernetes RBAC 권한 부여를 사용하려는 경우 액세스 항목에 하나 이상의 *그룹 이름*을 추가할 수 있습니다. 액세스 항목을 생성한 후 그룹 이름을 추가 및 제거할 수 있습니다. IAM 위탁자가 클러스터의 Kubernetes 객체에 액세스할 수 있으려면 Kubernetes 역할 기반 권한 부여(RBAC) 객체를 생성하고 관리해야 합니다. 클러스터에서 그룹 이름을 `kind: Group`의 `subject`로 지정하는 Kubernetes `RoleBinding` 또는 `ClusterRoleBinding` 객체를 생성합니다. Kubernetes는 Kubernetes `Role` 또는 `ClusterRole` 객체에서 지정한 모든 클러스터 객체에 대한 IAM 주체 액세스를 승인하고 바인딩의 `roleRef`에서도 이를 지정합니다. 그룹 이름을 지정하는 경우 Kubernetes 역할 기반 인증(RBAC) 객체에 익숙해지는 것이 좋습니다. 자세한 내용은 Kubernetes 문서의 [Using RBAC Authorization(RBAC 승인 사용)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 참조하십시오.
**중요**
Amazon EKS는 클러스터에 있는 Kubernetes RBAC 객체에 지정한 그룹 이름이 포함되었는지 확인하지 않습니다. 예를 들어 현재 존재하지 않는 그룹에 대한 액세스 항목을 생성하는 경우 EKS는 오류를 반환하는 대신 해당 그룹을 생성합니다.
Kubernetes에서 클러스터의 Kubernetes 객체에 대한 액세스 권한을 IAM 위탁자에 부여하는 대신 또는 이 방법 외에도 Amazon EKS *액세스 정책*을 액세스 항목에 연결할 수 있습니다. Amazon EKS는 IAM 위탁자에 액세스 정책의 권한과 함께 클러스터의 Kubernetes 객체에 액세스할 수 있는 권한을 부여합니다. 지정한 Kubernetes 네임스페이스로 액세스 정책의 권한 범위를 지정할 수 있습니다. 액세스 정책을 사용할 경우 Kubernetes RBAC 객체를 관리할 필요가 없습니다. 자세한 내용은 [액세스 정책을 액세스 항목과 연결](access-policies.md) 섹션을 참조하세요.
+ 유형이 `EC2_LINUX` 또는 `EC2_Windows`인 액세스 항목을 생성하는 경우 액세스 항목을 생성하는 IAM 보안 주체에 `iam:PassRole` 권한이 있어야 합니다. 자세한 내용은 *IAM 사용 설명서*에서 [사용자에게 AWS 서비스 역할을 전달할 수 있는 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)를 참조하십시오.
+ 표준 [IAM 동작](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)과 마찬가지로, 액세스 항목 생성 및 업데이트는 실질적으로 일관되며 초기 API 직접 호출이 성공적으로 반환된 후 효력이 발생하는 데 몇 초가 걸릴 수 있습니다. 이러한 잠재적 지연을 고려하도록 애플리케이션을 설계해야 합니다. 액세스 항목 생성 또는 업데이트는 애플리케이션의 중요한 고가용성 코드 경로에 포함하지 않는 것이 좋습니다. 대신 자주 실행하지 않는 별도의 초기화 루틴이나 설정 루틴에서 을 변경하세요. 또한 프로덕션 워크플로우에서 변경 사항을 적용하기 전에 변경 사항이 전파되었는지 확인하세요.
+ 액세스 항목은 [서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)을 지원하지 않습니다. 보안 주체 ARN이 서비스 연결 역할인 경우 액세스 항목을 생성할 수 없습니다. ` arn:aws:iam::*:role/aws-service-role/*` 형식의 ARN으로 서비스 연결 역할을 식별할 수 있습니다.
AWS Management Console 또는 AWS CLI를 사용하여 액세스 항목을 생성할 수 있습니다.
## AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 관리형 노드 그룹을 생성하려는 클러스터의 이름을 선택합니다.
1. **액세스** 탭을 선택합니다.
1. **액세스 항목 생성**을 선택합니다.
1. **IAM 보안 주체**의 경우 기존 IAM 역할 또는 사용자를 선택합니다. IAM 모범 사례에서는 장기 보안 인증 정보를 보유한 IAM *사용자* 대신, 단기 보안 인증 정보를 보유한 IAM *역할*을 사용하여 클러스터에 액세스하도록 권장합니다. 자세한 내용은 *IAM 사용 설명서*에서 [임시 자격 증명을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 공급자와의 페더레이션을 사용하도록 요구](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)를 참조하세요.
1. 자체 관리형 Amazon EC2 노드에 사용되는 노드 역할에 대한 액세스 항목인 경우 **유형**에서 **EC2 Linux** 또는 **EC2 Windows**를 선택합니다. 그렇지 않으면 기본값(**표준**)을 그대로 수락합니다.
1. 선택한 **유형**이 **표준**이고 **사용자 이름**을 지정하려면 사용자 이름을 입력합니다.
1. 선택한 **유형**이 **표준**이고 IAM 위탁자에 대해 Kubernetes RBAC 권한 부여를 사용하려는 경우 **그룹**에 대한 하나 이상의 이름을 지정합니다. 그룹 이름을 지정하지 않고 Amazon EKS 권한 부여를 사용하려는 경우 이후 단계에서 또는 액세스 항목을 생성한 후에 액세스 정책을 연결할 수 있습니다.
1. (선택사항) **태그**에서 액세스 항목에 레이블을 할당합니다. 예를 들어, 태그가 동일한 모든 리소스를 더 쉽게 찾을 수 있습니다.
1. **다음**을 선택합니다.
1. **액세스 정책 추가** 페이지에서 선택한 유형이 **표준**이고 Amazon EKS가 IAM 위탁자에 클러스터의 Kubernetes 객체에 대한 권한을 부여하게 하려면 다음 단계를 완료합니다. 그렇지 않은 경우 **다음**을 선택합니다.
1. **정책 이름**에서 액세스 정책을 선택합니다. 액세스 정책의 권한은 볼 수 없지만 Kubernetes 사용자 대면 `ClusterRole` 객체에서 이와 유사한 권한을 포함합니다. 자세한 내용은 Kubernetes Documentation의 [User-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)를 참조하세요.
1. 다음 옵션 중 하나를 선택하세요.
+ **클러스터** - Amazon EKS에서 IAM 위탁자가 클러스터의 모든 Kubernetes 객체에 대한 액세스 정책의 권한을 갖도록 권한을 부여하려면 이 옵션을 선택합니다.
+ **Kubernetes 네임스페이스** - Amazon EKS에서 IAM 위탁자가 클러스터 내 특정 Kubernetes 네임스페이스의 모든 Kubernetes 객체에 대한 액세스 정책의 권한을 갖도록 권한을 부여하려면 이 옵션을 선택합니다. **네임스페이스**의 경우 클러스터의 Kubernetes 네임스페이스 이름을 입력합니다. 네임스페이스를 더 추가하려면 **새 네임스페이스 추가**를 선택하고 네임스페이스 이름을 입력합니다.
1. 정책을 더 추가하려면 **정책 추가**를 선택합니다. 각 정책의 범위를 다르게 지정할 수 있지만 각 정책은 한 번만 추가할 수 있습니다.
1. **다음**을 선택합니다.
1. 액세스 항목의 구성을 검토합니다. 문제가 있는 것 같으면 **이전**을 선택하여 이전 단계로 돌아가서 오류를 수정합니다. 구성이 올바르면 **생성**을 선택합니다.
## AWS CLI
1. AWS 명령줄 인터페이스 사용 설명서의 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)에 설명된 대로 AWS CLI를 설치합니다.
1. 액세스 항목을 만들려면 다음 예제 중 하나를 사용하여 액세스 항목을 만들 수 있습니다:
+ 자체 관리형 Amazon EC2 Linux 노드 그룹에 대한 액세스 항목을 생성합니다. *my-cluster*를 클러스터 이름으로, *111122223333*을 AWS 계정 ID로, *EKS-my-cluster-self-managed-ng-1*을 [노드 IAM 역할](create-node-role.md)로 바꿉니다. 노드 그룹이 Windows 노드 그룹인 경우 *EC2\$1LINUX*를 `EC2_Windows`로 바꾸세요.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX
```
`STANDARD` 이외의 유형을 지정할 때는 이 `--kubernetes-groups` 옵션을 사용할 수 없습니다. 유형이 `STANDARD` 이외의 값이므로 액세스 정책을 이 액세스 항목에 연결할 수 없습니다.
+ Kubernetes에서 클러스터에 대한 액세스를 부여하려는 Amazon EC2 자체 관리형 노드 그룹에 사용되지 않는 IAM 역할을 허용하는 액세스 항목을 생성합니다. *my-cluster*를 클러스터 이름으로, *111122223333*을 AWS 계정 ID로, *my-role*을 IAM 역할 이름으로 바꿉니다. *Viewers*를 클러스터의 Kubernetes `RoleBinding` 또는 `ClusterRoleBinding` 객체에 지정한 그룹 이름으로 바꿉니다.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
```
+ 클러스터에서 IAM 사용자를 인증할 수 있는 액세스 항목을 생성합니다. IAM 모범 사례에서는 장기 보안 인증 정보를 보유한 IAM *사용자* 대신, 단기 보안 인증 정보를 보유한 IAM *역할*을 사용하여 클러스터에 액세스하도록 권장하지만, 이 예제는 가능한 상황을 보여줍니다. 자세한 내용은 *IAM 사용 설명서*에서 [임시 자격 증명을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 공급자와의 페더레이션을 사용하도록 요구](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)를 참조하세요.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user
```
이 사용자에게 Kubernetes API 검색 역할의 권한보다 더 많은 액세스 권한을 부여하려는 경우 `--kubernetes-groups` 옵션이 사용되지 않으므로 액세스 정책을 액세스 항목에 연결해야 합니다. 자세한 내용은 [액세스 정책을 액세스 항목과 연결](access-policies.md)과 Kubernetes Documentation의 [API discovery roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles)를 참조하세요.
# 액세스 항목 업데이트
AWS Management Console 또는 AWS CLI를 사용하여 액세스 항목을 업데이트할 수 있습니다.
## AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 관리형 노드 그룹을 생성하려는 클러스터의 이름을 선택합니다.
1. **액세스** 탭을 선택합니다.
1. 업데이트할 액세스 항목을 선택합니다.
1. **편집**을 선택합니다.
1. **사용자 이름**에서 기존 값을 변경할 수 있습니다.
1. **그룹**에서 기존 그룹 이름을 제거하거나 새 그룹 이름을 추가할 수 있습니다. **system:nodes** 또는 **system:bootstrappers**와 같은 그룹 이름이 있는 경우에는 제거하지 않습니다. 이러한 그룹을 제거하면 클러스터가 제대로 작동하지 않을 수 있습니다. 그룹 이름을 지정하지 않고 Amazon EKS 권한 부여를 사용하려면 이후 단계에서 [액세스 정책](access-policies.md)을 연결합니다.
1. **태그**에서 액세스 항목에 레이블을 할당할 수 있습니다. 예를 들어, 태그가 동일한 모든 리소스를 더 쉽게 찾을 수 있습니다. 기존 태그를 제거할 수도 있습니다.
1. **변경 사항 저장**을 선택합니다.
1. 액세스 정책을 항목에 연결하려면 [액세스 정책을 액세스 항목과 연결](access-policies.md) 섹션을 참조하세요.
## AWS CLI
1. AWS 명령줄 인터페이스 사용 설명서의 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)에 설명된 대로 AWS CLI를 설치합니다.
1. 액세스 항목을 업데이트하려면 *my-cluster*를 클러스터의 이름으로, *111122223333*를 AWS 계정 ID로, *EKS-my-cluster-my-namespace-Viewers*를 IAM 역할의 이름으로 바꿉니다.
```
aws eks update-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --kubernetes-groups Viewers
```
액세스 항목이 `STANDARD` 이외의 값인 경우 `--kubernetes-groups` 옵션을 사용할 수 없습니다. 또한 `STANDARD` 이외의 유형인 액세스 항목에 액세스 정책을 연결할 수 없습니다.
# 액세스 항목 삭제
액세스 항목을 잘못 삭제했다면 언제든지 다시 생성할 수 있습니다. 삭제하려는 액세스 항목이 액세스 정책과 연결된 경우 연결은 자동으로 삭제됩니다. 액세스 항목을 삭제하기 전에 액세스 항목에서 액세스 정책을 연결 해제하지 않아도 됩니다.
AWS Management Console 또는 AWS CLI를 사용하여 액세스 항목을 삭제할 수 있습니다.
## AWS Management Console
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 액세스 항목을 삭제하려는 클러스터의 이름을 선택합니다.
1. **액세스** 탭을 선택합니다.
1. **액세스 항목** 목록에서 삭제할 액세스 항목을 선택합니다.
1. 삭제를 선택합니다.
1. 확인 대화 상자에서 **삭제**를 선택합니다.
## AWS CLI
1. AWS 명령줄 인터페이스 사용 설명서의 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)에 설명된 대로 AWS CLI를 설치합니다.
1. 액세스 항목을 삭제하려면 *my-cluster*를 클러스터의 이름으로, *111122223333* 를 AWS 계정 ID로, *my-role*을 더 이상 클러스터에 액세스하지 않으려는 IAM 역할의 이름으로 바꿉니다.
```
aws eks delete-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
# EKS 액세스 항목에 대한 사용자 지정 사용자 이름 설정
Amazon EKS에 대한 액세스 항목을 생성할 때 자동으로 생성된 사용자 이름을 사용하거나 사용자 이름을 직접 지정할 수 있습니다. 이 페이지에서는 두 가지 옵션을 모두 설명하고 사용자 지정 사용자 이름을 설정하는 방법을 안내합니다.
## 개요
액세스 항목의 사용자 이름은 Kubernetes 로그 및 감사 추적에서 IAM 보안 주체를 식별하는 데 사용됩니다. 기본적으로 Amazon EKS는 IAM ID의 ARN을 기반으로 사용자 이름을 생성하지만 필요한 경우 사용자 이름을 직접 지정할 수 있습니다.
## 기본 사용자 이름 생성
사용자 이름 값을 지정하지 않으면 Amazon EKS는 IAM ID를 기반으로 사용자 이름을 자동 생성합니다.
+ **IAM 사용자**:
+ EKS는 Kubernetes 사용자 이름을 IAM 사용자의 ARN으로 설정합니다.
+ 예제:
```
{arn-aws}iam::<111122223333>:user/
```
+ **IAM 역할**:
+ EKS는 Kubernetes 사용자 이름을 IAM 역할의 ARN을 기반으로 설정합니다.
+ 역할을 수임한 경우 STS ARN. Amazon EKS가 역할에 `{{SessionName}}`을 추가합니다. 지정한 역할의 ARN에 경로가 포함된 경우 Amazon EKS는 생성된 사용자 이름에서 해당 경로를 제거합니다.
+ 예제:
```
{arn-aws}sts::<111122223333>:assumed-role//{{SessionName}}
```
고유한 사용자 이름을 지정해야 하는 특별한 이유가 없는 한, 사용자 이름을 지정하지 말고 Amazon EKS에서 자동으로 생성하게 두는 것이 좋습니다.
## 사용자 지정 사용자 이름 설정
액세스 항목을 생성할 때 `--username` 파라미터를 사용하여 사용자 이름을 직접 지정할 수 있습니다.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --username
```
### 사용자 지정 사용자 이름 요구 사항
사용자 지정 사용자 이름을 지정하는 경우:
+ 사용자 이름은 `system:`, `eks:`, `aws:`, `amazon:` 또는 `iam:`로 시작할 수 없습니다.
+ IAM 역할에 대한 사용자 이름인 경우 사용자 이름 끝에 `{{SessionName}}` 또는 `{{SessionNameRaw}}`를 추가하는 것이 좋습니다.
+ 사용자 이름에 `{{SessionName}}` 또는 `{{SessionNameRaw}}`를 추가하는 경우 사용자 이름에서 \$1\$1SessionName\$1\$1 *앞에* 콜론을 포함해야 합니다.
# 액세스 정책 및 AWS CLI를 사용하여 IAM 역할 또는 사용자에 대한 액세스 항목 생성
AWS 관리형 EKS 액세스 정책을 사용하여 IAM 자격 증명에 Kubernetes 클러스터에 액세스 및 관리할 수 있는 표준화된 권한을 부여하는 Amazon EKS 액세스 항목을 생성합니다.
## 개요
Amazon EKS의 액세스 항목은 IAM 자격 증명(사용자 및 역할)이 Kubernetes 클러스터에 액세스하고 상호 작용하는 방식을 정의합니다. EKS 액세스 정책을 사용하여 액세스 항목을 생성하면 다음 작업이 가능합니다.
+ 특정 IAM 사용자 또는 역할에 EKS 클러스터 액세스 권한 부여
+ 표준화 및 사전 정의된 권한 세트를 제공하는 AWS 관리형 EKS 액세스 정책을 사용하여 권한 제어
+ 특정 네임스페이스 또는 클러스터 전체에 대한 권한 범위 지정
+ `aws-auth` ConfigMap을 수정하거나 Kubernetes RBAC 리소스를 생성하지 않고도 액세스 관리 간소화
+ 보안 모범 사례를 유지하면서 일반적인 사용 사례를 다루는 Kubernetes 액세스 제어에 AWS 통합 접근 방식 사용
이 접근 방식은 수동 Kubernetes RBAC 구성 없이 표준화된 AWS 관리형 권한을 제공하므로 대부분의 사용 사례에 권장됩니다. EKS 액세스 정책을 사용하면 Kubernetes RBAC 리소스를 수동으로 구성할 필요가 없으며 일반적인 사용 사례를 포괄하는 사전 정의된 권한 세트가 제공됩니다.
## 사전 조건
+ *액세스 항목*을 활성화하도록 클러스터의 *인증 모드*를 구성해야 합니다. 자세한 내용은 [액세스 항목을 사용하도록 인증 모드 변경](setting-up-access-entries.md) 섹션을 참조하세요.
+ AWS 명령줄 인터페이스 사용 설명서의 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)에 설명된 대로 AWS CLI를 설치 및 구성합니다.
## 1단계: 액세스 항목 정의
1. 권한을 부여하려는 사용자 또는 역할과 같은 IAM 자격 증명의 ARN을 찾습니다.
+ 각 IAM 자격 증명에는 하나의 EKS 액세스 항목만 있을 수 있습니다.
1. Amazon EKS 액세스 정책 권한을 특정 Kubernetes 네임스페이스에만 적용할지 또는 전체 클러스터에 적용할지 여부를 결정합니다.
+ 권한을 특정 네임스페이스로 제한하려면 네임스페이스 이름을 기록해 둡니다.
1. IAM 자격 증명에 사용할 EKS 액세스 정책을 선택합니다. 이 정책은 클러스터 내 권한을 부여합니다. 정책의 ARN을 기록합니다.
+ 정책 목록은 [사용 가능한 액세스 정책](access-policy-permissions.md)을 참조하세요.
1. 자동 생성된 사용자 이름이 액세스 항목에 적합한지 또는 사용자 이름을 수동으로 지정해야 하는지 결정합니다.
+ AWS는 IAM 자격 증명을 기반으로 이 값을 자동 생성합니다. 사용자 지정 사용자 이름을 설정할 수 있습니다. 이는 Kubernetes 로그에 표시됩니다.
+ 자세한 내용은 [EKS 액세스 항목에 대한 사용자 지정 사용자 이름 설정](set-custom-username.md) 섹션을 참조하세요.
## 2단계: 액세스 항목 생성
액세스 항목을 계획한 후에는 AWS CLI를 사용하여 생성합니다.
다음은 가장 많이 사용되는 사례의 예시입니다. [모든 구성 옵션에 대한 CLI 참조를 확인합니다](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
다음 단계에서 액세스 정책을 연결합니다.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD
```
## 3단계: 액세스 정책 연결
명령은 정책을 지정된 Kubernetes 네임스페이스로 제한할지 여부에 따라 달라집니다.
액세스 정책의 ARN이 필요합니다. [사용 가능한 액세스 정책](access-policy-permissions.md)을 검토합니다.
### 네임스페이스 범위를 포함하지 않고 정책 생성
```
aws eks associate-access-policy --cluster-name --principal-arn --policy-arn
```
### 네임스페이스 범위를 포함하고 생성
```
aws eks associate-access-policy --cluster-name --principal-arn \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn
```
## 다음 단계
+ [IAM 자격 증명에서 kubectl을 사용할 수 있도록 kubeconfig 생성](create-kubeconfig.md)
# AWS CLI에서 Kubernetes 그룹을 사용하여 액세스 항목 생성
권한 부여에 Kubernetes 그룹을 사용하고 수동 RBAC 구성을 필요로 하는 Amazon EKS 액세스 항목을 생성합니다.
**참고**
대부분의 사용 사례에서는 이 페이지에서 설명하는 Kubernetes 그룹 접근 방식 대신 EKS 액세스 정책을 사용하는 것이 좋습니다. EKS 액세스 정책은 수동 RBAC 구성 없이 액세스를 관리하는 더욱 간단한 AWS 통합 방식을 제공합니다. EKS 액세스 정책이 제공하는 것보다 더 세분화된 제어가 필요한 경우에만 Kubernetes 그룹 접근 방식을 사용합니다.
## 개요
액세스 항목은 IAM 자격 증명(사용자 및 역할)이 Kubernetes 클러스터에 액세스합니다. Kubernetes 그룹 접근 방식은 IAM 사용자 또는 역할에 표준 Kubernetes RBAC 그룹을 통해 EKS 클러스터에 액세스할 수 있는 권한을 부여합니다. 이 방법을 사용하려면 Kubernetes RBAC 리소스(Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings)를 생성 및 관리해야 하고, 고도로 사용자 지정된 권한 세트, 복잡한 권한 부여 요구 사항이 필요하거나 하이브리드 Kubernetes 환경 전반에서 일관된 액세스 제어 패턴을 유지하려는 경우에 권장됩니다.
이 주제에서는 Amazon EC2 인스턴스가 EKS 클러스터에 조인하는 데 사용되는 IAM 자격 증명에 대한 액세스 항목 생성을 다루지 않습니다.
## 사전 조건
+ *액세스 항목*을 활성화하도록 클러스터의 *인증 모드*를 구성해야 합니다. 자세한 내용은 [액세스 항목을 사용하도록 인증 모드 변경](setting-up-access-entries.md) 섹션을 참조하세요.
+ AWS 명령줄 인터페이스 사용 설명서의 [설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)에 설명된 대로 AWS CLI를 설치 및 구성합니다.
+ Kubernetes RBAC에 익숙해지는 것이 좋습니다. 자세한 내용은 Kubernetes 문서의 [Using RBAC Authorization(RBAC 승인 사용)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 참조하세요.
## 1단계: 액세스 항목 정의
1. 권한을 부여하려는 사용자 또는 역할과 같은 IAM 자격 증명의 ARN을 찾습니다.
+ 각 IAM 자격 증명에는 하나의 EKS 액세스 항목만 있을 수 있습니다.
1. 이 IAM 자격 증명과 연결할 Kubernetes 그룹을 결정합니다.
+ 이러한 그룹을 참조하는 기존 Kubernetes `Role`/`ClusterRole` 및 `RoleBinding`/`ClusterRoleBinding` 리소스를 생성 또는 사용해야 합니다.
1. 자동 생성된 사용자 이름이 액세스 항목에 적합한지 또는 사용자 이름을 수동으로 지정해야 하는지 결정합니다.
+ AWS는 IAM 자격 증명을 기반으로 이 값을 자동 생성합니다. 사용자 지정 사용자 이름을 설정할 수 있습니다. 이는 Kubernetes 로그에 표시됩니다.
+ 자세한 내용은 [EKS 액세스 항목에 대한 사용자 지정 사용자 이름 설정](set-custom-username.md) 섹션을 참조하세요.
## 2단계: Kubernetes 그룹에 대한 액세스 항목 생성
액세스 항목을 계획한 후에는 AWS CLI를 사용하여 적절한 Kubernetes 그룹으로 생성합니다.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --kubernetes-groups
```
다음과 같이 바꿉니다.
+ ``을 EKS 클러스터 이름으로
+ ``을 IAM 사용자 또는 역할의 ARN으로
+ ``를 쉼표로 구분된 Kubernetes 그룹 목록으로(예: “system:developers,system:readers”)
[모든 구성 옵션에 대한 CLI 참조를 확인합니다](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
## 3단계: Kubernetes RBAC 구성
IAM 위탁자가 클러스터의 Kubernetes 객체에 액세스할 수 있으려면 Kubernetes 역할 기반 액세스 제어(RBAC) 객체를 생성하고 관리해야 합니다.
1. 권한을 정의하는 Kubernetes `Role` 또는 `ClusterRole` 객체를 생성합니다.
1. 클러스터에서 그룹 이름을 `kind: Group`의 `subject`로 지정하는 Kubernetes `RoleBinding` 또는 `ClusterRoleBinding` 객체를 생성합니다.
Kubernetes에서 그룹 및 권한을 구성하는 방법에 대한 자세한 내용은 Kubernetes 문서의 [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 참조하세요.
## 다음 단계
+ [IAM 자격 증명에서 kubectl을 사용할 수 있도록 kubeconfig 생성](create-kubeconfig.md)
# ConfigMap을 사용하여 IAM 사용자에게 Kubernetes 액세스 권한 부여
**중요**
`aws-auth ConfigMap`는 더 이상 사용되지 않습니다. Kubernetes API에 대한 액세스를 관리하는 권장 방법은 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 섹션을 참조하세요.
[IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)를 사용하는 클러스터에 대한 액세스는 Amazon EKS 컨트롤 플레인에서 실행되는 [Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme)용 AWS IAM Authenticator에 의해 사용 설정됩니다. 인증자는 `aws-auth` `ConfigMap`에서 구성 정보를 가져옵니다. 모든 `aws-auth` `ConfigMap` 설정은 GitHub의 [Full Configuration Format](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format)을 참조하세요.
## Amazon EKS 클러스터에 IAM 보안 주체 추가
Amazon EKS 클러스터를 생성할 경우, 클러스터를 생성하는 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)에게는 Amazon EKS 제어 영역의 클러스터 역할 기반 액세스 제어(RBAC) 구성에 `system:masters` 권한이 자동으로 부여됩니다. 이 보안 주체는 표시되는 구성에 나타나지 않으므로 클러스터를 원래 생성한 보안 주체를 추적해야 합니다. 추가 IAM 위탁자에 클러스터와 상호 작용할 수 있는 기능을 부여하려면 Kubernetes 내에서 `aws-auth ConfigMap`을 편집하고 `aws-auth ConfigMap`에 지정하는 `group`의 이름으로 Kubernetes `rolebinding` 또는 `clusterrolebinding`을 생성합니다.
**참고**
Kubernetes 역할 기반 액세스 제어(RBAC) 구성에 대한 자세한 내용은 Kubernetes Documentation의 [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 참조하세요.
1. `kubectl`이 클러스터에 액세스하는 데 사용하는 자격 증명을 확인합니다. 컴퓨터에서 다음 명령으로 `kubectl`이 사용하는 자격 증명을 볼 수 있습니다. 기본 경로를 사용하지 않는 경우 *\$1/.kube/config*를 `kubeconfig` 파일의 경로로 바꿉니다.
```
cat ~/.kube/config
```
예제 출력은 다음과 같습니다.
```
[...]
contexts:
- context:
cluster: my-cluster.region-code.eksctl.io
user: admin@my-cluster.region-code.eksctl.io
name: admin@my-cluster.region-code.eksctl.io
current-context: admin@my-cluster.region-code.eksctl.io
[...]
```
이전 예제 출력에서는 *admin*이라는 사용자의 자격 증명이 *my-cluster*라는 클러스터에 대해 구성되었습니다. 클러스터를 생성한 사용자인 경우 클러스터에 대한 액세스 권한이 이미 있습니다. 클러스터를 생성한 사용자가 아닌 경우 다른 IAM 보안 주체에 대한 클러스터 액세스를 사용 설정하기 위해 나머지 단계를 완료해야 합니다. [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)에서는 되도록 사용자 대신 역할에 권한을 부여하세요. 다음 명령을 사용하여 현재 클러스터에 액세스할 수 있는 다른 보안 주체를 확인할 수 있습니다.
```
kubectl describe -n kube-system configmap/aws-auth
```
예제 출력은 다음과 같습니다.
```
Name: aws-auth
Namespace: kube-system
Labels:
Annotations:
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-node-role
username: system:node:{{EC2PrivateDNSName}}
BinaryData
====
Events:
```
이전 예는 기본 `aws-auth` `ConfigMap`입니다. 노드 인스턴스 역할만 클러스터에 액세스할 수 있습니다.
1. IAM 위탁자를 매핑할 수 있는 기존 Kubernetes `roles` 및 `rolebindings` 또는 `clusterroles` 및 `clusterrolebindings`가 있어야 합니다. 이런 리소스에 대한 자세한 내용을 알아보려면 Kubernetes 문서의 [RBAC 승인 사용](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 참조하세요.
1. 기존 Kubernetes `roles` 또는 `clusterroles`를 확인합니다. `Roles`는 `namespace`로 범위가 지정되지만 `clusterroles`는 클러스터로 범위가 지정됩니다.
```
kubectl get roles -A
```
```
kubectl get clusterroles
```
1. 이전 출력에서 반환된 모든 `role` 또는 `clusterrole`의 세부 정보를 보고 IAM 보안 주체가 클러스터에서 보유하려는 권한(`rules`)이 있는지 확인합니다.
*role-name*을 이전 명령의 출력에서 반환된 `role` 이름으로 바꿉니다. *kube-system*을 `role`의 네임스페이스로 바꿉니다.
```
kubectl describe role role-name -n kube-system
```
*cluster-role-name*을 이전 명령의 출력에서 반환된 `clusterrole` 이름으로 바꿉니다.
```
kubectl describe clusterrole cluster-role-name
```
1. 기존 Kubernetes `rolebindings` 또는 `clusterrolebindings`를 확인합니다. `Rolebindings`는 `namespace`로 범위가 지정되지만 `clusterrolebindings`는 클러스터로 범위가 지정됩니다.
```
kubectl get rolebindings -A
```
```
kubectl get clusterrolebindings
```
1. `rolebinding` 또는 `clusterrolebinding`의 모든 세부 정보를 보고 `roleRef`로 나열된 이전 단계의 `role` 또는 `clusterrole` 그리고 `subjects`에 나열된 그룹 이름이 있는지 확인합니다.
*role-binding-name*을 이전 명령의 출력에서 반환된 `rolebinding` 이름으로 바꿉니다. *kube-system*을 `rolebinding`의 `namespace`로 바꿉니다.
```
kubectl describe rolebinding role-binding-name -n kube-system
```
예제 출력은 다음과 같습니다.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-console-dashboard-restricted-access-role-binding
namespace: default
subjects:
- kind: Group
name: eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.io
```
*cluster-role-binding-name*을 이전 명령의 출력에서 반환된 `clusterrolebinding` 이름으로 바꿉니다.
```
kubectl describe clusterrolebinding cluster-role-binding-name
```
예제 출력은 다음과 같습니다.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
name: eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
```
1. `aws-auth` `ConfigMap`을 편집합니다. `eksctl`과 같은 도구를 사용하여 `ConfigMap`을 업데이트하거나 이를 편집하여 수동으로 업데이트할 수 있습니다.
**중요**
`eksctl` 또는 다른 도구를 사용하여 `ConfigMap`을 편집하는 것이 좋습니다. 사용할 수 있는 다른 도구에 대한 자세한 내용을 알아보려면 Amazon EKS 모범 사례 가이드의 [도구를 사용하여 aws-authConfigMap](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap)을 변경을 참조하세요. 부적절하게 형식이 지정된 `aws-auth` `ConfigMap`으로 인해 클러스터에 대한 액세스 권한을 상실할 수 있습니다.
+ [eksctl을 사용하여 구성 맵을 편집](#configmap-eksctl)하는 단계를 확인합니다.
+ [configmap을 수동으로 편집](#configmap-manual)하는 단계를 봅니다.
### Eksctl을 사용하여 Configmap 편집
1. 장치에 설치된 `eksctl` 명령줄 도구의 버전 `0.215.0` 이상 또는 AWS CloudShell이 필요합니다. `eksctl`을 설치 또는 업그레이드하려면 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요.
1. `ConfigMap`에서 현재 매핑을 확인합니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다. *region-code*를 클러스터가 있는 AWS 리전으로 바꿉니다.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
예제 출력은 다음과 같습니다.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. 역할에 대한 매핑을 추가합니다. *my-role*을 역할 이름으로 바꿉니다. *eks-console-dashboard-full-access-group*을 Kubernetes `RoleBinding` 또는 `ClusterRoleBinding` 객체에 지정된 그룹 이름으로 바꿉니다. *111122223333*을 계정 ID로 바꿉니다. *admin*을 선택한 모든 이름으로 바꿀 수 있습니다.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \
--no-duplicate-arns
```
**중요**
역할 ARN에는 `role/my-team/developers/my-role`과 같은 경로가 포함될 수 없습니다. ARN 형식은 ` arn:aws:iam::111122223333:role/my-role `이어야 합니다. 이 예에서는 `my-team/developers/`를 제거해야 합니다.
예제 출력은 다음과 같습니다.
```
[...]
2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap
```
1. 사용자에 대한 매핑을 추가합니다. [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)에서는 되도록 사용자 대신 역할에 권한을 부여하세요. *my-user*를 사용자 이름으로 바꿉니다. *eks-console-dashboard-restricted-access-group*을 Kubernetes `RoleBinding` 또는 `ClusterRoleBinding` 객체에 지정된 그룹 이름으로 바꿉니다. *111122223333*을 계정 ID로 바꿉니다. *my-user*를 선택한 모든 이름으로 바꿀 수 있습니다.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \
--no-duplicate-arns
```
예제 출력은 다음과 같습니다.
```
[...]
2022-05-09 14:53:48 [ℹ] adding identity "arn:aws:iam::111122223333:user/my-user" to auth ConfigMap
```
1. `ConfigMap`에서 매핑을 다시 확인합니다.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
예제 출력은 다음과 같습니다.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group
arn:aws:iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group
```
### Configmap 수동 편집
1. 편집을 위해 `ConfigMap`을 엽니다.
```
kubectl edit -n kube-system configmap/aws-auth
```
**참고**
“`Error from server (NotFound): configmaps "aws-auth" not found`”라는 오류가 표시되면 [클러스터에 aws-auth ConfigMap 적용](#aws-auth-configmap)의 절차를 사용하여 스톡 `ConfigMap`을 적용합니다.
1. IAM 보안 주체를 `ConfigMap`에 추가하세요. IAM 그룹은 IAM 보안 주체가 아니므로 `ConfigMap`에 추가할 수 없습니다.
+ **IAM 역할(예: [페더레이션 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html))을 추가하려면**: 역할 세부 정보를 `data` 아래 `ConfigMap`의 `mapRoles` 섹션에 추가합니다. 파일에 이미 존재하지 않는 경우 이 섹션을 추가합니다. 각 항목은 다음 파라미터를 지원합니다.
+ **rolearn**: 추가할 IAM 역할의 ARN. 이 값은 경로를 포함할 수 없습니다. 예를 들어, ` arn:aws:iam::111122223333:role/my-team/developers/role-name `과 같은 ARN을 지정할 수 없습니다. 대신 ARN은 ` arn:aws:iam::111122223333:role/role-name `이어야 합니다.
+ **username**: Kubernetes 내에서 IAM 역할에 매핑할 사용자 이름.
+ **그룹(groups)**: 역할을 매핑할 그룹 또는 Kubernetes 그룹 목록입니다. 그룹은 기본 그룹이나 `clusterrolebinding` 또는 `rolebinding`에 지정된 그룹일 수 있습니다. 자세한 내용은 Kubernetes Documentation의 [Default roles and role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings)를 참조하세요.
+ **IAM 사용자를 추가하는 방법:** [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)에서는 되도록 사용자 대신 역할에 권한을 부여하세요. 사용자 세부 정보를 `data` 아래 `ConfigMap`의 `mapUsers` 섹션에 추가합니다. 파일에 이미 존재하지 않는 경우 이 섹션을 추가합니다. 각 항목은 다음 파라미터를 지원합니다.
+ **userarn**: 추가할 IAM 사용자의 ARN.
+ **username**: Kubernetes 내에서 IAM 사용자에게 매핑할 사용자 이름.
+ **groups**: 사용자를 매핑할 그룹 또는 Kubernetes 그룹 목록입니다. 그룹은 기본 그룹이나 `clusterrolebinding` 또는 `rolebinding`에 지정된 그룹일 수 있습니다. 자세한 내용은 Kubernetes Documentation의 [Default roles and role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings)를 참조하세요.
1. 예를 들어, 아래 YAML 블록에는 다음이 포함됩니다.
+ 노드가 클러스터에 직접 등록할 수 있도록 IAM 노드 인스턴스를 Kubernetes 그룹에 매핑하는 `mapRoles` 섹션 및 모든 클러스터에 대한 모든 Kubernetes 리소스를 볼 수 있는 Kubernetes 그룹에 매핑되는 `my-console-viewer-role` IAM 역할. `my-console-viewer-role` IAM 역할에 필요한 IAM 및 Kubernetes 그룹 권한 목록은 [필수 권한](view-kubernetes-resources.md#view-kubernetes-resources-permissions) 섹션을 참조하세요.
+ 기본 AWS 계정의 `admin` IAM 사용자를 `system:masters` Kubernetes 그룹에 매핑하는 `mapUsers` 섹션 및 특정 네임스페이스에 대한 Kubernetes 리소스를 볼 수 있는 Kubernetes 그룹에 매핑되는 다른 AWS 계정의 `my-user` 사용자. `my-user` IAM 사용자에 필요한 IAM 및 Kubernetes 그룹 권한 목록은 [필수 권한](view-kubernetes-resources.md#view-kubernetes-resources-permissions) 섹션을 참조하세요.
필요에 따라 줄을 추가하거나 제거하고 모든 예제 값을 자신의 값으로 바꿉니다.
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws:iam::111122223333:role/my-console-viewer-role
username: my-console-viewer-role
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::111122223333:user/admin
username: admin
- groups:
- eks-console-dashboard-restricted-access-group
userarn: arn:aws:iam::444455556666:user/my-user
username: my-user
```
1. 파일을 저장하고 텍스트 편집기를 종료합니다.
## 클러스터에 `aws-auth` `ConfigMap` 적용
`aws-auth` `ConfigMap`은 관리형 노드 그룹을 생성하거나 `eksctl`을 사용하여 노드 그룹을 생성할 때 자동으로 생성되어 클러스터에 적용됩니다. 이 ConfigMap은 처음에는 노드를 클러스터에 조인하기 만들어졌으나 이 `ConfigMap`을 사용하여 IAM 보안 주체에 역할 기반 액세스 제어(RBAC) 액세스를 추가할 수도 있습니다. 자체 관리형 노드를 시작했고 클러스터에 `aws-auth` `ConfigMap`을(를) 적용하지 않았다면 다음 절차를 수행하면 됩니다.
1. `aws-auth` `ConfigMap`을(를) 이미 적용했는지 확인합니다.
```
kubectl describe configmap -n kube-system aws-auth
```
‘`Error from server (NotFound): configmaps "aws-auth" not found`’와 같은 오류가 발생할 경우 다음 단계를 수행하여 스톡 `ConfigMap`을 적용합니다.
1. AWS Authenticator 구성 맵을 다운로드, 편집 및 적용합니다.
1. 구성 맵을 다운로드합니다.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. `aws-auth-cm.yaml` 파일에서 `rolearn`을 노드와 연결된 IAM 역할의 Amazon 리소스 이름(ARN)으로 설정합니다. 이 작업은 텍스트 편집기를 사용하거나 *my-node-instance-role*을 대체하고 다음 명령을 실행하여 수행할 수 있습니다.
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
이 파일에서 어떠한 행도 수정하지 마세요.
**중요**
역할 ARN에는 `role/my-team/developers/my-role`과 같은 경로가 포함될 수 없습니다. ARN 형식은 ` arn:aws:iam::111122223333:role/my-role `이어야 합니다. 이 예에서는 `my-team/developers/`를 제거해야 합니다.
노드 그룹에 대해 AWS CloudFormation 스택 출력을 점검하고 다음 값을 찾습니다.
+ **InstanceRoleARN**-`eksctl`로 생성된 노드 그룹용
+ **NodeInstanceRole**-AWS Management Console에서 Amazon EKS 판매 AWS CloudFormation 템플릿으로 생성된 노드 그룹용
1. 구성을 적용합니다. 이 명령을 완료하는 데 몇 분이 걸릴 수 있습니다.
```
kubectl apply -f aws-auth-cm.yaml
```
**참고**
권한 부여 또는 리소스 유형 오류가 표시되는 경우 문제 해결 주제의 [권한이 없거나 액세스가 거부됨(`kubectl`)](troubleshooting.md#unauthorized) 섹션을 참조하세요.
1. 노드의 상태를 확인하고 `Ready` 상태가 될 때까지 대기합니다.
```
kubectl get nodes --watch
```
`Ctrl`\$1`C`를 입력하여 쉘 프롬프트로 돌아갑니다.
# 외부 OIDC 제공자를 통해 사용자에게 Kubernetes에 대한 액세스 권한 부여
Amazon EKS는 클러스터에서 사용자를 인증하는 방법으로 OpenID Connect(OIDC) 자격 증명 공급자를 지원합니다. OIDC ID 공급자는 AWS ID 및 액세스 관리(IAM)와 함께 또는 그 대안으로 사용할 수 있습니다. IAM 사용에 대한 자세한 내용은 [IAM 사용자 및 역할에 Kubernetes API에 대한 액세스 권한 부여](grant-k8s-access.md)를 참조하세요. 클러스터에 인증을 구성한 후, Kubernetes `roles` 및 `clusterroles`를 생성하여 역할에 권한을 할당한 다음 Kubernetes `rolebindings` 및 `clusterrolebindings`를 사용하여 역할을 ID에 바인딩할 수 있습니다. 자세한 내용은 Kubernetes 문서의 [Using RBAC Authorization(RBAC 승인 사용)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 참조하세요.
+ 하나의 OIDC 자격 증명 공급자를 클러스터에 연결할 수 있습니다.
+ Kubernetes는 OIDC ID 제공업체를 제공하지 않습니다. 기존 퍼블릭 OIDC 자격 증명 공급자를 사용하거나 자체 ID 공급자를 실행할 수 있습니다. 인증된 공급자 목록은 OpenID 사이트에서 [OpenID 인증](https://openid.net/certification/)을 참조하세요.
+ Amazon EKS가 서명 키를 검색할 수 있도록 OIDC 자격 증명 공급자의 발급자 URL에 공개적으로 액세스할 수 있어야 합니다. Amazon EKS는 자체 서명된 인증서를 사용하는 OIDC ID 제공업체를 지원하지 않습니다.
+ 클러스터에 노드를 조인하는 데 여전히 필요하므로 클러스터에 IAM 인증을 비활성화할 수 없습니다.
+ 하지만 여전히 OIDC 자격 증명 공급자 사용자가 아니라 AWS [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)가 Amazon EKS 클러스터를 생성해야 합니다. 이는 클러스터 생성자가 Kubernetes API가 아닌 Amazon EKS API와 상호 작용하기 때문입니다.
+ 컨트롤 플레인에 대해 CloudWatch Logs가 설정되어 있는 경우 OIDC ID 제공업체 인증 사용자는 클러스터의 감사 로그에 표시됩니다. 자세한 내용은 [컨트롤 플레인 로그 활성화 또는 비활성화](control-plane-logs.md#enabling-control-plane-log-export) 섹션을 참조하세요.
+ OIDC 제공자가 제공한 계정으로 AWS Management Console에 로그인할 수 없습니다. AWS ID 및 액세스 관리 계정으로 AWS Management Console에 로그인해야만 [AWS Management Console에서 Kubernetes 리소스 보기](view-kubernetes-resources.md)할 수 있습니다.
## OIDC 자격 증명 공급자 연결
OIDC 자격 증명 공급자를 클러스터에 연결하려면 먼저 공급자의 다음 정보가 필요합니다.
**발급자 URL**
API 서버가 토큰을 확인하기 위한 퍼블릭 서명 키를 검색할 수 있도록 허용하는 OIDC ID 제공자의 URL입니다. URL은 `https://`로 시작해야 하며 공급자의 OIDC ID 토큰에 있는 `iss` 클레임에 해당해야 합니다. OIDC 표준에 따라 경로 구성 요소는 허용되지만 쿼리 파라미터는 허용되지 않습니다. 일반적으로 URL은 `https://server.example.org` 또는 `https://example.com` 같은 하나의 호스트 이름으로만 구성됩니다. 이 URL은 `.well-known/openid-configuration` 아래 레벨을 가리켜야 하며 인터넷을 통해 공개적으로 액세스할 수 있어야 합니다.
**클라이언트 ID(*대상*이라고도 함)**
OIDC ID 제공자에게 인증을 요청하는 클라이언트 애플리케이션의 ID입니다.
`eksctl` 또는 AWS Management Console을 사용하여 자격 증명 공급자를 연결할 수 있습니다.
### eksctl을 사용하여 ID 공급자 연결
1. 다음 콘텐츠를 가진 `associate-identity-provider.yaml`이라는 파일을 생성합니다: 예제 값을 사용자의 값으로 바꿉니다. `identityProviders` 섹션의 값은 OIDC 자격 증명 공급자로부터 가져옵니다. 값은 `identityProviders`의 `name`, `type`, `issuerUrl`, `clientId` 설정에만 필요합니다.
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: your-region-code
identityProviders:
- name: my-provider
type: oidc
issuerUrl: https://example.com
clientId: kubernetes
usernameClaim: email
usernamePrefix: my-username-prefix
groupsClaim: my-claim
groupsPrefix: my-groups-prefix
requiredClaims:
string: string
tags:
env: dev
```
**중요**
`groupsPrefix` 또는 `usernamePrefix`에 대해 `system:` 또는 해당 문자열의 어떤 부분도 지정하지 마세요.
1. 공급자를 생성합니다.
```
eksctl associate identityprovider -f associate-identity-provider.yaml
```
1. 클러스터와 OIDC ID 제공업체에 `kubectl`을 사용하려면 Kubernetes Documentation의 [Using kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl)을 참조하세요.
### AWS 콘솔을 사용하여 ID 공급자 연결
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. 클러스터를 선택한 다음 **액세스** 탭을 선택합니다.
1. **OIDC 자격 증명 공급자** 섹션에서 \$1ID 제공업체 연결\$1을 선택합니다.
1. [**OIDC 자격 증명 공급자 연결(Associate OIDC Identity Provider)**] 페이지에서 다음 옵션을 입력하거나 선택한 후 [**연결(Associate)**]을 선택합니다.
+ [**이름(Name)**]에 공급자의 고유한 이름을 입력합니다.
+ **발급자 URL**에 공급자의 URL을 입력합니다. 이는 인터넷을 통해 액세스할 수 있는 URL이어야 합니다.
+ **클라이언트 ID**에 OIDC ID 제공업체의 클라이언트 ID(**대상**이라고도 함)를 입력합니다.
+ **사용자 이름 클레임**에 사용자 이름으로 사용할 클레임을 입력합니다.
+ **그룹 클레임**에 사용자의 그룹으로 사용할 클레임을 입력합니다.
+ (선택사항) **고급 옵션**을 선택하고 다음 정보를 입력하거나 선택합니다.
+ **사용자 이름 접두사** — 사용자 이름 클레임 앞에 추가할 접두사를 입력합니다. 기존 이름과의 충돌을 방지하기 위해 접두사가 사용자 이름 클레임 앞에 추가됩니다. 값을 제공하지 않은 경우 사용자 이름이 `email` 이외의 값이면 접두사는 **발급자 URL**에 대한 기본값으로 설정됩니다. 값` -`를 사용하여 모든 접두사를 사용 중지할 수 있습니다. `system:` 또는 해당 문자열의 어떤 부분도 지정하지 마세요.
+ **그룹 접두사** — 그룹 클레임 앞에 추가할 접두사를 입력합니다. 기존 이름(예:` system: groups`)과의 충돌을 방지하기 위해 접두사가 그룹 클레임 앞에 추가됩니다. 예를 들어, 값 `oidc:`는 `oidc:engineering` 및 `oidc:infra`와 같은 그룹 이름을 생성합니다. `system:` 또는 해당 문자열의 어떤 부분도 지정하지 마세요.
+ **필수 클레임** — **클레임 추가**를 선택하고 클라이언트 ID 토큰에 필요한 클레임을 설명하는 하나 이상의 키 값 페어를 입력합니다. 키 값 페어는 ID 토큰에 필요한 클레임을 설명합니다. 설정된 경우 각 클레임은 일치하는 값이 ID 토큰에 존재하는 것으로 확인됩니다.
1. 클러스터와 OIDC ID 제공업체에 `kubectl`을 사용하려면 Kubernetes Documentation의 [Using kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl)을 참조하세요.
## IAM; 정책 예
OIDC 자격 증명 공급자가 클러스터에 연결되지 않도록 하려면 다음 IAM 정책을 생성하여 Amazon EKS 관리자의 IAM 계정에 연결합니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) 및 [IAM 자격 증명 권한 추가](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)와 서비스 권한 부여 참조의 [Actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerserviceforkubernetes.html)를 참조하세요.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "denyOIDC",
"Effect": "Deny",
"Action": [
"eks:AssociateIdentityProviderConfig"
],
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/*"
},
{
"Sid": "eksAdmin",
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
}
]
}
```
다음 예제 정책은 `clientID`가 `kubernetes`이고 `issuerUrl`이 `https://cognito-idp.us-west-2amazonaws.com/*`인 경우 OIDC 자격 증명 공급자 연결을 허용합니다.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCognitoOnly",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotLikeIfExists": {
"eks:issuerUrl": "https://cognito-idp.us-west-2.amazonaws.com/*"
}
}
},
{
"Sid": "DenyOtherClients",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotEquals": {
"eks:clientId": "kubernetes"
}
}
},
{
"Sid": "AllowOthers",
"Effect": "Allow",
"Action": "eks:*",
"Resource": "*"
}
]
}
```
# 클러스터에서 OIDC 자격 증명 공급자 연결 해제
클러스터에서 OIDC 자격 증명 공급자의 연결을 해제하면 공급자에 포함된 사용자가 더 이상 클러스터에 액세스할 수 없습니다. 하지만 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)로 계속 클러스터에 액세스할 수 있습니다.
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. [**OIDC 자격 증명 공급자(OIDC Identity Providers)**] 섹션에서 [**연결 해제(Disassociate)**]를 선택하고 자격 증명 공급자 이름을 입력한 다음 `Disassociate`를 선택합니다.
# AWS Management Console에서 Kubernetes 리소스 보기
AWS Management Console을 사용하면 클러스터에 배포된 Kubernetes 리소스를 볼 수 있습니다. AWS CLI 또는 [eksctl](https://eksctl.io/)로는 Kubernetes 리소스를 볼 수 없습니다. 명령줄 도구를 사용하여 Kubernetes 리소스를 보려면 [kubectl](install-kubectl.md)을 사용합니다.
**참고**
AWS Management Console의 **컴퓨팅** 탭에서 **리소스** 탭과 **노드** 섹션을 보려면 사용 중인 [IAM 위탁자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)에 특정 IAM 및 Kubernetes 권한이 있어야 합니다. 자세한 내용은 [필수 권한](#view-kubernetes-resources-permissions) 섹션을 참조하세요.
1. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks/home#/clusters)을 엽니다.
1. **클러스터(Clusters)** 목록에서 보려는 Kubernetes 리소스를 포함하는 클러스터를 선택합니다.
1. **리소스(Resources)** 탭을 선택합니다.
1. 보려는 리소스에 대한 **리소스 유형** 그룹을 선택합니다(예: **워크로드)**. 해당 그룹의 리소스 유형 목록이 표시됩니다.
1. **워크로드(Workloads)** 그룹에서 리소스 유형을 선택합니다(예: **배포(Deployments)**). 리소스 유형 설명, 리소스 유형의 자세한 내용이 있는 Kubernetes 설명서에 대한 링크, 클러스터에 배포된 해당 유형의 리소스 목록이 표시됩니다. 목록이 비어 있는 경우 클러스터에 배포된 해당 유형의 리소스가 없습니다.
1. 이에 대한 자세한 내용을 확인하려면 리소스를 선택합니다. 다음 예제를 시도해 보세요.
+ **워크로드** 그룹을 선택하고, **배포** 리소스 유형을 선택한 다음 **coredns** 리소스를 선택합니다. 리소스를 선택하면 기본적으로 **구조화된 뷰**에 있습니다. 일부 리소스 유형의 경우 **구조화된 뷰**의 **포드** 섹션이 표시됩니다. 이 섹션에서는 워크로드에 의해 관리되는 포드가 나열됩니다. 포드에 대한 정보를 보려면 나열된 모든 포드를 선택할 수 있습니다. 일부 리소스 유형의 정보가 **구조적 뷰(Structured View)**에 표시됩니다. 리소스 페이지의 오른쪽 상단 모서리에서 **원시 뷰(Raw view)**를 선택하는 경우 리소스에 대한 Kubernetes API의 전체 JSON 응답이 표시됩니다.
+ **클러스터(Cluster)** 그룹을 선택한 다음 **노드(Nodes)** 리소스 유형을 선택합니다. 클러스터에 모든 노드 목록이 표시됩니다. 노드는 모든 [Amazon EKS 노드 유형](eks-compute.md)일 수 있습니다. 이 목록은 클러스터의 **컴퓨팅** 탭을 선택하는 경우 **노드** 섹션에 표시되는 것과 동일한 목록입니다. 목록에서 노드 리소스를 선택합니다. **구조화된 뷰**에 **포드** 섹션도 표시됩니다. 이 섹션에서는 노드에서 실행되는 모든 포드를 보여줍니다.
## 필수 권한
AWS Management Console의 **컴퓨팅** 탭에서 **리소스** 탭과 **노드** 섹션을 보려면 사용 중인 [IAM 위탁자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)에 특정 최소 IAM 및 Kubernetes 권한이 있어야 합니다. IAM 및 Kubernetes RBAC 권한이 모두 올바르게 구성되어 있어야 합니다. IAM 보안 주체에 필요한 권한을 할당하려면 다음 단계를 완료하세요.
1. `eks:AccessKubernetesApi` 및 Kubernetes 리소스를 보는 데 필요한 기타 IAM 권한이 사용 중인 IAM 위탁자에 할당되었는지 확인하세요. IAM 보안 주체의 권한을 편집하는 방법에 대한 자세한 내용은 IAM 사용 설명서의 [보안 주체에 대한 액세스 제어](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-principals) 섹션을 참조하세요. 역할의 권한을 편집하는 방법에 대한 자세한 내용을 알아보려면 IAM 사용 설명서의 [역할 권한 정책(콘솔) 수정](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy)을 참조하세요.
다음 정책 예에는 계정의 모든 클러스터에 대한 Kubernetes 리소스를 보는 데 필요한 위탁자의 권한이 포함되어 있습니다. *111122223333*을 AWS 계정 ID로 바꿉니다.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:ListUpdates",
"eks:AccessKubernetesApi",
"eks:ListAddons",
"eks:DescribeCluster",
"eks:DescribeAddonVersions",
"eks:ListClusters",
"eks:ListIdentityProviderConfigs",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:111122223333:parameter/*"
}
]
}
```
[연결된 클러스터](eks-connector.md)에서 노드를 보려면 [Amazon EKS 커넥터 IAM 역할](connector-iam-role.md)이 클러스터에서 보안 주체를 가장할 수 있어야 합니다. 그러면 [Amazon EKS Connector](eks-connector.md)에서 위탁자를 Kubernetes 사용자에게 매핑할 수 있습니다.
1. EKS 액세스 항목을 사용하여 Kubernetes RBAC 권한을 구성합니다.
**EKS 액세스 항목이란 무엇인가요?**
EKS 액세스 항목은 IAM 위탁자(사용자 및 역할)에게 Kubernetes 클러스터에 대한 액세스 권한을 부여하는 간소화된 방법입니다. Kubernetes RBAC 리소스와 `aws-auth` ConfigMap을 수동으로 관리하는 대신 액세스 항목은 AWS에서 제공하는 관리형 정책을 사용하여 IAM과 Kubernetes 권한 간 매핑을 자동으로 처리합니다. 액세스 항목에 대한 자세한 내용은 [EKS 액세스 항목을 사용한 IAM 사용자에게 Kubernetes에 대한 액세스 권한 부여](access-entries.md) 섹션을 참조하세요. 사용 가능한 액세스 정책 및 권한에 대한 자세한 내용은 [액세스 정책 권한](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html)을 참조하세요.
두 가지 방법으로 액세스 항목에 Kubernetes 권한을 연결할 수 있습니다.
+ **액세스 정책 사용:** 액세스 정책은 AWS에서 유지 관리하는 사전 정의된 Kubernetes 권한 템플릿입니다. 여기에서는 일반적인 사용 사례에 대한 표준화된 권한 세트를 제공합니다.
+ **Kubernetes 그룹 참조:** IAM ID를 Kubernetes 그룹에 연결하는 경우 그룹 권한을 부여하는 Kubernetes 리소스를 생성할 수 있습니다. 자세한 내용은 Kubernetes 문서의 [Using RBAC Authorization(RBAC 승인 사용)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 참조하세요.
1. AWS CLI를 사용하여 IAM 위탁자에 대한 액세스 항목을 생성하세요. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다. *111122223333*을 계정 ID로 바꿉니다.
```
aws eks create-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
예제 출력은 다음과 같습니다.
```
{
"accessEntry": {
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"kubernetesGroups": [],
"accessEntryArn": "arn:aws:eks:region-code:111122223333:access-entry/my-cluster/role/111122223333/my-console-viewer-role/abc12345-1234-1234-1234-123456789012",
"createdAt": "2024-03-15T10:30:45.123000-07:00",
"modifiedAt": "2024-03-15T10:30:45.123000-07:00",
"tags": {},
"username": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"type": "STANDARD"
}
}
```
1. 정책을 액세스 항목에 연결하세요. Kubernetes 리소스를 보려면 `AmazonEKSViewPolicy`를 사용하세요.
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster
```
예제 출력은 다음과 같습니다.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"associatedAt": "2024-03-15T10:31:15.456000-07:00"
}
```
네임스페이스별 액세스의 경우 정책 범위를 특정 네임스페이스로 지정할 수 있습니다.
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=namespace,namespaces=default,kube-system
```
1. 액세스 항목이 성공적으로 생성되었는지 확인하세요.
```
aws eks describe-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
1. 연결된 정책을 나열하여 정책 연결을 확인하세요.
```
aws eks list-associated-access-policies \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
예제 출력은 다음과 같습니다.
```
{
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster"
},
"associatedAt": "2024-03-15T10:31:15.456000-07:00",
"modifiedAt": "2024-03-15T10:31:15.456000-07:00"
}
]
}
```
## CloudTrail 가시성
Kubernetes 리소스를 볼 때 CloudTrail 로그에 다음 작업 이름이 표시됩니다.
+ `AccessKubernetesApi` - 리소스를 읽거나 보는 경우
이 CloudTrail 이벤트는 Kubernetes 리소스에 대한 읽기 액세스의 감사 추적을 제공합니다.
**참고**
이 작업 이름은 감사 목적으로만 CloudTrail 로그에 표시됩니다. 이는 IAM 작업이 아니며 IAM 정책 설명에 사용할 수 없습니다. IAM 정책을 통해 Kubernetes 리소스에 대한 읽기 액세스를 제어하려면 [필수 권한](#view-kubernetes-resources-permissions) 섹션에 나온 대로 `eks:AccessKubernetesApi` 권한을 사용합니다.
# Kubernetes API에 대한 쓰기 액세스 권한을 AWS 서비스에 부여
## 필수 권한
AWS 서비스가 Amazon EKS 클러스터의 Kubernetes 리소스에서 쓰기 작업을 수행할 수 있도록 하려면 `eks:AccessKubernetesApi` 및 `eks:MutateViaKubernetesApi` IAM 권한을 모두 부여해야 합니다.
예를 들어 Amazon SageMaker HyperPod는 이러한 권한을 사용하여 SageMaker AI Studio에서 모델 배포를 지원합니다. 자세한 내용은 Amazon SageMaker AI 개발자 안내서의 [Set up optional JavaScript SDK permissions](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-setup.html#sagemaker-hyperpod-model-deployment-setup-optional-js)를 참조하세요.
**중요**
생성, 업데이트 및 삭제와 같은 쓰기 작업에는 두 권한이 모두 필요합니다. 두 권한 중 하나가 누락된 경우 쓰기 작업에 실패합니다.
## CloudTrail 가시성
Kubernetes 리소스에서 쓰기 작업을 수행하는 동안 CloudTrail 로그에 특정 작업 이름이 표시됩니다.
+ `createKubernetesObject` - 새 리소스를 생성하는 경우
+ `updateKubernetesObject` - 기존 리소스를 수정하는 경우
+ `deleteKubernetesObject` - 리소스를 제거하는 경우
이러한 CloudTrail 이벤트는 Kubernetes 리소스에서 수정된 모든 사항에 대한 자세한 감사 추적을 제공합니다.
**참고**
이러한 작업 이름은 감사 목적으로만 CloudTrail 로그에 표시됩니다. 이는 IAM 작업이 아니며 IAM 정책 설명에 사용할 수 없습니다. IAM 정책을 통해 Kubernetes 리소스에 대한 쓰기 액세스를 제어하려면 [필수 권한](#mutate-kubernetes-resources-permissions) 섹션에 표시된 `eks:MutateViaKubernetesApi` 권한을 사용합니다.
# Kubeconfig 파일을 생성하여 kubectl을 EKS 클러스터에 연결
**작은 정보**
향후 예정된 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)합니다.
이 주제에서는 클러스터에 대한 `kubeconfig` 파일을 생성하거나 기존 파일을 업데이트합니다.
`kubectl` 명령줄 도구는 `kubeconfig` 파일의 구성 정보를 사용하여 클러스터의 API 서버와 통신합니다. 자세한 내용은 쿠버네티스 문서의 [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조하세요.
Amazon EKS는 클러스터 인증을 위해 `kubectl`과 함께 `aws eks get-token` 명령을 사용합니다. 기본적으로 AWS CLI에서는 다음 명령을 사용하여 반환되는 것과 동일한 보안 인증 정보를 사용합니다.
```
aws sts get-caller-identity
```
+ 기존 Amazon EKS 클러스터. 배포하려면 [Amazon EKS 시작하기](getting-started.md) 섹션을 참조하세요.
+ `kubectl` 명령줄 도구는 장치 또는 AWS CloudShell에 설치됩니다. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. 예를 들어, 클러스터 버전이 `1.29`인 경우 `kubectl` 버전 `1.28`, `1.29` 또는 `1.30`를 함께 사용할 수 있습니다. `kubectl`을 설치하거나 업그레이드하려면 [`kubectl` 및 `eksctl` 설정](install-kubectl.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)를 참조하세요.
+ 지정한 클러스터에 대해 `eks:DescribeCluster` API 작업을 사용할 수 있는 권한을 보유한 IAM 사용자 또는 역할. 자세한 내용은 [Amazon EKS 자격 증명 기반 정책 예제](security-iam-id-based-policy-examples.md) 섹션을 참조하세요. 자체 OpenID Connect 제공업체의 ID를 사용하여 클러스터에 액세스하는 경우 Kubernetes Documentation의 [Using kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl)을 참조하여 `kube config` 파일을 생성하거나 업데이트합니다.
## 자동으로 `kubeconfig` 파일 생성
+ 장치에 설치 및 구성된 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)를 참조하세요.
+ 지정한 클러스터에 대해 `eks:DescribeCluster` API 작업을 사용할 수 있는 권한. 자세한 내용은 [Amazon EKS 자격 증명 기반 정책 예제](security-iam-id-based-policy-examples.md) 섹션을 참조하세요.
1. 클러스터에 대해 `kubeconfig` 파일을 생성 또는 업데이트합니다. *region-code*를 클러스터를 생성한 AWS 리전으로 바꾸고 *my-cluster*를 클러스터 이름으로 바꿉니다.
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
기본적으로 구성 파일은 홈 디렉터리의 기본 `kubeconfig` 경로(`.kube`)에 생성되거나 해당 위치의 기존 `config` 파일과 병합됩니다. `--kubeconfig` 옵션을 사용하여 다른 경로를 지정할 수 있습니다.
`--role-arn` 옵션으로 IAM 역할 ARN을 지정하면 `kubectl` 명령을 실행할 때 인증에 사용할 수 있습니다. 그렇지 않으면 기본 AWS CLI 또는 SDK 자격 증명 체인의 [IAM 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)가 사용됩니다. `aws sts get-caller-identity` 명령을 실행하여 기본 AWS CLI 또는 SDK ID를 확인할 수 있습니다.
사용 가능한 모든 옵션을 알아보려면 `aws eks update-kubeconfig help` 명령을 실행하거나 *AWS CLI 명령 참조*의 [update-kubeconfig](https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html)를 참조하세요.
1. 구성을 테스트합니다.
```
kubectl get svc
```
예제 출력은 다음과 같습니다.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes ClusterIP 10.100.0.1 443/TCP 1m
```
권한 부여 또는 리소스 유형 오류가 표시되는 경우 문제 해결 주제의 [권한이 없거나 액세스가 거부됨(`kubectl`)](troubleshooting.md#unauthorized) 부분을 참조하세요.
# Kubernetes 서비스 계정을 사용하여 Kubernetes 워크로드에 AWS에 대한 액세스 권한 부여
[서비스 계정 관리](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)
## 서비스 계정 토큰
[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
```
## 클러스터 추가 기능
다음 클러스터 추가 기능은 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 및 액세스 관리 권한 부여
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 비교
대략적으로 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 역할
**작은 정보**
향후 예정된 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) 백그라운드 정보
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 공급자 생성
클러스터에는 [OpenID Connect](https://openid.net/connect/)(OIDC) 발급자 URL이 연결되어 있습니다. 서비스 계정에 AWS Identity and Access Management(IAM) 역할을 사용하려면 클러스터의 OIDC 발급자 URL에 IAM OIDC 제공자가 있어야 합니다.
## 사전 조건
+ 기존 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)
1. 장치에 설치된 `eksctl` 명령줄 도구의 버전 `0.215.0` 이상 또는 AWS CloudShell이 필요합니다. `eksctl`을 설치 또는 업그레이드하려면 `eksctl` 설명서에서 [설치](https://eksctl.io/installation)를 참조하세요.
1. 클러스터의 OIDC 발행자 ID를 판단합니다.
클러스터의 OIDC 발행자 ID를 검색하고 변수에 저장합니다. ``을 사용자의 고유한 값으로 교체합니다.
```
cluster_name=
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..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 콘솔)
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 역할 할당
이 주제에서는 Kubernetes 서비스 계정이 AWS Identity and Access Management(IAM) 역할을 수임하도록 구성하는 방법에 대해 설명합니다. 서비스 계정을 사용하도록 구성된 모든 포드는 해당 역할에 액세스 권한이 있는 모든 AWS 서비스에 액세스할 수 있습니다.
## 사전 조건
+ 기존 클러스터가 있어야 합니다. 아직 없는 경우 [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 정책 생성
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 역할 생성 및 연결
IAM 역할을 생성하고 Kubernetes 서비스 계정에 연결합니다. `eksctl` 또는 AWS CLI를 사용할 수 있습니다.
### 역할 생성 및 연결(eksctl)
이 `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)
IAM 역할을 수임하려는 기존 Kubernetes 서비스 계정이 있는 경우 이 단계를 건너뛸 수 있습니다.
1. Kubernetes 서비스 계정을 생성합니다. 다음 콘텐츠를 디바이스에 복사합니다. *my-service-account*를 원하는 이름으로 바꾸고 필요한 경우 *기본*을 다른 네임스페이스로 바꿉니다. *기본*을 변경하는 경우, 네임스페이스가 이미 존재해야 합니다.
```
cat >my-service-account.yaml <
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:
Mountable secrets: my-service-account-token-qqjfl
Tokens: my-service-account-token-qqjfl
[...]
```
## 다음 단계
+ [Kubernetes 서비스 계정을 사용하도록 포드 구성](pod-configuration.md)
# Kubernetes 서비스 계정을 사용하도록 포드 구성
포드가 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 <
[서비스 계정에 대한 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를 사용하여 다른 계정에 인증
다른 계정의 클러스터에서 ID 공급자를 생성하거나 연결된 `AssumeRole` 작업을 사용하여 크로스 계정 IAM 권한을 구성할 수 있습니다. 다음 예에서 *계정 A*는 서비스 계정에 대해 IAM 역할을 지원하는 Amazon EKS 클러스터를 소유합니다. 이 클러스터에서 실행되는 포드는 *계정 B*의 IAM 권한을 수임해야 합니다.
+ **옵션 1**은 더 간단하지만 계정 B가 계정 A의 클러스터에 대한 OIDC ID 제공업체를 생성하고 관리해야 합니다.
+ **옵션 2**는 계정 A에서 OIDC 관리를 유지하지만 두 번의 `AssumeRole` 직접 호출을 통해 역할을 연결해야 합니다.
## 옵션 1: 다른 계정의 클러스터에서 ID 제공업체 생성
이 예제에서 계정 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` 작업 사용
이 접근 방식에서 각 계정은 IAM 역할을 생성합니다. 계정 B의 역할은 계정 A를 신뢰하고 계정 A의 역할은 OIDC 페더레이션을 사용하여 클러스터에서 자격 증명을 가져옵니다. 그런 다음 포드는 AWS CLI 프로파일을 사용하여 두 역할을 함께 연결합니다.
### 1단계: 계정 B에서 대상 역할 생성
계정 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(*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는 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단계: 역할을 연결하도록 포드 구성
포드가 계정 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 사용
**보안 인증 정보 사용**
서비스 계정(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에 대한 설치 지침을 따르세요.
## 고려 사항
### Java
Java를 사용할 때는 클래스 경로에 **`sts` 모듈을 포함해야 합니다. 자세한 내용은 Java SDK 문서의 [WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html)를 참조하세요.
# 서명 키를 가져와서 OIDC 토큰 검증
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) 섹션을 참조하세요.
## 사전 조건
+ 클러스터에 대한 기존 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)을 참조하세요.
## 절차
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 서비스에 대한 액세스 권한을 부여하는 방법 알아보기
포드의 컨테이너에 있는 애플리케이션은 AWS SDK 또는 AWS CLI를 사용하여 AWS ID 및 액세스 관리(IAM) 권한을 사용하여 AWS 서비스에 API 요청을 할 수 있다. 애플리케이션은 AWS 자격 증명으로 AWS API 요청에 서명해야 합니다.
**EKS Pod Identity는 Amazon EC2 인스턴스 프로필이 Amazon EC2 인스턴스에 자격 증명을 제공하는 것과 비슷한 방식으로 애플리케이션에 대한 자격 증명을 관리하는 기능을 제공합니다. AWS 자격 증명을 생성하여 컨테이너에 배포하거나 Amazon EC2 인스턴스의 역할을 사용하는 대신에 IAM 역할을 Kubernetes 서비스 계정과 연결하고 서비스 계정을 사용하도록 포드를 구성합니다.
[](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의 이점
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 설정 개요
다음 절차를 완료하여 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
+ Kubernetes 서비스 계정에 IAM 역할 매핑을 위해 클러스터당 최대 5,000개의 EKS Pod Identity 연결이 지원됩니다.
## 고려 사항
+ **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 클러스터 버전
EKS Pod Identity를 사용하려면 클러스터의 플랫폼 버전이 다음 표에 나열된 버전과 동일한 버전 또는 이후 버전이거나 Kubernetes 버전이 표에 나열된 버전보다 이후 버전이어야 합니다. Kubernetes 버전용 Amazon EKS Pod Identity 에이전트의 권장 버전을 찾으려면 [Amazon EKS 추가 기능 버전의 클러스터와의 호환성 확인](addon-compat.md) 섹션을 참조하세요.
| Kubernetes 버전 | 플랫폼 버전 |
| --- | --- |
| 나열되지 않은 Kubernetes 버전 | 모든 플랫폼 버전 지원 |
| `1.28` | `eks.4` |
### EKS Pod Identity 제한 사항
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 작동 방식 이해
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 사용
코드에서 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 에이전트와 포드의 작동 방식
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 에이전트 설정
Amazon EKS Pod Identity는 Amazon EC2 인스턴스 프로필이 Amazon EC2 인스턴스에 자격 증명을 제공하는 것과 비슷한 방식으로 애플리케이션에 대한 자격 증명을 관리하는 기능을 제공합니다.
Amazon EKS Pod Identity는 추가 **EKS Auth API와 각 노드에서 실행되는 에이전트 포드를 통해 워크로드에 보안 인증 정보를 제공합니다.
**작은 정보**
EKS Auto Mode 클러스터에 EKS Pod Identity 에이전트를 설치할 필요가 없습니다. 이 기능은 EKS Auto Mode에 내장되어 있습니다.
## 고려 사항
+ 기본적으로 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 에이전트 생성
### 에이전트 필수 조건
+ 기존 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 콘솔을 사용하여 에이전트 설정
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를 사용하여 에이전트 설정
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 역할 할당
이 주제에서는 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 콘솔)
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)
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 <
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"
}
]
}
```
이전 단계에서 예제 정책을 생성한 경우 출력은 동일합니다. 다른 정책을 생성한 경우 *예제* 내용이 다릅니다.
## 다음 단계
[서비스 계정으로 AWS 서비스에 액세스하도록 포드 구성](pod-id-configure-pods.md)
# EKS Pod Identity 대상 IAM 역할을 사용하여 AWS 리소스에 액세스
Amazon Elastic Kubernetes Service(Amazon EKS)에서 애플리케이션을 실행할 때 다른 AWS 계정에 있는 AWS 리소스에 액세스해야 할 수 있습니다. 이 설명서에서는 Kubernetes 포드가 대상 역할을 사용하여 다른 AWS 리소스에 액세스할 수 있도록 EKS Pod Identity를 사용하여 교차 계정 액세스를 설정하는 방법을 보여줍니다.
## 사전 조건
시작하기 전에 다음 단계를 완료합니다.
+ [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)
## 작동 방식
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 계정의 리소스에 대한 보안 액세스를 허용합니다.
## 캐싱 고려 사항
캐싱 메커니즘으로 인해 기존 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 역할 생성 및 연결
이 단계에서는 대상 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 역할 생성
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 역할 신뢰 정책 업데이트
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 역할에 대한 권한 정책 업데이트
이 단계에서는 대상 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 역할 연결
이 단계에서는 대상 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 서비스에 액세스하도록 포드 구성
포드가 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 <
속성 기반 액세스 제어(ABAC)는 속성을 함께 결합하는 정책을 통해 사용자에게 권한을 부여합니다. EKS Pod Identity는 클러스터 이름, 네임스페이스, 서비스 계정 이름 등의 속성을 사용하여 각 포드의 임시 자격 증명에 태그를 연결합니다. 관리자는 이러한 역할 세션 태그를 사용하여 일치하는 태그를 기반으로 AWS 리소스에 대한 액세스를 허용하여 여러 서비스 계정에서 작업할 수 있는 단일 역할을 작성할 수 있습니다. 역할 세션 태그에 대한 지원을 추가함으로써 동일한 IAM 역할과 IAM 정책을 재사용하면서 클러스터 간 및 클러스터 내 워크로드 간에 더 엄격한 보안 경계를 적용할 수 있습니다.
## 태그가 있는 샘플 정책
다음은 해당 객체에 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}"
}
}
}
]
}
```
## 세션 태그 활성화 또는 비활성화
EKS Pod Identity는 역할을 수임할 때 사전 정의된 세션 태그 세트를 추가합니다. 관리자는 이러한 세션 태그를 사용하여 일치하는 태그를 기반으로 AWS 리소스에 대한 액세스를 허용하여 여러 리소스에서 작업할 수 있는 단일 역할을 작성할 수 있습니다.
### 세션 태그 활성화
세션 태그는 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`
### 세션 태그 비활성화
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. **변경 사항 저장**을 선택합니다.
## 교차 계정 태그
EKS Pod Identity에서 추가한 모든 세션 태그는 **전이적이며, 워크로드가 역할을 다른 계정으로 전환하는 데 사용하는 모든 `AssumeRole` 작업에 태그 키와 값이 전달됩니다. 다른 계정의 정책에 이러한 태그를 사용하여 교차 계정 시나리오에서 액세스를 제한할 수 있습니다. 자세한 내용은 IAM 사용 설명서의 [세션 태그를 사용하는 역할 체인](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining)을 참조하세요.**
## 사용자 지정 태그
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 사용
## EKS Pod Identity 보안 인증 정보 사용
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` 비활성화
## AWS Management Console
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
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 역할 생성
```
{
"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)을 참조하세요.