**이 페이지 개선에 도움 주기** 이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다. # 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`를 입력하여 쉘 프롬프트로 돌아갑니다.