EKS에서 ConfigMap 없이 API로 접근 관리하기(Cluster Access Management)

들어가며

Amazon EKS에서 클러스터 접근 관리는 기존에 AWS-Auth ConfigMap을 활용해 IAM과 Kubernetes RBAC을 연결하는 방식으로 이루어졌습니다. 

그러나 이 방식에는 여러 단점이 있었고, 이를 보완하기 위해 Cluster Access Management 기능이 새롭게 도입되었습니다.  이를 통해 AWS API를 활용한 자동화된 접근 제어가 가능해졌으며, 보다 유연하고 보안성이 강화된 관리가 가능합니다. 이번 글에서는 두 방식의 차이점과 실습을 통해 Cluster Access Management를 활용하는 방법을 살펴보겠습니다

 

AWS-Auth ConfigMap

AWS-Auth ConfigMap이란?

AWS-Auth ConfigMap은 EKS에서 IAM 사용자, role을 k8s RBAC와 연결하는 Kubernetes의 ConfigMap 리소스입니다.

 

IAM 역할과 K8s의 권한을 매핑하는데, 예를 들어 EKS 클러스터에서 특정 IAM 역할이 어떤 Kubernetes User나 Group의 권한으로 동작할지 정의합니다. 또한, AWS IAM 인증을 사용하여 kubectl 및 API 요청을 인증할 수 있습니다.

 

AWS-Auth ConfigMap 구조

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::123456789012:role/EKSNodeInstanceRole
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::123456789012:user/my-user
      username: my-user
      groups:
        - system:masters
  mapAccounts: |
    - "123456789012"

 

 

mapRoles   IAM Role → Kubernetes 사용자 및 그룹 매핑 

특정 IAM 역할을 K8s의 그룹과 연결하여 해당 역할이 클러스터에서 어떤 권한을 가질지 결정합니다. 
- 위 예제에서 EKSNodeInstanceRole 역할을 가진 IAM Role이 EKS 노드로 인식되며, system:nodes 그룹에 속합니다.

 

mapUsers  IAM User → Kubernetes 사용자 or 그룹 매핑 

특정 IAM 사용자를 Kubernetes RBAC 사용자로 등록할 수 있습니다.

- 위 예제에서는 my-user IAM 사용자가 system:masters 그룹에 속해 있으므로, Kubernetes 클러스터 관리자 권한을 갖습니다.

 

mapAccounts  AWS 계정 → 모든 역할 허용 

특정 AWS 계정에서 생성된 IAM 역할을 자동으로 신뢰할 수 있도록 허용합니다.

- 위 예제에서는 123456789012 계정에 속한 역할이 Cluster에 접근할 수 있습니다.

 

AWS-Auth ConfigMap의 단점

위와 같은 ConfigMap을 통한 AWS Auth 방법은 접근 권한을 설정하기 위해 AWS 및 Kubernetes API를 모두 설정해야 했고, 설정을 잘못하게 되면 사용자가 클러스터에서 잠길 수 있습니다. 또한, Cluster를 생성한 사용자는 암묵적으로 권한을 갖게 되어 그 담당자가 퇴사하거나 계정에 문제가 생긴다면 Cluster가 잠겨버리는 문제를 갖고 있습니다.

 

위와 같은 AWS-Auth Configmap의 불편함으로 인해 최근 Cluster Access Management(클러스터 접근 관리)라는 기능이 출시되었습니다. 

 

Cluster Access Management

CLUSTER ACCESS MANAGEMENT (클러스터 접근 관리)란?

Cluster Access Management는 AWS EKS에서 클러스터에 대한 접근을 관리 방식으로, AWS API를 활용하여 더 간편하고 유연하며 안전하게 EKS 클러스터의 접근 제어를 할 수 있습니다.

기존에는 권한을 추가하거나 수정을 해야 하면 aws-auth ConfigMap을 직접 수정해야 했지만, EKS API를 통해 자동화할 수 있습니다. 즉, IaC(Infrastructure as Code)를 활용하여 손쉽게 자동화할 수 있습니다.

 

