← 목차
Week 6 · Phase 3 운영과 확장

보안과 RBAC
+ Pod Security

인증·인가의 차이, RBAC 4대 리소스, ServiceAccount, X.509/OIDC 사용자, 그리고 Pod Security Admission
학습 자료 · k8s-rbac · podsecurity_admission
산출물 · 팀별 권한 분리 + ServiceAccount + PSA 적용
Kubernetes 10주 교육 커리큘럼 · github.com/kjin17/k8s_study
VMware by Broadcom

학습 목표

"누가, 무엇을, 어디까지 할 수 있나"
  • 인증 vs 인가 — Authentication(누구인가)과 Authorization(무엇을 허용)의 차이를 안다
  • RBAC 4대 리소스 — Role / ClusterRole / RoleBinding / ClusterRoleBinding을 작성한다
  • ServiceAccount — Pod 워크로드의 권한을 분리한다
  • X.509 / OIDC — 사용자 인증 흐름을 이해하고 직접 사용자를 만든다
  • Pod Security Admission — 네임스페이스 단위 Pod 보안 정책을 적용한다
VMware by Broadcom
2

인증(AuthN) → 인가(AuthZ) → Admission

API 요청이 통과하는 3개의 관문
요청 ① 인증 (AuthN)X.509 · OIDC · SA Token ② 인가 (AuthZ)RBAC 규칙 검사 ③ Admission (PSA 등)정책 검증 → etcd 저장 인증: "너 누구야?" · 인가: "그거 해도 돼?" · Admission: "정책에 맞아?" — 셋 다 통과해야 반영
VMware by Broadcom
3

RBAC 4대 리소스 조합

권한(Role)과 부여(Binding)를 범위(네임스페이스/클러스터)로 조합
리소스범위역할
Role네임스페이스해당 NS 안의 권한 규칙 정의
ClusterRole클러스터 전체클러스터 범위 권한 or 여러 NS 재사용
RoleBinding네임스페이스주체(User/SA)에게 Role/ClusterRole을 NS에 부여
ClusterRoleBinding클러스터 전체주체에게 ClusterRole을 전 클러스터에 부여
VMware by Broadcom
4

ServiceAccount & Pod Security Admission

워크로드 권한 분리 + 네임스페이스 Pod 보안
ServiceAccount

워크로드의 신원

  • Pod에 SA 할당 → 해당 권한으로만 API 호출
  • Token(1.24+ 프로젝티드·단명) 자동 마운트
  • 예: Jenkins SA는 ci NS만, prod는 read-only
PSA

3 레벨 × 3 모드

  • 레벨: privileged / baseline / restricted
  • 모드: enforce(차단) / audit(기록) / warn(경고)
  • NS 라벨로 적용 · restricted = runAsNonRoot·drop ALL
VMware by Broadcom
5

라이브 실습 — RBAC & 권한 검증

사용자를 만들고 권한 범위를 확인
# 인터랙티브 RBAC 스크립트 (SA→Role/Binding→권한테스트→X.509 사용자) $ ./k8s-rbac.sh # alice 사용자 권한 영향 범위 검증 $ kubectl auth can-i --list -n dev --as=alice $ kubectl auth can-i create deployments -n prod --as=alice # no $ kubectl auth can-i create deployments -n dev --as=alice # yes
VMware by Broadcom
6

과제 — 권한 설계 & 강제

회사 시나리오로 권한 체계를 설계
RBAC 설계

팀별 권한 분리

  • dev팀(dev/test edit) · ops팀(전체 view) · security팀(audit) RBAC 설계서+적용
  • Jenkins SA: ci NS만 동작, prod read-only
  • Forbidden 분석 → 최소 권한만 추가 워크플로우 문서화
PSA 강제

restricted 차단

  • restricted NS에 권한 부족 Pod 배포 → 차단 로그 분석
  • 워크로드 수정: runAsNonRoot, drop ALL capabilities
VMware by Broadcom
7

체크리스트 & 다음 주

이걸 할 수 있으면 Week 6 완료
  • kubectl auth can-i / impersonation(--as)을 활용할 수 있다
  • Role/ClusterRole/RoleBinding/ClusterRoleBinding 4조합을 그릴 수 있다
  • X.509 CSR로 사용자를 만들고 kubeconfig를 발급할 수 있다
  • Pod에 ServiceAccount를 할당하고 token을 검증할 수 있다
  • PSA 3레벨·3모드(enforce/audit/warn)의 차이를 설명할 수 있다
→
다음 주(Week 7) — CRD·Operator·Cluster API로 K8s를 확장하고, Helm/Carvel로 패키지를 관리합니다.
VMware by Broadcom
8