[TIL] Kubernetes 보안 & 커스텀 리소스-2025.09.02

1. 인증(Authentication) & 인가(Authorization)

• 인증: "너 누구냐?" → 사용자를 확인 (X.509 인증서, ServiceAccount, OIDC 토큰).
• 인가: "뭐 할 수 있냐?" → RBAC(Role-Based Access Control)로 권한 제어.
• RBAC 핵심 요소
  • Role / ClusterRole: 권한 정의.
  • RoleBinding / ClusterRoleBinding: 권한과 주체(User, Group, ServiceAccount) 연결.
• 실습 예제
  • dev-user → development 네임스페이스에서 파드 조회만 가능하도록 Role + RoleBinding 생성.
  • kubectl auth can-i list pods --as dev-user → yes.
  • 삭제/다른 네임스페이스 접근 → no.
• 인사이트: 최소 권한 원칙(Principle of Least Privilege)을 보장해야 클러스터 보안 강화 가능.

 

2. 관리자와 사용자 관리

• 관리자 업무 3단계
  1. Role/ClusterRole 생성: 권한 정의.
  2. 사용자 인증서 생성 & 전달: 개인 키(.key), 인증서(.crt), CA 인증서 제공.
  3. RoleBinding/ClusterRoleBinding 연결: 사용자와 권한 매핑.
• 자동화 스크립트 제공: CSR 생성 → 승인 → 인증서 추출까지 자동화.
• 사용자 측 설정
  • kubectl 설치, 받은 인증서/키/CA를 ~/.kube에 배치.
  • kubeconfig 생성 (kubectl config set-cluster, set-credentials, set-context).
  • auth can-i로 권한 테스트.
• 포인트: 관리자/사용자 간 보안 채널로 인증 정보를 전달하는 것이 중요.

 

3. ClusterRole

• Role vs ClusterRole
  • Role → 단일 네임스페이스 한정.
  • ClusterRole → 클러스터 전체/네임스페이스 무관 리소스 관리.
• 사용 시점
  1. 클러스터 범위 리소스 (Node, PV, Namespace 등).
  2. 모든 네임스페이스에 동일 권한 부여 필요 시.
• 예제: storage-admin ClusterRole
  • PV 전체 제어.
  • StorageClass 읽기 권한.
  • 모든 네임스페이스 PVC 읽기 권한.
• ClusterRoleBinding
  • User(dev-user, dev-user2 등)에게 storage-admin 권한 연결.
• 주의: 매우 강력하므로 최소 권한 원칙 유지 필요.

 

4. ServiceAccount

• 정의: Pod 내부 프로세스가 API 서버와 통신할 때 사용하는 “로봇 계정”.
• 작동 원리
  1. 자동 할당 (default ServiceAccount).
  2. 토큰이 /var/run/secrets/...에 자동 마운트.
  3. Pod 내부 앱이 토큰을 Authorization 헤더로 API 서버 호출.
  4. API 서버는 토큰 기반 인증 → RBAC 권한 확인.
• 예제 1: Pod Lister
  • ServiceAccount pod-lister-sa 생성.
  • Role(get, list, watch pods) + RoleBinding 연결.
  • Test Pod 실행 시 kubectl get pods 성공 로그 확인.
• 예제 2: storage-admin 권한 부여
  • ServiceAccount storage-pod-sa 생성.
  • 기존 storage-admin ClusterRole과 ClusterRoleBinding으로 연결.
  • 해당 SA 사용하는 Pod → PV, PVC, SC 조회 가능 / Pod 조회 불가.
• 핵심: Pod는 반드시 ServiceAccount 통해 권한 획득 → 안전한 권한 분리 실현.

 

5. 커스텀 리소스 & 컨트롤러

• Custom Resource (CR)
  • 쿠버네티스 API 확장 → 새로운 리소스 타입 정의 가능.
  • CRD(CustomResourceDefinition) 생성으로 스키마 등록.
  • 예: Greeting 리소스 정의 → message, recipient 필드 포함.
• Controller
  • Desired State vs Actual State 맞추는 제어 루프.
  • 예: Deployment Controller, Service Controller.
• Operator 패턴
  • CR + Controller 조합 → 고급 자동화.
  • 예: Greeting CR 생성 → Greeting Controller가 이벤트 감지 → 로그 출력/알림 전송 등 동작 수행.
• 실습 흐름
  1. CRD 정의 및 배포 (greeting-crd.yaml).
  2. CR 인스턴스 생성 (my-greeting.yaml).
  3. Controller 이미지 빌드 및 배포.
  4. 로그 모니터링하며 CR 수정/삭제 이벤트 확인.
• 의미: 쿠버네티스를 “앱 운영 플랫폼”으로 확장하는 핵심 메커니즘.

핵심

1. 보안 계층화
   • 사용자(User)와 Pod(ServiceAccount)를 명확히 구분.
   • RBAC + 최소 권한 원칙으로 안정성 확보.
2. 권한 범위 관리
   • Role은 네임스페이스 한정, ClusterRole은 전체 범위.
   • 잘못 쓰면 클러스터 전체 위험 가능 → 반드시 주의.
3. 운영 자동화
   • 관리자 인증서 발급 & 사용자 환경 세팅은 스크립트로 표준화 가능.
   • ServiceAccount 활용 시 애플리케이션도 RBAC 기반 권한 획득.
4. 플랫폼 확장성
   • Custom Resource + Controller(Operator)로 쿠버네티스를 데이터베이스, 메시지 큐 등 복잡한 시스템 운영 플랫폼으로 확장 가능.