Security - ClusterRole / ClusterRoleBinding

이전 글에서 Role / RoleBinding으로 “네임스페이스 내부 리소스”에 권한을 부여하는 방법을 정리했습니다.
이번에는 클러스터 전체 범위 리소스(예: Node, PV 등)에 권한을 주기 위해 사용하는 ClusterRole / ClusterRoleBinding을 정리합니다.

---

1) 리소스는 “네임스페이스 범위”와 “클러스터 범위”로 나뉜다

RBAC를 이해할 때 가장 먼저 잡아야 하는 기준은 리소스의 범위(scope)입니다.

네임스페이스 범위(Namespaced resources)

네임스페이스 안에 “소속”되는 리소스들입니다.

• Pod, ReplicaSet, Deployment, Job, Service
• Secret, ConfigMap
• (대부분의 워크로드/서비스 관련 리소스)

특징:

• 생성 시 네임스페이스가 필요(명시하지 않으면 default)
• 조회/수정/삭제 시에도 보통 -n <namespace>가 필요
• 권한은 Role / RoleBinding으로 부여

클러스터 범위(Cluster-scoped resources)

특정 네임스페이스에 소속될 수 없는 리소스들입니다.

• Node
• PersistentVolume(PV)
• CertificateSigningRequest(CSR)
• Namespace 오브젝트 자체
• ClusterRole / ClusterRoleBinding 자체(이것들도 클러스터 범위 리소스)

특징:

• 생성 시 네임스페이스를 지정하지 않음
• 권한은 보통 ClusterRole / ClusterRoleBinding으로 부여

요약:

• Namespaced 리소스 → Role/RoleBinding
• Cluster-scoped 리소스 → ClusterRole/ClusterRoleBinding

---

2) “노드도 네임스페이스에 속하나?” → 아니다

강의에서 던진 질문의 핵심은 이것입니다.

• “Node는 네임스페이스로 그룹화/격리할 수 있을까?”
• “Node-01이 특정 네임스페이스의 일부라고 말할 수 있을까?”

답은 불가능입니다. Node는 클러스터 전체 리소스이며 네임스페이스 개념에 매이지 않습니다.
따라서 Node 관련 권한은 Role이 아니라 ClusterRole로 다루는 것이 자연스럽습니다.

---

3) 전체 목록은 kubectl api-resources로 확인한다

강의에서 소개한 방법 그대로, 리소스가 namespaced인지 아닌지 확인하려면:

kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false

또는 특정 리소스를 검색:

kubectl api-resources | grep -E 'nodes|persistentvolumes|certificatesigningrequests|namespaces'

---

4) ClusterRole: 클러스터 범위 리소스에 대한 “권한 규칙”

ClusterRole은 Role과 구조가 거의 같습니다.

• apiVersion: rbac.authorization.k8s.io/v1
• kind: ClusterRole
• rules: apiGroups / resources / verbs

차이점:

• Role은 metadata.namespace가 있지만
• ClusterRole은 네임스페이스가 없다(클러스터 범위 오브젝트)

예시 1) 클러스터 관리용(Node 관리) ClusterRole

“노드를 보고/만들고/삭제할 수 있는” 권한:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-node-admin
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch", "create", "delete", "patch", "update"]

적용:

kubectl apply -f clusterrole-node-admin.yaml

예시 2) 스토리지 관리자(PV/PVC) ClusterRole

강의에서는 “PV 및 클레임”을 언급합니다. PV는 클러스터 범위, PVC는 네임스페이스 범위입니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: storage-admin
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete", "patch", "update"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "create", "delete", "patch", "update"]

PVC는 namespaced지만, ClusterRole에 넣어두면 “모든 네임스페이스의 PVC”까지 포괄하는 권한이 될 수 있습니다(아래 6번 참고).

---

5) ClusterRoleBinding: 사용자/그룹/SA를 ClusterRole에 연결

RoleBinding이 Role과 주체를 연결하듯,
ClusterRoleBinding은 ClusterRole과 주체(사용자/그룹/SA)를 연결합니다.

• kind: ClusterRoleBinding
• subjects: 누구에게
• roleRef: 어떤 ClusterRole에

예시) cluster-admin-user → cluster-node-admin 권한 부여

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-user-to-node-admin
subjects:
  - kind: User
    name: cluster-admin-user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-node-admin
  apiGroup: rbac.authorization.k8s.io

적용:

kubectl apply -f clusterrolebinding-node-admin.yaml

---

6) 중요한 주의: “ClusterRole은 클러스터 리소스만”이 엄격 규칙은 아니다

강의에서 강조한 포인트입니다.

• ClusterRole/ClusterRoleBinding은 주로 클러스터 범위 리소스를 위해 쓰지만,
• 네임스페이스 리소스에 대해서도 ClusterRole을 만들 수 있습니다.

이게 의미하는 바:

• Role로 Pod 권한을 주면 → 특정 네임스페이스에서만 Pod 접근 가능
• ClusterRole로 Pod 권한을 주면 → 클러스터의 모든 네임스페이스 Pod에 접근 가능(바인딩 방식에 따라 달라질 수 있지만 기본적으로 범위가 커짐)

즉, “Pod 접근 권한” 같은 것도 ClusterRole로 주면 영향 범위가 커지므로 운영에서는 신중해야 합니다.

예시) 모든 네임스페이스의 Pod 조회 권한(읽기)

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

이걸 ClusterRoleBinding으로 사용자에게 붙이면, 그 사용자는 전 네임스페이스 Pod를 볼 수 있습니다.

---

7) 조회/디버깅 명령

목록/상세 확인

kubectl get clusterroles
kubectl get clusterrolebindings

kubectl describe clusterrole cluster-node-admin
kubectl describe clusterrolebinding cluster-admin-user-to-node-admin

권한 확인: kubectl auth can-i

특히 --as로 사용자 가장 테스트가 유용합니다.

kubectl auth can-i list nodes --as=cluster-admin-user
kubectl auth can-i delete nodes --as=cluster-admin-user

kubectl auth can-i list pods --as=cluster-admin-user -n default
kubectl auth can-i list pods --as=cluster-admin-user -n kube-system

---

8) 기본 제공 ClusterRole이 이미 많다

Kubernetes는 클러스터 설치 시 기본적으로 여러 ClusterRole을 생성합니다(강의 언급).
예를 들어 운영에서 자주 보게 되는 것들(환경마다 다를 수 있음):

• cluster-admin (최고 권한)
• admin, edit, view (네임스페이스 단위 운영에서 자주 사용)

확인은:

kubectl get clusterroles | head
kubectl get clusterroles | grep -E 'cluster-admin|admin|edit|view'

---

핵심 정리

• 리소스는 namespaced와 cluster-scoped로 구분된다.
• Node/PV/CSR/Namespace 같은 클러스터 리소스 권한은 ClusterRole/ClusterRoleBinding이 기본 선택이다.
• ClusterRole은 Role과 문법이 유사하지만 네임스페이스가 없다.
• ClusterRole을 네임스페이스 리소스에 적용할 수도 있으며, 이 경우 보통 모든 네임스페이스에 영향을 주므로 주의해야 한다.
• 검증은 kubectl auth can-i + --as가 표준이다.

 

Practice Test: https://uklabs.kodekloud.com/topic/practice-test-cluster-roles-2/