K8S role 파헤치기

쿠버네티스를 공부하다 보니 role, rolebinding, serviceaccount에 대한 개념이 혼동되는 부분이 있어서 정리해 보았다.

참고 문서

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

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

Role & ClusterRole

RBAC(Role-based access control)에서 Role과 ClusterRole은 permission의 set을 의미한다.

Role과 ClusterRole의 차이는 namespace에 종속되어 있는지이다. Role의 경우 특정 namespace에 대해서만 가능하고, ClusterRole은 non-namespaced 자원이다.

ClusterRole의 경우

1. cluster scope resource에 permission 정의
2. namespaced resource에 permission 정의하고 각각의 namespace에 access 부여
3. namespaced resource에 permission 정의하고 모든 namespace에 access 부여

다음과 같이 role을 부여할 수 있다.

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"]

default namespace의 pod에 대해 get, watch, list하는 권한을 정의한다.

RoleBinding & ClusterRoleBinding

role은 user에게 bind되어야 비로소 동작할 수 있다.

role과 user를 연결해주는 것이 role binding이다.

role binding의 경우 동일한 namespace의 role을 reference할 수 있고, cluster role 역시 reference할 수 있다. Cluster Role을 모든 namespace에 적용하고 싶다면, Cluster Role Binding을 사용하자.

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
  name: jane # "name" is case sensitive
  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

subjects 필드에는 실제로 권한을 부여받는 주체를 나열하고, roleRef는 적용할 rule을 나열한다.

ServiceAccount

ServiceAccount는 k8s 내에 존재하는 계정이다. 일반적인 User나 group과는 다르게, Kubernetes resource로서 k8s API 의 지원을 받는다.

각 namespace에는 자동으로 default service account가 생성된다.

service account를 만들면 jwt token이 생성되어 secret 오브젝트에 저장된다.

Examples & Tips

실제 사용 사례와 알아두면 좋은 tip을 나열한다.

Role

rules:
- apiGroups: ["apps"]
  #
  # at the HTTP level, the name of the resource for accessing Deployment
  # objects is "deployments"
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

default apiGroups인 pod와 다르게, deployments의 경우 apps라는 apiGroups에 속해 있으므로 apiGroups를 명시해야 한다.

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match
  verbs: ["get", "post"]

non-resource인 endpoint의 경우 위와 같이 권한을 부여한다.

RoleBinding

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

default ServiceAccount에 권한 부여한다.

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

qa namespace에 있는 모든 service account에 권한 부여한다.