ConfigMap으로 IAM 사용자에게 Kubernetes 액세스 권한 부여

ConfigMap으로 IAM 사용자에게 Kubernetes 액세스 권한 부여

aws-auth ConfigMap을 사용해 IAM 보안 주체에게 Amazon EKS 클러스터 액세스 권한을 부여하는 방법을 설명합니다.

출처: 문서

본문

중요: aws-auth ConfigMap은 더 이상 사용되지 않습니다(deprecated). Kubernetes API 액세스를 관리하는 권장 방법은 "EKS 액세스 항목으로 IAM 사용자에게 Kubernetes 액세스 권한 부여"를 참고하세요.

IAM 보안 주체를 사용한 클러스터 액세스는 Amazon EKS 컨트롤 플레인에서 실행되는 AWS IAM Authenticator for Kubernetes가 활성화합니다. 이 인증자는 aws-auth ConfigMap에서 구성 정보를 가져옵니다. 모든 aws-auth ConfigMap 설정은 GitHub의 "Full Configuration Format"을 참고하세요.

IAM 보안 주체를 Amazon EKS 클러스터에 추가

Amazon EKS 클러스터를 생성하면 클러스터를 생성한 IAM 보안 주체가 Amazon EKS 컨트롤 플레인의 클러스터 역할 기반 액세스 제어(RBAC) 구성에서 자동으로 system:masters 권한을 부여받습니다. 이 보안 주체는 표시되는 구성에 나타나지 않으므로, 원래 클러스터를 만든 보안 주체를 추적해 두어야 합니다. 추가 IAM 보안 주체에게 클러스터와 상호작용할 수 있는 권한을 부여하려면 Kubernetes 내에서 aws-auth ConfigMap을 편집하고, aws-auth ConfigMap에 지정한 group 이름으로 Kubernetes rolebinding 또는 clusterrolebinding을 생성하세요.

참고: Kubernetes 역할 기반 액세스 제어(RBAC) 구성에 대한 자세한 내용은 Kubernetes 문서의 "RBAC 인증 사용"을 참고하세요.

  1. kubectl이 클러스터에 액세스할 때 사용하는 자격 증명을 확인합니다. 컴퓨터에서 다음 명령으로 kubectl이 사용하는 자격 증명을 볼 수 있습니다. 기본 경로를 사용하지 않는다면 ~/.kube/config를 kubeconfig 파일 경로로 바꾸세요.
cat ~/.kube/config

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

[...]
contexts:
- context:
    cluster: my-cluster.region-code.eksctl.io
    user: [email protected]
  name: [email protected]
current-context: [email protected]
[...]

위 예제 출력에서 admin이라는 사용자의 자격 증명이 my-cluster라는 클러스터에 대해 구성되어 있습니다. 이 사용자가 클러스터를 생성한 사용자라면 이미 클러스터에 액세스할 수 있습니다. 클러스터를 생성한 사용자가 아니라면 나머지 단계를 완료해 다른 IAM 보안 주체에게 클러스터 액세스를 활성화해야 합니다. IAM 모범 사례에서는 사용자보다 역할에 권한을 부여할 것을 권장합니다. 다음 명령으로 현재 클러스터에 액세스할 수 있는 다른 보안 주체를 확인할 수 있습니다.

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 인증 사용"을 참고하세요.

  2. 기존 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의 세부 정보를 확인하고, 이전 단계의 role 또는 clusterrole이 roleRef로, 그룹 이름이 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-auth ConfigMap 변경에 도구 사용"을 참고하세요. 형식이 잘못된 aws-auth ConfigMap은 클러스터에 대한 액세스를 잃게 만들 수 있습니다.

다음 중 원하는 방법을 선택하세요: eksctl로 ConfigMap 편집 단계 보기 / ConfigMap 수동 편집 단계 보기.

eksctl로 ConfigMap 편집

사용 기기나 AWS CloudShell에 eksctl 명령줄 도구 버전 0.215.0 이상이 설치되어 있어야 합니다. eksctl을 설치하거나 업데이트하려면 eksctl 문서의 "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 모범 사례에서는 사용자보다 역할에 권한을 부여할 것을 권장합니다. 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을 클러스터에 적용" 절차를 사용해 기본 ConfigMap을 적용하세요.

  1. IAM 보안 주체를 ConfigMap에 추가합니다. IAM 그룹은 IAM 보안 주체가 아니므로 ConfigMap에 추가할 수 없습니다.
  • IAM 역할을 추가하려면(예: 페더레이션 사용자용): ConfigMap의 data 아래 mapRoles 섹션에 역할 세부 정보를 추가합니다. 파일에 이 섹션이 없으면 추가합니다. 각 항목은 다음 매개변수를 지원합니다.
    • rolearn: 추가할 IAM 역할의 ARN. 이 값에는 경로가 포함될 수 없습니다. 예를 들어 arn:aws:iam::111122223333:role/my-team/developers/role-name 같은 ARN은 지정할 수 없습니다. ARN은 arn:aws:iam::111122223333:role/role-name이어야 합니다.
    • username: IAM 역할에 매핑할 Kubernetes 내 사용자 이름.
    • groups: 역할을 매핑할 Kubernetes 그룹 또는 그룹 목록. 이 그룹은 기본 그룹이거나 clusterrolebinding 또는 rolebinding에 지정된 그룹일 수 있습니다. 자세한 내용은 Kubernetes 문서의 "기본 역할 및 역할 바인딩"을 참고하세요.
  • IAM 사용자를 추가하려면: IAM 모범 사례에서는 사용자보다 역할에 권한을 부여할 것을 권장합니다. ConfigMap의 data 아래 mapUsers 섹션에 사용자 세부 정보를 추가합니다. 파일에 이 섹션이 없으면 추가합니다. 각 항목은 다음 매개변수를 지원합니다.
    • userarn: 추가할 IAM 사용자의 ARN.
    • username: IAM 사용자에 매핑할 Kubernetes 내 사용자 이름.
    • groups: 사용자를 매핑할 Kubernetes 그룹 또는 그룹 목록. 이 그룹은 기본 그룹이거나 clusterrolebinding 또는 rolebinding에 지정된 그룹일 수 있습니다. 자세한 내용은 Kubernetes 문서의 "기본 역할 및 역할 바인딩"을 참고하세요.

