Google Kubernetes Engine: RBAC

RBAC 는 쿠버네티스 클러스터 내부에서 오브젝트를 조작하기 위한 권한을 주기 위해서 사용한다.

 

RBAC 에 대해 본격적으로 배우기 전에 Cloud IAM 과 RBAC 가 어떤 관계가 있는지 이해하는게 중요하다.

 

GKE 에서 사용할 때 이 둘은 같이 사용하며, 서로가 하는 역할이 다르다:

• Cloud IAM:
  • Google Cloud Platform (GCP) 의 리소스들 (e.g Cloud SQL, Cloud Storage, GKE 등) 에 접근하기 위한 권한을 담당한다.
  • GKE 내부 클러스터의 오브젝트에 대한 접근 권한은 담당하지 않는다.
• RBAC:
  • 쿠버네티스 클러스터 내부에서 오브젝트 (e.g Pod, Service, Deployment 등) 을 조작하기 위한 권한을 주기 위해서 사용한다.

 

Kubernetes RBAC 를 구성하는 세 가지 주요 요소는 다음과 같다:

• 주체(subjects):
  • 누가 권한을 가지고 있는가? (Who)
  • subject 는 User, Group, ServiceAccount 로 나눌 수 있다:
    • User: 사용자나 시스템
    • Group: 여러 사용자를 묶은 것 
    • ServiceAccount: Pod 또는 어플리케이션이 쿠버네티스와 상호작용하기 위해 사용하는 계정 
• 자원(resources):
  • 어떤 리소스에 대한 권한을 가지고 있는가? (Which)
• 동사(verbs):
  • 리소스에 어떠한 작업 (e.g get, watch, create, describe) 을 할 수 있는가? (What)

 

Kubernetes RBAC 는 어떻게 사용자에게 권한을 주는가?

• Role 을 통해서 리소스에 대한 제어 권한을 만들고, 이 'Role' 을 사용자에게 Binding 하기 위해 'RoleBinding' 을 만들어서 권한을 줄 수 있다.

이를 Kubernetes RBAC 구성요소로 설명하자면 Role 은 Resource 와 Verb 를 가진 것이고, RoleBinding 은 Role 을 사용자에게 연결시켜주면서 subject 를 가지게 만드는 것이다.

 

Role 과 RoleBindings 는 Cluster Level 이나 Namespace Level 에서 사용할 수 있다.

• ClusterRole 은 클러스터 수준의 리소스 (e.g Node 나 PersistentVolume) 에 권한을 줄 때 유용하게 사용할 수 있다.
• 물론 namespace level 의 리소스도 권한을 줄 수 있으며, 이렇게주면 모든 네임스페이스에서 해당 리소스를 사용할 수 있다. 

 

'Deny' 와 관련된 Role 은 없다. 그냥 해당 Role 이 없다면 기본적으로 제어를 할 수 없다라고 생각하면 된다.

 

`kubectl api-resources`  명령을 통해서 정확한 reousrce 이름과 apiGroup 을 볼 수 있는데 이를 이용하면 RBAC 정책을 설정하는데 도움을 줄 수 있다. 

RBAC 예시:

예시: namespace level 의 Role

먼저 namespace level 의 Role 을 만드는 예시를 살펴보자:

• 이 Role 은 my-namespace 에서 생성되며, 이 namespace 에서만 Role 이 적용된다.
• Pod 리소스에 대해 get, watch, list (즉, 읽기 작업)를 수행할 수 있는 권한을 부여했다.
• apiGroups 은 쿠버네티스 API 그룹을 지정하는데, 빈 값으로 주면 기본적인 기능을 사용할 수 있다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

 

RoleBinding 을 다음과 같이 yaml 로 만들고 이를 각각 kubectl apply -f <파일명>.yaml 로 명령하면 Role 이 바인딩되서 사용자 Jane 은 해당 권한을 사용할 수 있다:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: my-namespace
subjects:
- kind: User
  name: "jane"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

 

예시: Cluster Level 의 Role

ClusterRole은 클러스터 수준에서 권한을 부여하며, 네임스페이스를 지정할 필요가 없다. 

 

kind: ClusterRole 을 통해서 클러스터 수준의 Role 을 만들 수 있다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader-global
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

 

다음은 이 Role 과 Binding 하기 위한 RoleBinding 을 만드는 예시이다: 

 

ClusterRoleBinding은 ClusterRole에만 참조할 수 있으며, 일반 Role에는 참조할 수 없다. 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-global
subjects:
- kind: User
  name: "jane"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader-global
  apiGroup: rbac.authorization.k8s.io

 

이 글에서는 sub