RBAC — 누가 K8s API 자체에 무엇을 할 수 있는가
Kubernetes Job/CronJob 및 RBAC 공식 문서 종합 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/workloads/controllers/job, reference/access-authn-authz/rbac) Kubernetes 공식문서 Using RBAC Authorization
이 모듈을 다 읽으면
- Role과 ClusterRole의 스코프 차이(네임스페이스 vs 클러스터 전체)를 설명할 수 있다
- RoleBinding이 ClusterRole을 특정 네임스페이스로 스코프를 좁혀 재사용하는 패턴을 설명할 수 있다
k8s-learn-16에서 다룬 NetworkPolicy(Pod 간 네트워크 트래픽 통제)와는 완전히 다른 층위로, RBAC는 'K8s API 자체'에 누가 어떤 동작(get/list/delete 등)을 할 수 있는지를 통제하는 인가(authorization) 체계라는 것을 정리한다.
Role/ClusterRole — 네임스페이스 스코프냐 클러스터 스코프냐
Role은 항상 특정 네임스페이스 하나에 속한다 — 생성할 때 반드시 그 네임스페이스를 지정해야 하고, 그 안의 리소스에 대한 권한만 정의한다. ClusterRole은 네임스페이스에 속하지 않는(non-namespaced) 리소스다 — 클러스터 전체 범위의 권한(Node, PersistentVolume, Namespace 같은 클러스터 스코프 리소스)을 정의하거나, 여러 네임스페이스에 걸친 네임스페이스 리소스 권한을 정의할 수 있다.
핵심 포인트
- Role: 특정 네임스페이스 하나에 속함, 그 안 리소스 권한만 정의
- ClusterRole: non-namespaced — 클러스터 스코프 리소스(Node·PV·Namespace 등) 권한 또는 여러 네임스페이스에 걸친 권한 정의 가능
RoleBinding/ClusterRoleBinding — 그 Role을 누구에게 적용할 것인가
Role·ClusterRole 자체는 '권한 정의'일 뿐이고, 실제로 누구에게 그 권한을 부여할지는 Binding이 결정한다. RoleBinding은 Role(또는 ClusterRole)을 특정 사용자·그룹·ServiceAccount에 바인딩하는데, 그 효력은 그 RoleBinding이 속한 네임스페이스 안으로 한정된다. ClusterRoleBinding은 ClusterRole을 클러스터 전체 범위로 바인딩한다.
핵심 포인트
- RoleBinding: Role(또는 ClusterRole)을 사용자·그룹·ServiceAccount에 바인딩, 효력은 그 RoleBinding이 속한 네임스페이스로 한정
- ClusterRoleBinding: ClusterRole을 클러스터 전체 범위로 바인딩
핵심 패턴 — RoleBinding이 ClusterRole을 특정 네임스페이스로 좁혀 재사용한다
실무에서 자주 쓰이는 조합이 있다 — ClusterRole 자체는 클러스터 전체에 적용 가능한 권한 정의지만, 그걸 ClusterRoleBinding이 아니라 RoleBinding으로 바인딩하면 그 ClusterRole에 정의된 권한이 '그 RoleBinding이 속한 네임스페이스 안에서만' 적용된다. 이 패턴 덕분에 'pod 읽기 권한' 같은 공통 ClusterRole 하나를 여러 네임스페이스에서 RoleBinding으로 각각 다르게 스코프를 좁혀 재사용할 수 있다 — 매번 똑같은 Role을 네임스페이스마다 새로 정의할 필요가 없다.
핵심 포인트
- ClusterRole을 RoleBinding으로 바인딩하면 그 권한이 해당 RoleBinding의 네임스페이스로만 스코프가 좁혀짐
- 공통 ClusterRole 하나('pod 읽기' 등)를 여러 네임스페이스에서 RoleBinding으로 재사용 가능 — 네임스페이스마다 같은 Role을 반복 정의할 필요 없음