서론
작년 말에 우연히 Goodbye aws-auth ! 라는 문구가 들어간 블로그를 본 적이 있습니다.
그 땐, 정확히 테스트까지 하고 넘어가지 않았지만, 더이상 aws-auth configmap을 사용하지 않아도 AWS Principle (IAM Group, User, Role 등)이 EKS Cluster에 접근 할 수 있다는 내용이었습니다.
EKS를 사용하면서 처음 만났던 장벽이 aws-auth configmap이었기 때문에, 기존 방식과 새로운 방식에 대해서 정확히 이해하고 가면 좋겠다고 생각해서 정리해봤습니다.
K8S Cluster에 사용자가 접근하려면?
RBAC을 위해서 적절한 Role, ClusterRole, ServiceAccount 를 사용해야합니다.
기본적으로 K8S Cluster에 접근하기 위해서는 접속사의 ~/.kube/config 파일에 , cluster, user, client-certificate-data, client-key-data 등의 정보를 기입하여 인증(AuthN)해야합니다.
이 문서에서 Kubernetes의 인증/인가 방식에 대한 방법을 자세하게 보실 수 있습니다.
EKS Control Plane API 호출 방법
2023년 12월 18일 AWS는 클러스터 액세스 관리를 위한 간소화된 컨트롤 기능을 출시했습니다.
이에 따라서, 기존 ConfigMap으로만 구성되던 Cluster 인증 방식이 다음과 같이 세가지로 분류되었습니다.
•
EKS API
•
ConfigMap
•
EKS API and ConfigMap
![[스크린샷 2024-03-20 오후 6.03.55.png]]
추가 정보
인증 모드 간 전환은 단방향 작업입니다. 즉, 다음 두 가지 변경만 가능합니다.
•
CONFIG_MAP -> EKS API_AND_CONFIG_MAP
•
EKS API_AND_CONFIG_MAP -> EKS API
인증 모드 별 차이
Configmap
kube-system namespace에 위치한 aws-auth configmap에 정의된 설정에 따라 AWS Principle에게 EKS Cluster에 대한 RBAC을 제공합니다.
apiVersion: v1
data:
mapAccounts: |
- "590184102060"
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::590184102060:role/eks-nodegroup-default
username: system:node:{{EC2PrivateDNSName}}
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::590184102060:user/jwjung
username: jwjung
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
creationTimestamp: -
resourceVersion: -
uid: -
Plain Text
복사
EKS API
새로 출시된 EKS API 방식은 크게 두 가지 논리적 리소스를 통해 AWS Principle에게 RBAC을 제공합니다.
•
Access Entry
•
Access Policy
Access Entry는 EKS에 접근할 AWS Principle에 대한 정의입니다.
아래 사진과 같이 Access Entry는 K8S Group, Access Policy, AWS Principal 3가지 리소스에 대한 정보를 가지게 됩니다.
•
AmazonEKSClusterAdminPolicy – cluster-admin
•
AmazonEKSAdminPolicy – admin (Namespace 단위)
•
AmazonEKSEditPolicy – edit (Namespace 단위)
•
AmazonEKSViewPolicy – view (Namespace 단위)
EKS Cluster 인증 모드를 API_AND_CONFIG_MAP으로 설정하면 두 가지 방식 모두에서 권한을 계산합니다.
만약 AWS Principle (보안 주체)이 access entry 와 aws-auth configmap 모두 참조되는 경우, EKS는 access entry에 정의된 권한만 principle에게 부여합니다.
추가 정보
지금까지는 Amazon EKS 클러스터를 프로비저닝하는 데 사용된 IAM Principle이 (이하 클러스터 생성자) 영구적으로 Kubernetes 클러스터 Admin 권한을 부여받았습니다.
EKS API 방식이 추가되면서 Access Entry를 통해서, 클러스터 생성자에 대한 권한 제어가 가능해졌습니다.
이를 통해 다음과 같은 이점이 생겼습니다.
•
EKS를 프로비저닝하는데 사용되는 IAM Principle 지정 실수로부터 자유로워짐
•
EKS를 프로비전이하는 IAM Principle의 관리자 권한이 필수가 아니게 됨으로써 보안적으로 유리함
(기존 Configmap 방식은 클러스터 생성자에 대한 admin 권한이 암시적으로 부여되었기 때문에, 권한 변경/삭제가 불가능했습니다.)
•
AWS Principle에 대한 권한 부여를 K8S 내부 리소스가 아닌 AWS API를 통해 관리하기 때문에, 관리에 용이함 (특히 IaC로 관리가 더욱 용이함)
아래 그림은 EKS API요청에 대한 처리 과정을 자세하게 보여줍니다.
직접 해보기
시나리오
1.
aws-auth configmap 설정으로 EKS Cluster 접근해보기
2.
EKS API 방식을 사용해서 EKS Cluster 접근해보기
데모
1.
테스트에 사용할 ClusterRole 사전 생성합니다.
아래와 같이 yaml 파일을 만든 후 EKS Cluster에 배포하여 ClusterRole와 Binding된 Group (pod-and-config-viewers) 를 생성습니다..
# test_clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-and-config-viewer
rules:
- apiGroups: ['']
resources: ['pods', 'pods/log', 'configmaps']
verbs: ['list', 'get', 'watch']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: pod-and-config-viewer
subjects:
- kind: Group
name: pod-and-config-viewers
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: pod-and-config-viewer
apiGroup: rbac.authorization.k8s.io
Plain Text
복사
2.
Access Entry에 자격 증명을 등록합니다.
등록과 함께 Kubernetes 내부의 Group을 해당 Access Entry에 연동할 수 있습니다.
# Entry 생성
aws eks create-access-entry \\
--cluster-name cloudest \\
--principal-arn arn:aws:iam::000000000000:role/default-instance-profile \\
[--kubernetes-group K8S_GROUP_NAME]
# Entry 업데이트
aws eks update-access-entry \\
--cluster-name cloudest \\
--principal-arn "arn:aws:iam::000000000000:role/default-instance-profile" \\
--kubernetes-groups=pod-and-config-viewers
Plain Text
복사
3.
현재 Access Entry를 조회하여, 등록된 자격증명을 확인할 수 있습니다.
# 특정 Cluster의 전체 Access Entry 조회
aws eks list-access-entries \\
--cluster-name cloudest
# 특정 Access Entry 세부정보 조회
aws eks describe-access-entry \\
--cluster-name cloudest \\
--principal-arn "arn:aws:iam::000000000000:role/default-instance-profile"
Plain Text
복사
4.
Access Entry에 등록된 AWS Principle과 AWS에서 사전 정의된 Access Policy와 연결합니다.
$ aws eks associate-access-policy \\
--cluster-name cloudest \\
--principal-arn arn:aws:iam::000000000000:role/default-instance-profile \\
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy \\
--access-scope '{"type": "cluster"}'
# 연결 해제 명령어
aws eks disassociate-access-policy \\
--cluster-name cloudest \\
--principal-arn "arn:aws:iam::000000000000:role/default-instance-profile" \\
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy
# 생성 후 확인 명령어
$ aws eks describe-access-entry \\
--cluster-name cloudest \\
--principal-arn "arn:aws:iam::000000000000:role/default-instance-profile"
# AWS의 ReadOnly 라는 이름의 Role에 test* namespace에 대한 읽기 전용
$ aws eks associate-access-policy \\
--cluster-name <CLUSTER_NAME> \\
--principal-arn arn:aws:iam::<AWS_ACCOUNT_ID>:role/ReadOnly \\
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \\
--access-scope type=namespace,namespaces=test*
Plain Text
복사
주의사항
•
Amazon EKS는 클러스터에 있는 Kubernetes RBAC 객체에 지정한 그룹 이름이 포함되었는지 확인하지 않습니다.
•
EKS cluster authentication mode는 Cluster 생성 후 수정 가능하지만, EKS API 쪽으로의 단방향 업그레이드입니다.
•
Access Entry, Configmap 설정이 양쪽에 존재하는 경우, Access Entry의 설정이 우선 적용됩니다.
(두 인증 방식 모두 사용하는 설정인 경우에만 유효)
결론
•
처음 Access Entry를 완전히 이해하기 전까지만 해도 4개의 사전 정의된 IAM Managed Policy만 사용가능한 것인 줄 알았다. 그래서 복잡한 권한 관리를 위해서는 여전히 aws-auth configmap을 사용해야 하는 줄 알았다.
그런데 K8S Group을 바인딩 할 수 있는 것을 이해하고나니, API 방식의 RBAC이 완벽한 상위호환인 것을 알 수 있었다.