[AWS/EKS] AWS IAM 사용자에 대한 RBAC (Role-based Access Control) 설정하기

AWS에서 각 IAM 사용자, 역할마다 권한을 달리하듯, 쿠버네티스에는 리소스에 대한 작업을 제어하는 RBAC (Role-based Access Control)를 제공한다.

최초 EKS 클러스터가 생성되면 클러스터 생성을 수행한 IAM 계정에만 master 권한을 부여하여 EKS Cluster 사용이 가능하도록 한다. 이 외의 IAM 사용자 또는 역할은 EKS Cluster 접근, api 호출이 불가능하다 (해당 IAM에 권한을 부여해도 불가능함).

이를 해결하기 위해서는 적절한 권한이 부여된 IAM을 생성하고, 쿠버네티스의 RBAC와의 연결이 필요하다.

 

본 포스팅의 순서는 다음과 같으며, AWS IAM 사용자/역할은 이미 존재하는것으로 가정한다 (본 포스팅에서는 IAM 사용자를 기준으로 테스트한다).

 

[목표: dev 계정에 pod 읽기 권한 부여]

1. IAM 정책 생성 및 적용

2. Role 생성

3. RoleBinding 생성

4. ConfigMap 수정

 

쿠버네티스에서는 다음과 같은 역할과 역할 바인딩 객체를 제공한다.

• 역할
  - 권한 설정 (예. pod에 대해 list, get 만 지원한다)
  - 종류: Role (네임스페이스 내의 쿠버네티스 리소스에대한 허용 규칙), ClusterRole (클러스터 내 모든 리소스에대한 허용 규칙)
• 역할 바인딩
  - 역할과 쿠버네티스 사용자, 혹은 그룹과 binding 수행 (예. 쿠버네티스 developer 그룹에 생성한 역할의 권한 부여)
  - 종류: RoleBinding (Role, ClusterRole 과 바인딩 가능), ClusterRoleBinding (ClusterRole과 바인딩 가능)

본 포스팅에서는 하나의 네임스페이스에 대한 pod만 접근 가능하도록 구성해본다.

 

1. IAM 정책 생성 및 적용

본 포스팅 IAM 사용자가 EKS에 생성된 pod 리소스 조회를 할수 있도록 하는 것이므로 EKS에 대한 IAM 정책 생성이 필요하다.

 

AWS IAM > 정책 생성 > 정책 입력

정책은 요구되는 작업에 따라 달라질 수 있다. 본 포스팅에서는 aws eks update-kubeconfig를 위한 아래의 권한만을 부여하였다. (AWS 도큐먼트에서는 좀더 다양한 관점에서의 IAM 정책 예를 제공한다. https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/security_iam_id-based-policy-examples.html)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "eks:DescribeNodegroup",
                "eks:ListNodegroups",
                "eks:DescribeCluster",
                "eks:ListClusters",
                "eks:AccessKubernetesApi",
                "ssm:GetParameter",
                "eks:ListUpdates",
                "eks:ListFargateProfiles"
            ],
            "Resource": "*"
        }
    ]
}

 

2. 역할 생성

role과 roleBinding 생성은 master 계정 (예. EKS 클러스터를 생성한 계정)에서 수행해야 정상 생성된다.

본 포스팅에서는 nginx 네임스페이스에 존재하는 pod를 조회하는 role을 작성하였다. rules에는 여러 규칙 작성이 가능하며, rules[].verbs는 resources에 명시된 리스트에 대해 허용할 요청 목록을 입력한다.

# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: nginx
  name: nginx-pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "list"]

 

yaml 파일을 적용한다.

$ kubectl apply -f role.yaml
role.rbac.authorization.k8s.io/nginx-pod-reader created

 

3. 역할 바인딩 생성

RoleBinding은 역할과 역할이 부여될 대상을 묶어주는 역할을 한다. 본 포스팅에서는 developer 그룹 (이 이름은 configmap 설정시 사용됨)이 nginx-pod-reader Role (nginx 네임스페이스의 pod에 대해 list, get 권한 부여)의 동작을 사용하게 한다.

# roleBinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: nginx
# role이 적용될 대상
subjects:
- kind: Group
  name: developer
  apiGroup: rbac.authorization.k8s.io
# subjects에 나열된 대상에 적용될 role 
roleRef:
  kind: Role
  name: nginx-pod-reader # 연결할 Role 혹은 ClusterRole의 이름과 일치해야 함
  apiGroup: rbac.authorization.k8s.io

 