또한, AWS IAM과 통합되어 IAM 역할 및 정책을 기반으로 접근을 설정할 수 있으며, 특정 사용자나 역할에 대한 접근을 활성화하거나 비활성화, 삭제등 세분화된 접근 제어를 할 수 있습니다.

 

주요 개념

Access Policy (접근 정책)

Amazon EKS에서 제공하는 사전 정의된 Kubernetes 권한 세트로, IAM 정책이 아닌 Kubernetes RBAC 권한을 포함합니다. 즉, 특정 역할을 수행하는 사용자가 필요로 하는 권한을 부여하는 역할을 합니다.

 

https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html

Review access policy permissions - Amazon EKS

 

위 링크를 통해 어떠한 권한이 있는지 확인하실 수 있습니다.

 

Access Entry (접근 항목)

특정 IAM User, IAM Role 또는 AWS 계정이 EKS 클러스터에 접근하는 방법을 정의하는 항목으로,  STANDARD 유형의 접근 항목에는 수동으로 접근 정책을 할당할 수 있습니다. 다른 유형의 접근 항목은 Amazon EKS에서 자동으로 권한을 관리하며, 그룹 이름을 지정하고 Kubernetes RBAC을 직접 구성하는 방법도 가능합니다.

 

Associate-Access-Policy (접근 정책 연결)

특정 Access Entry에 Access Policy(접근 정책)를 부여하는 과정입니다.

aws eks associate-access-policy \
  --cluster-name my-cluster \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSAdminPolicy \
  --principal-arn arn:aws:iam::123456789012:role/MyEKSAdminRole

 

-> 특정 IAM 역할(MyEKSAdminRole)이 AmazonEKSAdminPolicy를 통해 EKS 클러스터 관리 권한을 가지도록 설정하는 예시

 

실습

Cluster Accesss Management 적용 실습

IAM 액세스 항목 확인

 

AWS Console에 접근하여 EKS 메뉴로 진입합니다. 그 후 엑세스 탭에서 IAM 엑세스 항목을 확인합니다.

 

액세스 구성 모드 확인

 

현재 엑세스 구성 모드는 EKS API 및 ConfigMap인데, 해당 모드에서  정책 중복 시 EKS API 우선되며 ConfigMap은 무시됩니다.

 

액세스 구성 모드 변경

aws eks update-cluster-config --name $CLUSTER_NAME --access-config authenticationMode=API

 

위 명령어를 통해 현재 cluster에 access-config를 API만 사용하게끔 수정합니다. (한번 수정하면 다시 변경이 안됩니다!)

 

 

 

 

 

console에서 업데이트 기록 탭을 보게 되면 AccessConfigUpdate 유형의 업데이트가 진행되는 것을 알 수 있습니다. 

 

 

몇 분 지난 후 확인해 보면 인증모드가 EKS API로 변경된 것을 확인하실 수 있습니다.

 

맵핑 클러스터롤 정보 확인

kubectl get clusterroles -l 'kubernetes.io/bootstrapping=rbac-defaults' | grep -v 'system:'

 

EKS 클러스터에서 기본 제공 RBAC ClusterRole 목록을 조회해보겠습니다.

 

default인 admin, cluster-admin, edit, view role이 있는 것을 확인하실 수 있습니다.

 

access entry 확인

aws eks list-access-entries --cluster-name $CLUSTER_NAME | jq

 

현재 존재하는 list-access-entries를 확인해 보겠습니다.

 

현재 3개가 존재하는데, user/eks-user는 cluster를 생성할 때 넣어진 user이고,  Node에게 필요한 NodeInstanceRole, EKS ServiceRole까지 확인할 수 있습니다.

 

testuser 생성

aws iam create-user --user-name testuser

 

먼저 test user iam을 생성합니다.

 

aws iam create-access-key --user-name testuser

 

그 후 cli 방식 액세스 권한 부여합니다.

 

aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --user-name testuser

 

마지막으로 testuser 사용자에 정책을 추가합니다.

 

aws eks create-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser

이제 testuser의 access entry 생성해 보겠습니다.

 

testuser 생성 확인

