🔐 신입이 실수로 서버를 지우지 못하게 – Kubernetes RBAC 설정

지금까지는 클러스터의 모든 권한을 가진 admin 계정으로 실습했습니다. 실제 회사라면 이렇게 하면 안 됩니다. 신입 개발자에게 kubectl 권한을 주는데 실수로 kubectl delete pod --all을 치는 사고가 일어날 수 있죠. RBAC(Role-Based Access Control) 은 “누가, 어떤 리소스에, 무엇을 할 수 있는지”를 세밀하게 제어하는 쿠버네티스의 보안 시스템입니다.

---

🎯 이번 실습 시나리오

신입 개발자용 계정(dev-sa)을 만들어서 다음과 같이 권한을 제한합니다.

• ✅ 가능: 파드 목록 조회(list), 상세 조회(get), 로그 보기(watch)
• ❌ 불가능: 파드 삭제(delete), 생성(create), 수정(edit)

---

🧩 RBAC의 3요소

파일 3개를 분리해서 만드는 게 핵심입니다. 이유가 있습니다.

요소	YAML	역할
ServiceAccount	dev-sa.yaml	사원증 (ID만 있음, 권한 없음)
Role	pod-reader-role.yaml	업무 매뉴얼 (무엇을 할 수 있는지 규칙)
RoleBinding	dev-rolebinding.yaml	근로계약서 (사원에게 업무를 부여)

파일을 분리하면 재사용이 됩니다. 새 팀원이 들어오면 dev-sa.yaml만 새로 만들고 같은 Role을 Binding하면 됩니다. Role은 수정 없이 재활용합니다.

---

🛠️ 구현

Step 1: 계정 생성 (ServiceAccount)

# dev-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-sa
  namespace: default

kubectl apply -f dev-sa.yaml

Step 2: 권한 규칙 정의 (Role)

# pod-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]     # 파드와 파드 로그에만 적용
  verbs: ["get", "list", "watch"]     # 조회만 허용, delete 없음!

kubectl apply -f pod-reader-role.yaml

Step 3: 권한 연결 (RoleBinding)

# dev-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-pod-reader
  namespace: default
subjects:
- kind: ServiceAccount
  name: dev-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f dev-rolebinding.yaml

---

✅ 권한 검증

admin 계정에서 로그아웃하지 않고, --as 옵션으로 dev-sa 계정을 흉내내서(Impersonation) 테스트합니다.

# 파드 목록 조회 → 성공해야 함
kubectl auth can-i list pods --as=system:serviceaccount:default:dev-sa
# 결과: yes ✅

# 파드 삭제 → 거부돼야 함
kubectl auth can-i delete pods --as=system:serviceaccount:default:dev-sa
# 결과: no 🛡️

# 파드 생성 → 거부돼야 함
kubectl auth can-i create pods --as=system:serviceaccount:default:dev-sa
# 결과: no 🛡️

---

🔍 계정 이름 구조 뜯어보기

--as 옵션에 쓰이는 system:serviceaccount:default:dev-sa의 의미:

system:serviceaccount : default : dev-sa
│                        │         │
│                        │         └── 계정 이름 (우리가 지정)
│                        └── 네임스페이스 (계정이 속한 공간)
└── 시스템 계정임을 나타내는 접두어 (고정값)

---

💡 Role vs ClusterRole — 범위가 다릅니다

	Role	ClusterRole
적용 범위	특정 네임스페이스	전체 클러스터
사용 케이스	팀별 권한 분리	노드 관리, PV 관리 등

지금 만든 pod-reader Role은 default 네임스페이스에서만 유효합니다. 다른 네임스페이스의 파드는 볼 수 없습니다. 전체 클러스터의 파드를 볼 수 있게 하려면 ClusterRole을 써야 합니다.

---

💡 실제 적용 예시

라즈베리파이 프로젝트에 적용했을 때의 계획:

admin 계정: 클러스터 전체 관리
prometheus-sa: 메트릭 수집용 (nodes, pods 조회만)
dev-sa: 파드 조회 + 로그 보기 (삭제 불가)
ci-sa: Deployment 업데이트만 가능 (삭제 불가)

외부 모니터링 도구(Prometheus)에 전체 admin 권한을 주지 않고, 필요한 권한만 딱 잘라 주는 방식입니다.

---

✅ 정리

RBAC은 쿠버네티스 클러스터를 여러 팀이 사용하는 환경에서 필수입니다. 권한 설계는 “최소 권한 원칙(Principle of Least Privilege)” — 필요한 것만, 필요한 범위에서만 부여하는 게 기본입니다.

다음 글에서는 트래픽이 몰릴 때 자동으로 파드를 늘리는 HPA(Horizontal Pod Autoscaler) 를 다룹니다.