IAM 사용자와 역할에 Kubernetes API 접근 권한 부여하기

IAM 사용자와 역할에 Kubernetes API 접근 권한 부여하기

클러스터의 Kubernetes API 엔드포인트에 인증할 수 있는 두 가지 ID 유형과, IAM ID를 Kubernetes 권한과 연결하는 방법을 알아봐요.

출처: 문서

본문

클러스터에는 Kubernetes API 엔드포인트가 있어요. Kubectl은 이 API를 사용해요. 다음 두 가지 유형의 ID로 이 API에 인증할 수 있어요:

• AWS Identity and Access Management(IAM) 주체 (역할 또는 사용자) — 이 유형은 IAM에 대한 인증이 필요해요. 사용자는 IAM 사용자로 AWS에 로그인하거나 ID 소스를 통해 제공된 자격 증명으로 연합 ID를 사용할 수 있어요. 사용자는 관리자가 이전에 IAM 역할을 사용해 ID 연합을 설정한 경우에만 연합 ID로 로그인할 수 있어요. 사용자가 연합을 통해 AWS에 접근하면 간접적으로 역할을 가정(assume)하는 것이에요. 이 유형의 ID를 사용할 때 다음을 할 수 있어요:

  • 클러스터의 Kubernetes 객체로 작업할 수 있는 Kubernetes 권한을 할당. IAM 주체가 클러스터의 Kubernetes 객체에 접근할 수 있도록 권한을 할당하는 방법은 Grant IAM users access to Kubernetes with EKS access entries 참고.
  • Amazon EKS API, AWS CLI, AWS CloudFormation, AWS Management Console, eksctl로 Amazon EKS 클러스터와 그 리소스로 작업할 수 있는 IAM 권한을 할당. 자세한 내용은 Service Authorization Reference의 Actions defined by Amazon Elastic Kubernetes Service 참고.

  노드는 IAM 역할을 가정해 클러스터에 조인해요. IAM 주체를 사용해 클러스터에 접근하는 기능은 Amazon EKS 제어 플레인에서 실행되는 Kubernetes용 AWS IAM Authenticator가 제공해요.

• 자체 OpenID Connect(OIDC) 프로바이더의 사용자 — 이 유형은 OIDC 프로바이더에 대한 인증이 필요해요. Amazon EKS 클러스터로 자체 OIDC 프로바이더를 설정하는 방법은 Grant users access to Kubernetes with an external OIDC provider 참고. 이 유형의 ID를 사용할 때 다음을 할 수 있어요:

  • 클러스터의 Kubernetes 객체로 작업할 수 있는 Kubernetes 권한을 할당.
  • Amazon EKS API, AWS CLI, AWS CloudFormation, AWS Management Console, eksctl로 Amazon EKS 클러스터와 그 리소스로 작업할 수 있는 IAM 권한은 할당할 수 없음.

두 가지 ID 유형을 모두 클러스터에 사용할 수 있어요. IAM 인증 방법은 비활성화할 수 없어요. OIDC 인증 방법은 선택사항이에요.

IAM ID를 Kubernetes 권한과 연결하기 (Associate IAM Identities with Kubernetes Permissions)

Kubernetes용 AWS IAM Authenticator가 클러스터의 제어 플레인에 설치돼 있어요. 이를 통해 허용한 AWS Identity and Access Management(IAM) 주체(역할과 사용자)가 클러스터의 Kubernetes 리소스에 접근할 수 있게 해줘요. 다음 방법 중 하나로 IAM 주체가 클러스터의 Kubernetes 객체에 접근하도록 허용할 수 있어요:

