Control-plane의 API 서버에 API 요청을 하는 두 개체가 있습니다.
바로 'User(or Group)'와 'Pod'인데요, (모든 Pod는 'ServiceAccount' 계정을 기반으로 동작)

API 서버에 아무나 아무 요청을 하도록 하면 안 되기 때문에 API 요청을 승인하기 위해서는 Role 기반의 인증 작업을 거칩니다. 그 인증 작업을 'API 인증' = 'Role 기반의 액세스 제어' = 'Role-based access control' = 'RBAC'이라고 합니다.

Role & RoleBinding

Role

어떤 API를 이용할 수 있는지의 권한을 정의한 것으로, 지정된 네임스페이스에서만 유효합니다.

예시) default 네임스페이스의 Pod에 대해 get, watch, list 할 수 있는 권한이 있는 pod-reader라는 Role을 생성

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

• apiGroups: Pod는 코어 API이기 때문에 apiGroups를 따로 지정하지 않음 ([""] = '코어 API 그룹'을 의미)
• resources: "pods", "deployments", "services" 등 사용할 API 리소스들을 명시함
• verbs: "create", "get", "update", "delete" 등 허용할 기능을 명시함

$ kubectl create role pod-reader --verb=get,watch,list --resource=pods --namespace=default

RoleBinding

'User/Group 또는 ServiceAccount'와 'Role'을 연결하며(User/Group ↔ Role, ServiceAccount ↔ Role) 특정 User/Group이나 ServiceAccount에 RoleBinding 함으로써 User/Group과 ServiceAccount의 API 접근을 제어합니다.

☞ 권한이 있는 User/Group이나 ServiceAccount의 접근만을 허용함

예시) default 네임스페이스에서 User jane에게 pod-reader Role을 할당

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef: 
  kind: Role  # this must be Role or ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

• subjects: User 'jane'에게 앞서 정의한 'pod-reader'라는 Role을 할당
• roleRef: 앞서 정의한 Role을 명세 (apiGroup: rbac api를 사용하기 때문에 rbac.authorization.k8s.io로 설정)

$ kubectl create rolebinding read-pods --user=jane --role=pod-reader --namespace=default

ClusterRole & ClusterRoleBinding

'RoleBinding' vs 'ClusterRoleBinding'

'RoleBinding'은 지정된 네임스페이스에서만 유효하지만, 'ClusterRoleBinding'은 클러스터 내 모든 네임스페이스에서 유효하다는 차이가 있습니다.

ClusterRole

어떤 API를 이용할 수 있는지의 권한을 정의한 것으로, 클러스터 전체 네임스페이스에서 유효합니다.

예시) 전체 네임스페이스의 Secret에 대한 get, watch, list 할 수 있는 권한을 가진 ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

ClusterRoleBinding

'User/Group 또는 ServiceAccount'와 'ClusterRole'을 연결합니다.

예시) manager Group의 모든 User가 모든 네임스페이스의 secret을 읽을 수 있도록 구성

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

---

Reference

• [패스트캠퍼스] Kubernetes 자격증 마스터 클래스 : CKA/CKAD/CKS
• https://kubernetes.io/docs/reference/access-authn-authz/rbac

개인적으로 공부하며 작성한 글로, 내용에 오류가 있을 수 있습니다.