[k8s] RBAC ㅡ 이해하기

14:36:36 [root@k8s-worker-jwc:~]$ kubectl get serviceaccount -n dev
NAME       SECRETS   AGE
default    0         23h
readuser   0         4h12m

RBAC

누가 뭘 할 수 있는지 — 역할 기반 접근 제어

---

RBAC이란?

RBAC(Role-Based Access Control)은 역할 기반 접근 제어다. k8s 클러스터에서 "누가 어떤 리소스에 어떤 동작을 할 수 있는지"를 정의한다. 예를 들어 개발자는 Pod 조회만 가능하고, 운영자는 배포까지 가능하게 설정할 수 있다.

RBAC은 3가지 오브젝트로 구성된다.

오브젝트	역할	예시
Role	"뭘 할 수 있는지" 권한 정의	dev 네임스페이스 Pod 조회 가능
ServiceAccount	k8s 안에서 쓰는 계정	readuser
RoleBinding	Role과 계정을 연결	readuser에게 Pod 조회 Role 부여

흐름은 항상 같다.

Role 생성 → ServiceAccount 생성 → RoleBinding으로 연결 → 권한 확인

---

Role 생성 — 권한 정의

dev 네임스페이스에서 Pod를 읽기만 할 수 있는 Role을 만든다.

# Role 생성
kubectl create role pod-reader \
  --verb=get,list,watch \
  --resource=pods \
  -n dev

# 옵션 설명
# pod-reader     : Role 이름 (직접 정하는 것)
# --verb         : 허용할 동작 (get=단건조회, list=목록조회, watch=실시간감시)
# --resource     : 대상 리소스 (pods, deployments, services 등)
# -n dev         : dev 네임스페이스에 적용

만들어진 Role을 yaml로 확인하면 rules 구조를 볼 수 있다.

kubectl get role pod-reader -n dev -o yaml

rules:
- apiGroups:
  - ""
  resources:
  - pods           # 대상 리소스
  verbs:
  - get
  - list
  - watch          # 허용 동작 (create, delete 없음)

 

14:36:34 [root@k8s-worker-jwc:~]$ kubectl get role pod-reader -n dev -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: "2026-06-10T01:21:46Z"
  name: pod-reader
  namespace: dev
  resourceVersion: "7334719"
  uid: b096404f-1130-4646-a377-65e8134f97b4
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

---

ServiceAccount 생성 — 계정 만들기

k8s에서 사용자 계정은 ServiceAccount로 관리한다. dev 네임스페이스에 readuser 계정을 만든다.

# ServiceAccount 생성
kubectl create serviceaccount readuser -n dev

# 확인
kubectl get serviceaccount -n dev

 

---

RoleBinding — Role과 계정 연결

Role과 ServiceAccount를 연결한다. 이 시점부터 readuser 계정에 pod-reader 권한이 적용된다.

# RoleBinding 생성
kubectl create rolebinding pod-reader-binding \
  --role=pod-reader \
  --serviceaccount=dev:readuser \
  -n dev

# 옵션 설명
# pod-reader-binding        : RoleBinding 이름 (직접 정하는 것)
# --role=pod-reader         : 연결할 Role 이름
# --serviceaccount=dev:readuser : 대상 계정 (네임스페이스:계정명)
# -n dev                    : dev 네임스페이스에 적용

주의: RoleBinding도 반드시 -n dev 를 붙여야 한다. 빠뜨리면 default 네임스페이스에 생성되어 권한이 제대로 적용되지 않는다.

[ 캡처 - RoleBinding 생성 확인 ]

---

권한 확인 — kubectl auth can-i

kubectl auth can-i 명령어로 특정 계정의 권한을 확인할 수 있다. 실제로 해당 계정으로 로그인하지 않아도 테스트가 가능하다.

# Pod 조회 권한 확인 → yes
kubectl auth can-i get pods -n dev --as=system:serviceaccount:dev:readuser

# Pod 삭제 권한 확인 → no
kubectl auth can-i delete pods -n dev --as=system:serviceaccount:dev:readuser

yes   ← get 허용됨
no    ← delete 차단됨

--as=system:serviceaccount:네임스페이스:계정명 형식으로 특정 계정을 가장해서 권한을 테스트한다.

[ 캡처 - auth can-i 결과 yes/no ]

---

Role vs ClusterRole

지금까지 만든 Role은 특정 네임스페이스에만 적용된다. 클러스터 전체에 적용하려면 ClusterRole을 쓴다.

	Role + RoleBinding	ClusterRole + ClusterRoleBinding
적용 범위	특정 네임스페이스	클러스터 전체
용도	팀별/환경별 권한 분리	클러스터 관리자 권한

---

다음 파트는 HPA — 트래픽에 따라 Pod 수를 자동으로 조절하는 방법을 다룬다.