username과 groups의 템플릿 변수

mapRoles와 mapUsers 항목의 username 및 groups 필드는 AWS IAM Authenticator가 인증 시 대체하는 템플릿 변수를 지원합니다. 사용 가능한 템플릿 변수는 다음과 같습니다.

  • {{AccountID}} - 인증된 IAM 보안 주체의 12자리 AWS 계정 ID.
  • {{SessionName}} - STS 역할 세션 이름으로, @ 문자는 -로 바뀝니다. EC2 인스턴스 역할의 경우 이 값은 인스턴스 ID입니다. 페더레이션 역할의 경우 페더레이션 ID입니다. sts:AssumeRole로 수임된 역할의 경우 호출자가 설정한 RoleSessionName 매개변수의 값입니다.
  • {{SessionNameRaw}} - 문자 대체 없이 원래 그대로의 STS 역할 세션 이름.
  • {{AccessKeyID}} - 요청을 인증하는 데 사용된 AWS 액세스 키 ID.
  • {{EC2PrivateDNSName}} - EC2 인스턴스의 프라이빗 DNS 이름. 이 변수는 세션 이름이 유효한 EC2 인스턴스 ID여야 하며 ec2:DescribeInstances API 호출을 수행합니다.

중요: {{SessionName}}과 {{SessionNameRaw}} 값은 역할이 sts:AssumeRole로 수임될 때 사용자가 제어합니다. 호출자는 RoleSessionName 매개변수를 거의 임의의 문자열로 설정할 수 있습니다. 이 변수를 username 필드에 사용하면, 매핑된 역할을 수임할 수 있는 호출자가 예약된 접두사(예: system:, eks:, aws:, amazon:, iam:)와 일치하지 않는 어떤 Kubernetes 사용자 이름으로든 가장할 수 있습니다. 이 변수를 groups 필드에 사용하면 호출자가 세션 이름을 조작해 자신의 Kubernetes 그룹 구성원을 선택할 수 있습니다. {{SessionName}}을 username이나 groups에 사용하려면 그 역할을 수임할 수 있는 모든 보안 주체를 신뢰할 수 있을 때만 사용하세요.

예를 들어 다음 YAML 블록에는 다음이 포함됩니다.

  • IAM 노드 인스턴스를 Kubernetes 그룹에 매핑하여 노드가 클러스터에 등록되고, 모든 클러스터의 모든 Kubernetes 리소스를 볼 수 있는 Kubernetes 그룹에 매핑된 my-console-viewer-role IAM 역할을 매핑하는 mapRoles 섹션. my-console-viewer-role IAM 역할에 필요한 IAM 및 Kubernetes 그룹 권한 목록은 "필요한 권한"을 참고하세요.
  • 기본 AWS 계정의 admin IAM 사용자를 system:masters Kubernetes 그룹에 매핑하고, 다른 AWS 계정의 my-user 사용자를 특정 네임스페이스의 Kubernetes 리소스를 볼 수 있는 Kubernetes 그룹에 매핑하는 mapUsers 섹션. my-user IAM 사용자에 필요한 IAM 및 Kubernetes 그룹 권한 목록은 "필요한 권한"을 참고하세요.

필요에 따라 줄을 추가하거나 제거하고 모든 예제 값을 자신의 값으로 바꾸세요.

# 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을 사용해 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 인증자 구성 맵을 다운로드, 편집, 적용합니다.
  • 구성 맵을 다운로드합니다.
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
  • aws-auth-cm.yaml 파일에서 rolearn을 노드와 연결된 IAM 역할의 Amazon Resource Name(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 템플릿으로 생성된 노드 그룹용

  • 구성을 적용합니다. 이 명령은 완료되는 데 몇 분이 걸릴 수 있습니다.

kubectl apply -f aws-auth-cm.yaml

참고: 인증 또는 리소스 유형 오류가 발생하면 문제 해결 주제의 "Unauthorized or access denied (kubectl)"을 참고하세요.

  1. 노드 상태를 관찰하고 Ready 상태에 도달할 때까지 기다립니다.
kubectl get nodes --watch

Ctrl+C를 눌러 셸 프롬프트로 돌아갑니다.

더 알아보기 (Learn more)