RBAC Role/ClusterRole

Role과 ClusterRole

verbs

• 리소스가 아닌 것에 대한 요청

  /api/v1/...과 /apis/<group>/<version>/...와 같은 엔드 포인트에 대한 요청은 요청 대상이 리소스가 아니다. 이런 경우, HTTP 요청에 사용된 메소드의 소문자 버전을 verb로 사용한다. 예를 들어, /api나 /healthz 엔드 포인트에 대한 GET HTTP 요청을 허용하기 위해서는 verb에 get을 지정하면 된다.

• 리소스를 대상으로 하는 요청

  HTTP verb	request verb
  POST	create
  GET,HEAD	get(개별), list(전체), watch(개별+전체)
  PUT	update
  PATCH	patch
  DELETE	delete(개별), deletecollection(전체)

Role

Role을 사용하면 네임스페이스에 속한 자원에 대해서 권한을 정의할 수 있다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  
  # Role이 정의될 네임스페이스를 지정한다.
  # Role과 이를 사용할 RoleBinding은 같은 네임스페이스에 위치해야 한다.
  namespace: default
rules:
- apiGroups: [""]  # "" = core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

간혹 아래와 같이 Pod의 log를 조회해야 하는 상황이 있다. 이를 위해서는 Pod의 하위 자원(subresource)인 log에 대한 권한을 보유하고 있어야 한다. RBAC에서는 /를 사용하여 하위 자원에 대한 접근 권한을 지정할 수 있다.

GET /api/v1/namespaces/{namespace}/pods/{name}/log

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-and-pod-logs-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]  # "pods/log"을 통해 pods의 하위 자원인 log를 지정할 수 있다.
  verbs: ["get", "list"]

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]  # "my-configmap" ConfigMap에만 접근할 수 있다.
  verbs: ["get", "update"]

ClusterRole

네임스페이스 영역에 속한 자원에 대한 권한을 정의하는 Role과는 달리, ClusterRole은 클러스터 범위의 자원이나 /healthz와 같은 비자원 엔드 포인트에 접근할 수 있는 권한도 정의할 수 있다.

apiVersion: rbac.authorziation.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding과 ClusterRoleBinding

RoleBinding이나 ClusterRoleBinding을 사용하면 앞서 정의한 Role 혹은 ClusterRole을 특정 유저/서비스 어카운트/그룹에 적용할 수 있다.

RoleBinding

RoleBinding은 ClusterRole 혹은 같은 네임스페이스에서 정의된 Role을 특정 유저나 서비스 어카운트, 혹은 그룹에 적용할 수 있다. 앞서 알아본 ClusterRole은 정의한 권한이 클러스터 범위까지 적용된다고 했지만, RoleBinding과 함께 사용하면 RoleBinding이 속한 네임스페이스로 그 범위가 제한된다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: some-rolebinding
  # Role은 Role이 정의된 네임스페이스에 대해서만 권한을 부여할 수 있다.
  # 예를 들어, 여기서 정의하는 Role이 부여하는 권한은 development 네임스페이스에 속한 오브젝트들에만 적용된다.
  namespace: development

roleRef:
  # RoleBinding은 Role과 ClusterRole을 특정 대상에게 부여한다.
  # ClusterRole에서 정의한 권한은 클러스터 범위까지도 유효하지만,
  # RoleBinding과 함께 사용하면 RoleBinding이 속한 네임스페이스로 그 범위가 제한된다.
  # 예를 들어, 아래와 같이 설정하면 development 네임스페이스에 속한 Secret 오브젝트에만 권한이 부여된다.
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io
  
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io

- kind: ServiceAccount
  name: dave-sa
  namespace: dave-sa-ns
  
# 특정 네임스페이스에 속한 모든 서비스 어카운트들에 대한 RoleBinding을 정의하고 싶다면
# "system:serviceaccounts:NAMESPACE_NAME" 그룹을 대상으로 RoleBinding을 정의하면 된다.
# 예를 들어, 아래에서는 qa 네임스페이스에 속한 모든 서비스 어카운트에 대한 RoleBinding을 정의한다.
- kind: Group
  name: system:serviceaccounts:qa  # qa 네임스페이스에 속한 모든 서비스 어카운트
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:serviceaccounts  # 모든 서비스 어카운트
  apiGroup: rbac.authorization.k8s.io

- kind: Group
  name: system:authenticated  # 인증된 모든 사용자
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated  # 인증되지 않은 모든 사용자

ClusterRoleBinding

ClusterRoleBinding은 ClusterRole을 특정 대상에게 부여할 수 있다. 클러스터 범위의 권한을 부여한다는 차이점 외에는 앞서 알아본 RoleBinding과 큰 차이는 없다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: some-clusterrolebinding
  
roleRef:
- kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io
  
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io

References

Authorization Overview, kubernetes.io
Using RBAC Authorization, kubernetes.io