aws eks list-access-entries --cluster-name $CLUSTER_NAME | jq -r .accessEntries[]

 

list-access-entries로 현재 cluster에 생성된 access entry 목록을 확인해 보겠습니다.

 

 

 

aws console에서도 확인하실 수 있는데, 현재는 그룹이나 access policy가 설정되어있지 않습니다.

 

AmazonEKSClusterAdminPolicy 연동

aws eks associate-access-policy --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster

 

testuser에 AmazonEKSClusterAdminPolicy 연동해 보겠습니다. (간단히 적용하는 실습이기 때문에 admin 권한을 부여하도록 하겠습니다.)

 

 

 

 

액세스 정책에 AmazonEKSClusterAdminPolicy이 할당된 것을 확인하실 수 있습니다.

 

testuser로 접근 확인

새로운 터미널을 열어서 다른 ec2(bastion)에 접근하여 testuser로 조회를 해보겠습니다.

 

kubectl get node -v6

 

 

kubectl rbac-tool whoami

 

rbac-tool에서 whoami를 해보겠습니다.

 

이제 EKS API 쪽에서 처리하다 보니 k8s의 RBAC 권한이 보이지 않습니다.

 

Cluster Accesss Management 사용 실습

기존 testuser access entry 제거

aws eks delete-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser

 

현재 testuser access entry에는 AmazonEKSClusterAdminPolicy  권한이 부여되어 있으니, 실습을 위해 삭제를 하겠습니다.

 

 

testuser가 pod 목록을 가져오는 명령어를 실행하려고 하면 권한이 없다는 에러가 발생하게 됩니다.

 

ClusterRole 생성

# pod viwer role
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-viewer-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list", "get", "watch"]

 

# pod admin role
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-admin-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["*"]

 

pod에 관해 목록 출력과 같은 단순히 출력만 할 수 있는 clusterRole과 모든 권한을 갖고 있는 admin 권한의 Cluster Role도 생성합니다.

 

Cluster Role Binding

kubectl create clusterrolebinding viewer-role-binding --clusterrole=pod-viewer-role --group=pod-viewer
kubectl create clusterrolebinding admin-role-binding --clusterrole=pod-admin-role --group=pod-admin

 

그 후 ClusterRoleBinding을 통해 pod-viewer와 pod-admin 그룹에 각각 binding 시켜줍니다.

 

ClusterAccessEntry 생성

aws eks create-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser --kubernetes-group pod-viewer | jq -r .accessEntry

 

그 후 먼저 testuser에 pod-viewer group을 연결시켜 줍니다.

 

 

pod 조회

kubectl get po

 

AmazonEKSClusterAdminPolicy을 삭제하고 조회를 했을 때는 조회가 안 됐었는데, 현재는 가능한 것을 확인하실 수 있습니다.

 

 

 

Pod 생성

kubectl run my-pod --image=nginx

 

간단히 nginx Pod를 생성해 보도록 하겠습니다.

 

 

하지만 현재 권한이 없어서 생성에 실패하는 것을 확인하실 수 있습니다.

 

ClusterAccessEntry 변경

aws eks update-access-entry --cluster-name $CLUSTER_NAME --principal-arn arn:aws:iam::$ACCOUNT_ID:user/testuser --kubernetes-group pod-admin | jq -r .accessEntry

 

이번엔 pod-admin group과 연결시킵니다.

 

 

Pod 조회

kubectl get po -A

 

모든 네임스페이스에 있는 pod를 조회해 보겠습니다.

 

정상적으로 조회가 되는 것을 확인하실 수 있습니다.

 

 

Pod 생성

 

 kubectl run my-pod --image=nginx

 

이번에도 Pod를 생성해 보도록 하겠습니다.

 

 

admin 권한이 있는 group과 연결되었기 때문에 생성이 된 것을 확인하실 수 있습니다.

 

---

참고

https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions

Associate access policies with access entries - Amazon EKS

 

https://aws.amazon.com/ko/blogs/tech/a-deep-dive-into-simplified-amazon-eks-access-management-controls/

간소화된 Amazon EKS 액세스 관리 제어 톺아보기 | Amazon Web Services