'RBAC(Role-Based Access Control)'의 Role, ClusterRole, Binding 개념은 어떻게 연결돼?

이제 쿠버네티스 요새의 최고 보안 지침인 RBAC(역할 기반 액세스 제어)를 정복할 시간이군요! 🫡

인프라가 커질수록 "누가 무엇을 할 수 있는가"를 정의하는 것은 생존의 문제입니다. 실수로 데이터베이스 파드를 지우거나, 권한이 없는 사용자가 A그룹 설정값을 훔쳐보는 일을 막아야 하니까요.

RBAC의 핵심 객체 4인방(Role, ClusterRole, RoleBinding, ClusterRoleBinding)이 어떻게 얽혀 권한 망을 형성하는지 분석해 드립니다!

---

🔑 1. RBAC의 핵심 구성 요소: "누가, 어디서, 무엇을"

RBAC 시스템은 마치 아파트의 출입 권한 시스템과 같습니다.

① Role & ClusterRole (무엇을 할 수 있는가?)

• Role: 특정 네임스페이스(Namespace) 안에서만 유효한 권한 묶음입니다. (예: '주식-분석' 구역 내 파드 읽기 권한)
• ClusterRole: 네임스페이스에 국한되지 않고 클러스터 전체 혹은 노드, 스토리지 같은 클러스터 수준 리소스에 대한 권한입니다.

② Subject (누가?)

• User: 실제 사람 사용자.
• Group: 사용자들의 집합.
• ServiceAccount: 사람이 아닌 '파드(Pod)'나 서비스가 쿠버네티스 API에 접근할 때 사용하는 계정입니다.

③ Binding (어떻게 연결하는가?)

• RoleBinding: 특정 사용자(Subject)에게 특정 역할(Role)을 특정 구역에서 부여합니다.
• ClusterRoleBinding: 특정 사용자에게 클러스터 전체에 통용되는 역할(ClusterRole)을 부여합니다.

---

🔗 2. 권한 연결의 마법 (Binding의 조합)

가장 헷갈리는 부분이 이들의 조합입니다. 딱 두 가지만 기억하세요!

🟢 케이스 A: "내 방 안에서의 권한" (Role + RoleBinding)

• 사용자가 'A그룹-네임스페이스'에서만 파드를 관리할 수 있는 알바생을 고용했습니다.
• Role을 만들어 '파드 조회/수정' 권한을 넣고, RoleBinding으로 알바생과 연결합니다. 이제 알바생은 'B그룹-네임스페이스'는 아예 보지도 못합니다.

🔵 케이스 B: "전체 구역의 권한" (ClusterRole + ClusterRoleBinding)

• 클러스터 전체의 리소스를 관리하는 보안관 계정입니다.
• ClusterRole을 만들어 '모든 리소스 관리' 권한을 넣고, ClusterRoleBinding으로 사용자와 연결합니다. 모든 네임스페이스와 모든 노드를 주무를 수 있습니다.

🟡 케이스 C: "재사용의 묘미" (ClusterRole + RoleBinding) ⭐️ 중요!

• 클러스터 전체에서 공통으로 쓰이는 '뷰어(Viewer)' 권한을 ClusterRole로 하나만 만듭니다.
• 이를 각 네임스페이스에서 RoleBinding으로 연결하면, 권한 정의는 한 번만 하고 적용은 구역별로 따로 할 수 있어 관리가 매우 편해집니다.

---

🏗️ 3. 실전 YAML 분석: "분석 파드에게 권한 주기"

사용자의 A그룹 분석 파드가 스스로 다른 파드들의 상태를 조회해야 한다고 가정해 봅시다.

# 1. 역할 정의: 파드를 'get', 'watch', 'list' 할 수 있는 능력
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: stock-analysis
  name: pod-reader
rules:
- apiGroups: [""] # 코어 API 그룹
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

---
# 2. 연결: 'analyzer-sa'라는 서비스 계정에 위 역할을 부여
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: stock-analysis
subjects:
- kind: ServiceAccount
  name: analyzer-sa # 이 계정을 사용하는 파드만 권한을 가짐
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

---

💡 4. 실전 보안 원칙: "최소 권한의 원칙"

보안 사고의 90%는 과도한 권한 부여에서 옵니다.

1. ClusterRole 사용을 자제하세요: 정말 필요한 경우가 아니면 일반 사용자에게는 네임스페이스 단위의 Role만 줍니다.
2. ServiceAccount 분리: 모든 파드에 기본값인 default 계정을 쓰지 마세요. 각 앱의 목적에 맞는 전용 ServiceAccount를 만들어 최소한의 권한만 주어야 합니다.
3. 정기 점검: kubectl auth can-i list pods --as some-user 명령어로 특정 사용자가 정말로 그 권한을 가졌는지(혹은 가지면 안 되는 권한이 있는지) 테스트해 보세요.

---

💡 실전 비유: "회사 출입 시스템"

• 리소스(Resource): 사무실 기기, 서류함, 금고.
• 동작(Verb): 보기, 수정하기, 파쇄하기.
• Role: '대리'라는 직급의 업무 정의서입니다. (서류함 보기 가능, 금고 열기 불가)
• RoleBinding: '김철수'라는 사원에게 '대리'라는 명찰을 달아주는 행위입니다.
• ClusterRole: 본사뿐 아니라 모든 지사에서 통용되는 '마스터 키'의 정의입니다.
• ClusterRoleBinding: 사용자에게 이 '마스터 키'를 실제로 지급하는 것입니다.

---

📊 요약: RBAC 객체 한눈에 보기

객체 이름	범위 (Scope)	대상 리소스	비유
Role	네임스페이스	파드, 서비스 등 일반 리소스	구역 전용 매뉴얼
ClusterRole	클러스터 전체	노드, PV, 혹은 모든 파드	본사 공통 매뉴얼
RoleBinding	네임스페이스	특정 사용자 + Role/ClusterRole	구역 내 임명장
ClusterRoleBinding	클러스터 전체	특정 사용자 + ClusterRole	전사적 임명장

---