[EKS] ⑤ 쿠버네티스 RBAC(Role, RoleBinding) - AWS IAM 역할에 권한 부여

이아영·2021년 4월 23일
3

EKS

목록 보기
5/7

Cluster가 생성되면 Cluster를 생성한 IAM 사용자 또는 역할의 ARN만 aws-auth ConfigMap에 추가된다. 또한 이 ARN에만 system:masters 권한이 포함된다. 즉, Cluster 생성자만 다른 사용자 및 역할을 aws-auth ConfigMap에 추가할 수 있다.(참고)

이번 글에서는 IAM 역할을 생성해서 Bastion 서버(EC2)에 붙여준 후, IAM 역할쿠버네티스 RBAC를 사용하여 Pod에 대한 읽기 권한을 부여해본다.

RBAC (Roll Based Access Control)

조직 내 개별 사용자의 역할을 기반으로 컴퓨터 또는 네트워크 리소스에 대한 액세스를 규제하는 방법

쿠버네티스 문서 - https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Bastion에 대한 EKS IAM 역할을 생성하고 RoleRoleBinding을 통해 해당 역할에 Pod에 대해 get, watch, list할 수 있는 권한을 부여해 보겠다.


Bastion에 대한 IAM 역할 생성

IAM 콘솔에서 Bastion EC2에 연결할 역할을 만들어 준다.

AWS 서비스EC2를 선택해주고 검토 단계까지 다음을 누르고 이름을 정해준 후 역할을 생성한다.

EC2 콘솔로 이동하여 만든 IAM 역할을 Bastion 서버(EC2)에 연결해준다.


Configmap에 IAM 역할 추가

kubectl edit -n kube-system configmap/aws-auth 명령어를 실행시켜 Configmap을 수정해준다.

처음 kubectl edit -n kube-system configmap/aws-auth 명령어를 실행시키면 다음과 같이 작성 되어져 있을 것이다.

# 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::90018*******:role/L23724-eks-node-role-tokyo
      username: system:node:{{EC2PrivateDNSName}}
kind: ConfigMap
metadata:
  creationTimestamp: "2021-04-22T03:43:04Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:mapRoles: {}
    manager: vpcLambda
    operation: Update
    time: "2021-04-22T04:35:30Z"
  name: aws-auth
  namespace: kube-system
  resourceVersion: "182506"
  selfLink: /api/v1/namespaces/kube-system/configmaps/aws-auth
  uid: 38358930-4ed3-48e1-b9da-bf5344f5bbba

mapRoles 부분에 Bastion에 붙여준 IAM 역할을 다음과 같이 추가하고 저장해준다.

apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::90018*******:role/L23724-bastion-eks-role
      username: L23724-bastion-eks-role

저장하고 나오면 configmap/aws-auth edited 이라는 메시지가 출력된다.


IAM 역할에 RBAC를 통해 권한 부여

Role

Role은 권한을 나타내는 규칙이 포함된다.

다음은 default네임스페이스의 Pod에 대한 읽기 액세스 권한을 부여할 수 있는 템플릿이다.

pod-read-role.yml

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

아래 kubectl apply 명령어를 통해 pod-reader라는 Role을 생성한다.

[aylee@ip-24-0-0-228 ~]$ kubectl apply -f pod-read-role.yml
role.rbac.authorization.k8s.io/pod-reader created

RoleBinding

RoleBindingRole에 정의 된 권한을 사용자 또는 사용자 집합에 부여한다.

다음은 방금 만든 IAM 역할(L23724-bastion-eks-role)에 Role(권한)을 부여할 수 있는 템플릿이다.

role-binding.yml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
  name: L23724-bastion-eks-role
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

아래 명령어를 통해 적용시켜준다.

[aylee@ip-24-0-0-228 ~]$ kubectl apply -f role-binding.yml
rolebinding.rbac.authorization.k8s.io/read-pods created

RoleBinding이 완료되었다. 이제 Bastion 서버(EC2)에 연결되어있는 IAM 역할권한(pod-reader 역할)이 부여되었다.

RBAC에 대한 자세한 내용은 아래 쿠버네티스 문서를 통해 확인
https://kubernetes.io/docs/reference/access-authn-authz/rbac/


권한 확인

aws sts get-caller-identity 명령어를 사용하면 designated_user에 대한 IAM 사용자 세부 정보가 표시 된다.

현재는 Bastion 서버 내에 aws configure로 세팅한 사용자(Cluster 생성자)가 나온다.

[aylee@ip-24-0-0-228 ~]$ aws sts get-caller-identity
{
    "Account": "90018*******",
    "UserId": "AIDA5DFZMAR**********",
    "Arn": "arn:aws:iam::90018*******:user/L23724"
}

다음 명령을 통해 aws configure에 대한 설정을 모두 삭제해 준다.

rm -rf ~/.aws

다시 aws sts-get-caller-identity 명령어를 실행해주면 UserIDARN이 EC2에 붙어있는 IAM 역할로 바껴있는 것을 볼 수 있다.

[aylee@ip-24-0-0-228 ~]$ aws sts get-caller-identity
{
    "Account": "90018*******",
    "UserId": "AROA5DFZMAR**********:i-0ef01f0daec2132a5",
    "Arn": "arn:aws:sts::90018*******:assumed-role/L23724-bastion-eks-role/i-0ef01f0daec2132a5"
}

권한 부여가 잘 되었는지 보기 위해 kubectl 명령어를 실행해보면

[aylee@ip-24-0-0-228 ~]$ kubectl get svc
Error from server (Forbidden): services is forbidden: User "L23724-bastion-eks-role" cannot list resource "services" in API group "" in the namespace "default"
[aylee@ip-24-0-0-228 ~]$ kubectl get po
No resources found in default namespace.

권한을 주지 않은 Service에 대한 리스트는 볼 수 없고 Pod에 대한 리스트는 볼 수 있다.
(현재는 따로 Pod를 띄워 놓지 않았기 때문에 리소스가 없다고 나옴)

1개의 댓글

comment-user-thumbnail
2023년 10월 31일

configmap 에 롤 추가 하고 role과 rolebinding 만 했다고 해서 aws sts-get-caller-identity 하면 designated_user 세부정보가 바뀌는게 이해가 안되네요...앞서 설정은 설정이지만 그게 designated_user의 aws sts까지 바꾼다는게..........그러면 configmap에 여러 롤을 추가하면 그리고 여러 role과 rolebinding을 추가하면 어떤 user의 aws sts와 연동이 되는지 좀 헷갈리네요

즉 cm이 여러그룹을 설정햇다면 .aws/ config 삭제후 aws sts get-caller-identity 하면 그중에 뭘로 셋팅되는지 어떤기준으로되나요?

답글 달기