우선 제 홈랩 영역에 외부 사용자(테넌트)가 들어올 수 있기 때문에 권한 격리를 했습니다.

1. [기능 설명] 테넌트 인증 및 권한 격리 (RBAC)

클러스터 내에서 각 테넌트가 자신의 자원만 제어할 수 있도록 논리적 격리를 구현하는 것.(CSP 서비스에서 사용자가 본인의 인스턴스만 제어하고 타인의 정보는 볼 수 없는 환경을 쿠버네티스에서 재현하고자 함.)

1-1. 주요 설계 목표

• 논리적 공간 분리 : 각 테넌트에게 전용 Namespace 를 할당하여 자원이 섞이지 않게 함
• 전용 계정 생성 : 클러스터 전체 관리자 권한이 아닌, 특정 테넌트 전용 ServiceAccount 를 발급함
• 권한 범위 제한 : RoleBinding 을 통해 해당 계정이 지정된 Namespace 내부의 리소스(Pod, Service 등)만 관리할 수 있도록 제한함

1-2. 필요한 쿠버네티스 기술 객체

Namespace

• 클러스터 내의 가상 클러스터, 리소스 격리의 기본 단위

ServiceAccount

• 파드(Pod) 또는 외부 사용자(테넌트)가 쿠버네티스 API를 호출할 때 사용하는 인증 주체
  • → 일반 User 는 인증서 발급 등 외부 인프라 관리가 필요하지만, ServiceAccount 는 쿠버네티스 내부 리소스로서 API Token(인증 토큰) 기반으로 관리가 용이하기 떄문에 테넌트에게 즉시 권한을 부여하는 모델에 적합함.

ClusterRole (admin)

• 쿠버네티스에 미리 정의된 역할로, 리소스에 대한 생성/수정/삭제 권한을 가짐

RoleBinding

• 특정 ServiceAccount 를 특정 Namespace 내의 ClusterRole 과 연결하여 권한을 발효시킴

---

2. [기능 개발] YAML 매니페스트 및 테스트

2-1. 테넌트 격리 환경 정의

• tenant-setup.yaml

# 1. 테넌트 전용 네임스페이스 생성
apiVersion: v1
kind: Namespace
metadata:
  name: tenant-alpha
---
# 2. 테넌트 전용 서비스 어카운트 생성
apiVersion: v1
kind: ServiceAccount
metadata:
  name: alpha-user
  namespace: tenant-alpha
---
# 3. 권한 연결 (RoleBinding)
# ClusterRole인 'admin'을 'tenant-alpha' 네임스페이스 내의 'alpha-user'에게만 매핑합니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alpha-user-admin-binding
  namespace: tenant-alpha
subjects:
- kind: ServiceAccount
  name: alpha-user
  namespace: tenant-alpha
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

📌 RoleBinding

• 누가(Subject), 무엇을(RoleRef), 어디에서(Namespace) 할 수 있는지를 연결
  • metadata.namespace
    • 권한이 효력을 발휘할 범위(Scope)를 결정
    • tenant-alpha 를 적었기 때문에, 이 권한은 다른 네임스페이스에는 아무런 영향을 주지 않음
  • subjects (권한을 받는 대상)
    • kind: ServiceAccount : 권한을 부여할 대상의 유형
    • name: alpha-user : 위에서 만든 서비스 어카운트의 이름을 정확히 지칭
  • roleRef (부여할 권한 내용)
    • kind: ClusterRole : 권한의 정의가 클러스터 전체 수준에서 공용으로 만들어진 것
    • name: admin : 쿠버네티스가 기본적으로 제공하는 ‘관리자용 권한 세트’.
      • 파드 생성, 수정, 삭제, 서비스 생성 등 네임스페이스 내의 거의 모든 작업이 포함되어 있음
    • apiGroup: rbac.authorization.k8s.io : RBAC 기능을 담당하는 쿠버네티스 API 그룹

2-2. 환경 적용 및 접속 토큰 발행

• 작성한 매니페스트를 클러스터에 반영하고, 테넌트가 외부에서 API 서버에 인증할 때 사용할 Access Token을 발행

# 매니페스트 적용
kubectl apply -f tenant-setup.yaml

# 테넌트용 토큰 발행 (보안을 고려하여 24시간 유효 기간 설정)
kubectl create token alpha-user -n tenant-alpha --duration=24h

2-3. 권한 검증 (Impersonation 테스트)

• 관리자 권한을 가진 상태에서 특정 계정을 사칭(--as)하여, 설정한 RBAC 정책이 의도대로 동작하는지 확인

• 정상 동작 확인: tenant-alpha 네임스페이스 내의 자원 조회

kubectl get pods -n tenant-alpha --as=system:serviceaccount:tenant-alpha:alpha-user

-> No resources found (성공 → 권한이 있어 조회가 가능하지만 생성된 파드가 없음)

• 격리 동작 확인: 관리 영역인 kube-system 네임스페이스 자원 조회

kubectl get pods -n kube-system --as=system:serviceaccount:tenant-alpha:alpha-user

-> Error from server (Forbidden) (성공 - 권한이 없어 접근이 차단됨)

마무리

이번 작업에서는 RBAC 을 기반으로 관리자(나)와 테넌트(사용자)의 권한 격리를 진행해보았습니다. 다음 포스트에서는 스토리지 격리를 설정해보겠습니다.

---

p.s) 처음 보는 쿠버네티스 개념이 너무 많은 것 같습니다. CKA 준비도 병행하고 있는데 운동 많~이 됩니다~^^