• access entries 만들기 — 클러스터가 클러스터의 Kubernetes 버전에 대한 사전 조건 섹션에 나열된 플랫폼 버전 이상이라면 이 옵션 사용을 권장합니다. access entries로 클러스터 외부에서 IAM 주체의 Kubernetes 권한을 관리해요. EKS API, AWS Command Line Interface, AWS SDKs, AWS CloudFormation, AWS Management Console로 클러스터에 대한 접근을 추가하고 관리할 수 있어요. 즉 클러스터를 만드는 데 사용한 것과 같은 도구로 사용자를 관리할 수 있어요. 시작하려면 Change authentication mode to use access entries를 따른 다음 Migrating existing aws-auth ConfigMap entries to access entries를 따르세요.
• aws-auth ConfigMap에 항목 추가 — 클러스터의 플랫폼 버전이 사전 조건 섹션에 나열된 버전보다 이르다면 이 옵션을 사용해야 해요. 클러스터의 플랫폼 버전이 클러스터의 Kubernetes 버전에 대한 사전 조건 섹션에 나열된 플랫폼 버전 이상이고 ConfigMap에 항목을 추가했다면 해당 항목을 access entries로 마이그레이션할 것을 권장합니다. 하지만 Amazon EKS가 ConfigMap에 추가한 항목(예: 관리형 노드 그룹이나 Fargate 프로파일에 사용되는 IAM 역할용 항목)은 마이그레이션할 수 없어요. 자세한 내용은 Grant IAM users and roles access to Kubernetes APIs 참고.

aws-auth ConfigMap 옵션을 사용해야 한다면 eksctl create iamidentitymapping 명령으로 ConfigMap에 항목을 추가할 수 있어요. 자세한 내용은 eksctl 문서의 Manage IAM users and roles 참고.

클러스터 인증 모드 설정 (Set Cluster Authentication Mode)

각 클러스터에는 인증 모드가 있어요. 인증 모드는 IAM 주체가 클러스터의 Kubernetes 객체에 접근하도록 허용하는 데 사용할 수 있는 방법을 결정해요. 세 가지 인증 모드가 있어요.

중요: access entry 방법이 활성화되면 비활성화할 수 없어요.

클러스터 생성 중 ConfigMap 방법이 활성화되지 않았다면 나중에 활성화할 수 없어요. access entries 도입 전에 생성된 모든 클러스터에는 ConfigMap 방법이 활성화되어 있어요.

클러스터와 함께 하이브리드 노드를 사용한다면 API 또는 API_AND_CONFIG_MAP 클러스터 인증 모드를 사용해야 해요.

• 클러스터 내 aws-auth ConfigMap — Amazon EKS 클러스터의 원래 인증 모드예요. 클러스터를 만든 IAM 주체가 kubectl로 클러스터에 접근할 수 있는 초기 사용자예요. 초기 사용자는 aws-auth ConfigMap의 목록에 다른 사용자를 추가하고 클러스터 내의 다른 사용자에게 영향을 주는 권한을 할당해야 해요. 관리할 항목이 ConfigMap에 없으므로 이 다른 사용자들은 초기 사용자를 관리하거나 제거할 수 없어요.
• ConfigMap과 access entries 모두 — 이 인증 모드에서는 두 방법으로 IAM 주체를 클러스터에 추가할 수 있어요. 각 방법은 별도의 항목을 저장한다는 점에 주의하세요. 예를 들어 AWS CLI에서 access entry를 추가해도 aws-auth ConfigMap은 업데이트되지 않아요.
• access entries만 — 이 인증 모드에서는 EKS API, AWS Command Line Interface, AWS SDKs, AWS CloudFormation, AWS Management Console로 IAM 주체에 대한 클러스터 접근을 관리할 수 있어요. 각 access entry에는 유형이 있으며, access scope의 조합으로 주체를 특정 네임스페이스로 제한하고 access policy로 사전 구성된 재사용 가능한 권한 정책을 설정할 수 있어요. 또는 STANDARD 유형과 Kubernetes RBAC 그룹으로 사용자 지정 권한을 할당할 수 있어요.

참고: Amazon EKS Auto Mode는 Access entries를 필요로 해요.

더 알아보기 (Learn more)

• 공식 문서