개요

EKS는 사용자가 IAM 사용자를 인증받아 대상 클러스터에 kubectl 명령어로 접근할 수 있도록 설정한다. 

하지만 이 IAM은 정책 기반으로 AWS 서비스에 대한 접근 제어만 가능할 것이다. kubernetes의 리소스를 제한하고 싶을 경우에는 어떻게 해야 할까?

Cluster 인증

EKS Cluster에 인증받는 순서가 아래 그림에 아주 자세하게 나와있다. 그림을 보고 테스트를 따라 해 본다면 쉽게 이해가 갈 것이다.

요약하자면 IAM과 kubernetes의 user 혹은 group을 aws-auth의 ConfigMap과 묶어 인증받는 순서이다. 같이 적용해 보도록 하자.


https://kubernetes.world/story/amazon-eks-access-control-of-kubectl-users-by-nagesh-subrahmanyam-nov-2020-medium/


AWS는 EKS 클러스터를 생성할 때의 IAM을 클러스터 master 계정으로 생성한다. master 계정 외에 다른 계정에서 클러스터에 접근하기 위해서는 aws-auth ConfigMap에 권한을 부여해야 한다. 

우선 master계정이 아닌 다른 IAM 계정으로 접근 시도해 보자.

User 생성 및 aws 액세스 키 적용

보통 개발자들 별로 IAM을 생성하여 액세스 키를 부여한다. 이렇게 함으로써 CloudTrail에서 이력 파악이 가능하다. 

aws configure 혹은 ~/.aws/credentials 에서 부여받은 액세스 키를 적용하자.

$ aws sts get-caller-identity
{
    "Account": "************", 
    "UserId": "AI******************K", 
    "Arn": "arn:aws:iam::************:user/sanghyeon.park_developer"
}

$ aws eks update-kubeconfig --region [region] --name [clustername]

Added new context arn:aws:eks:[region]:************:cluster/[clustername] to /home/ec2-user/.kube/config


kubectl 명령어를 실행할 때 aws 명령어로 eks의 토큰 값을 이용해 인증받고 실행하는 구조이다. 

이러한 내용은 위에 명령어로 생성된 .kube/config 파일에 명시되어 있다.

RBAC 적용 및 접근 권한 부여

위와 같이 설정한 뒤 cluster에 접근하려 했을 때 아래와 같은 결과가 나온다. 이는 클러스터를 읽을 수 있는 권한이 없다는 뜻이다.

$ kubectl get pods error: You must be logged in to the server (Unauthorized)


master 권한이 있는 계정으로 돌아가 Role을 생성해 보자.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: developer-role
  namespace: developer
rules:
  - apiGroups: ["*"]
    resources: ["pods"]
    verbs: ["list", "get", "create", "update"]


developer namespace의 pod 리소스에 대해 list, get, create, update에 대한 권한을 부여하는 role이다.

다른 권한을 부여하고 싶다면, kubectl describe clusterrole admin 명령어를 사용해서 골라서 쓰면 된다.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: developer-rolebinding
  namespace: developer
subjects:
  - kind: Group
    name: developer
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io


developer라는 Group에 Role을 묶어주는 RoleBinding을 생성한다.

IAM 사용자와 RBAC을 그룹에 매핑

aws-auth라는 ConfigMap에 위에서 생성한 Role이 적용되어 있는 그룹에 IAM user를 할당해 준다.

$ kubectl edit -n kube-system configmaps aws-auth
...생략
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::************:role/EKS-NodeGroup-Role
      username: system:node:{{EC2PrivateDNSName}}
  mapUsers: |
    - userarn: arn:aws:iam::************:user/sanghyeon.park_developer
      username: sanghyeon.park_developer
      groups:
        - developer
...생략


$ kubectl auth can-i list pods -n developer
yes
$ kubectl auth can-i delete pods -n developer
no

위의 명령어로 권한이 있는지 확인해 보자. 위에서 부여한 역할은 developer ns에서 list, create, update, get에 대한 권한만 부여했다. delete 권한은 없으므로 no라는 결과를 반환한다.

$ kubectl get pods -n developer

NAME                     READY   STATUS    RESTARTS   AGE
nginx-65764bd9b7-zq6td   1/1     Running   1          19m


RBAC과 IAM 정책을 잘 응용하여 설정한다면 AWS 서비스에 대한 보안과 Kubernetes 클러스터에 대한 보안 두 가지를 모두 잡을 수 있다. 

클러스터에 대한 보안적 요소는 RBAC 외에도 많이 있으므로 하나씩 다뤄 보도록 하겠다.