yaml 파일을 적용한다.

# RoleBinding 생성
$ kubectl apply -f roleBinding.yaml
rolebinding.rbac.authorization.k8s.io/read-pods created

# RoleBinding 생성 확인
kubectl get rolebindings -n nginx | grep read-pods
read-pods   Role/nginx-pod-reader   79s

 

4. ConfigMap 수정

EKS는 관리형 노드 그룹을 사용하거나 eksctl로 노드 그룹을 생성하였을 때 aws-auth라는 ConfigMap을 제공한다. 처음에 configmap/aws-auth는 노드를 클러스터에 조인하기 위해 구성되었으나, 최근에는 본 포스팅과 같이 IAM 사용자, 역할에 대한 RBAC 설정을 지원한다.

본 포스팅에서는 관리형 노드 그룹을 생성하여 aws-auth가 이미 생성되었다는 가정하에 진행한다.

 

configmap/aws-auth가 존재하는지 확인하는 명령어는 다음과같다.

$ kubectl get cm -n kube-system | grep aws-auth
aws-auth                                  1      40d

 

configmap을 편집하기위해 다음 명령어를 사용한다.

$ kubectl edit -n kube-system configmap/aws-auth

 

본 포스팅에서는 IAM 사용자에 대한 설정이므로 mapUsers에 추가한다 (IAM 역할의 경우 mapRoles에 해당 역할을 추가한다).

각 항목에 대한 설명은 다음과같다.

• userarn (or rolearn): IAM 사용자 혹은 IAM 역할의 ARN
• username: IAM 사용자와 연결할 쿠버네티스 내 사용자 이름 (IAM user와 동일한 것이 관리에 용이할 것 같다)
• groups: 쿠버네티스 내 사용자가 포함된 그룹 이름

 항목에 맞는 값을 입력 후 저장하고 편집 창을 나온다(ESC + :wq).

     ...
     
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: [NODEGROUP에 적용된 IAM 역할 ARN]
      username: system:node:{{EC2PrivateDNSName}}
  mapUsers: |
    - userarn: arn:aws:iam::<ACCOUNT>:user/user-dev01
      username: dev01
      groups:
      - developer
      
     ...

 

사용중이던 계정에서 user-dev01 계정으로 전환한다. (aws configure, AWS_PROFILE 등을 사용)

user-dev01로 잘 변경되었는지 확인한다.

$ aws sts get-caller-identity
{
    "Account": "<ACCOUNT>",
    "UserId": "AIDA5DFZMARIWRLEJ4USX",
    "Arn": "arn:aws:iam::<ACCOUNT>:user/user-dev01"
}

 

update-kubeconfig 수행 (kubeconfig를 수정하지 않으면 master에서 사용중이던 kubeconfig 내용을 그대로 사용하게되어 테스트가어렵다)

$ aws eks update-kubeconfig --region ap-northeast-2 --name [EKS-CLUSTER-NAME]
Updated context arn:aws:eks:ap-northeast-2:[ACCOUNT]:cluster/[EKS-CLUSTER-NAME] in /home/ec2-user/.kube/config

 

마지막으로 변경된 사용자에 대한 역할이 잘 적용되었는지 확인한다.

# nginx namespace의 pod 조회 -> 가능
$ kubectl get pod -n nginx
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-66b6c48dd5-5lqbk   1/1     Running   0          129m
nginx-deployment-66b6c48dd5-m2vbz   1/1     Running   0          129m

# default namespace의 pod 조회 -> 다른 namespace이므로 불가능
$ kubectl get pod
Error from server (Forbidden): pods is forbidden: User "dev01" cannot list resource "pods" in API group "" in the namespace "default"

# nginx namespace의 deployment 조회 -> namespace는 조건에 일치하나, deployment에대한 권한이 없어 불가능 
$ kubectl get deploy -n nginx
Error from server (Forbidden): deployments.apps is forbidden: User "dev01" cannot list resource "deployments" in API group "apps" in the namespace "nginx"

 

이와같이 본 포스팅에서는 RoleBinding을 설정하고 IAM 사용자에게 해당 역할을 부여하는 방법을 다루었다. 

 

 

[참고]

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/add-user-role.html#aws-auth-configmap

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/security_iam_id-based-policy-examples.html

https://kubernetes.io/docs/reference/access-authn-authz/rbac/