[Kubernetes] RBAC 설정

개념

K8s(Kubernetes)는 RBAC(Role-Based Access Control)을 통해 사용자(User) 또는 서비스 계정(ServiceAccount)에 리소스 접근 권한을 부여한다.

 

권한 구성

K8s 권한은 아래 3가지 원칙으로 구성한다.

1. 최소 권한 원칙(Principle of Least Privilege) 적용
   • 필요 최소한의 권한만 부여
   • 모든 권한을 admin으로 주지 않도록 주의
2. 네임스페이스별 격리
   • 프로젝트나 서비스별로 네임스페이스를 분리하고 Role/RoleBinding으로 관리
3. 서비스 계정 사용 권장
   • 사람 계정(User) 보다는 서비스 계정(ServiceAccount)으로 권한 부여
   • Pod가 권한을 사용해야 하는 경우 서비스 계정 연동

 

구성 원칙에 따라 네임스페이스 또는 클러스터 단위로 설정이 가능하다.

 

1. 네임스페이스 단위로 권한 부여

• 적용 범위: 특정 네임스페이스 내부 리소스에만 권한을 부여
• 사용 목적: 팀별 권한 분리, 환경별 접근 제한
• 주요 리소스 예시:
  • Pods, Services, ConfigMaps, Secrets, Deployments, StatefulSets 등 네임스페이스 단위 리소스
• 주요 오브젝트:
  • Role: 특정 네임스페이스 내 리소스에 대한 권한을 정의
  • RoleBinding: Role을 사용자/서비스 계정에 연결 (네임스페이스 단위)
• 사용 사례:
  • 개발팀에게 dev 네임스페이스 내 Pods와 ConfigMaps를 수정할 권한만 부여
  • QA팀에게 qa 네임스페이스 내만 접근 가능하도록 제한
  • 서비스 계정별 세밀한 권한 제어 가능 (예: 특정 애플리케이션만 ConfigMap 읽기 권한)

2. 클러스터 단위로 권한 부여

• 적용 범위: 클러스터 전체 또는 여러 네임스페이스에 걸친 권한 부여
• 사용 목적: 클러스터 관리, 모니터링/로깅, 전체 리소스 접근이 필요한 서비스 계정 설정
• 주요 리소스 예시:
  • Nodes, PersistentVolumes, Namespaces, ClusterRoles 와 같은 클러스터 단위 리소스
  • 네임스페이스 포함 가능: 모든 네임스페이스의 Pods, Deployments 등
• 주요 오브젝트:
  • ClusterRole: 클러스터 전체 리소스 또는 특정 네임스페이스 포함 권한을 정의
  • ClusterRoleBinding: ClusterRole을 사용자/서비스 계정에 연결 (클러스터 단위)
• 사용 사례:
  • 클러스터 관리자가 모든 네임스페이스에서 리소스를 생성/삭제/조회 가능하도록 설정
  • 모니터링 툴(prometheus 등)이 모든 네임스페이스의 Pod 상태를 조회하도록 설정
  • CSI 드라이버가 모든 PersistentVolume을 관리할 수 있도록 설정

 

Helm 차트로 필요한 권한 확인하는 방법

$ helm template <release> <chart.tgz> -f <values.yaml> -n <namespace> > <output.yaml>

• helm template : Helm Chart를 실제 클러스터에 적용하지 않고 YAML로 렌더링
• <release> : 임의로 지정하는 release 이름
• <chart.tgz> : 렌더링할 Helm Chart 패키지
• -f <values.yaml> : 기본값을 덮어쓸 사용자 지정 values 파일
• -n <namespace> : 리소스 네임스페이스 지정

 

예시:

$ helm template test krypton-4.16.0-gl1302195.tgz -f QA/zlm-MYS.yaml -n ns-krypton > test.yaml
$ cat test.yaml | grep -E "kind:|apiVersion:"

apiVersion: v1
kind: Secret
apiVersion: v1
kind: Secret
kind: ConfigMap
apiVersion: v1
kind: ConfigMap
apiVersion: v1
apiVersion: v1
kind: PersistentVolume
apiVersion: v1
kind: PersistentVolumeClaim
apiVersion: v1
kind: Service
apiVersion: apps/v1
kind: Deployment

 

 

=> secret, configmap, pv, pvc, service, deployment 관련 권한 필요.

 

권한 설정 예시

1. Role & RoleBinding

 

Role 생성 → ns-infra 네임스페이스에서 Pod를 조회, 생성, 삭제할 수 있는 권한 정의

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: ns-infra
  name: pod-manager
rules:
  - apiGroups: [""]
    resources: ["pods"]                                       # 파드
    verbs: ["get", "list", "watch", "create", "delete"]       # 조회, 생성, 삭제

 

+ Role 을 생성하지 않고 기본 ClusterRole을 사용해도 된다.

기본 ClusterRole

 

권한 수준	ClusterRole	범위	설명
최상위	cluster-admin	클러스터	모든 리소스, 모든 네임스페이스, 모든 동작 가능. 사실상 루트 권한.
네임스페이스 관리 가능	admin	네임스페이스	네임스페이스 내 대부분의 리소스 관리 가능(배포, 서비스, 시크릿 등). RoleBinding 생성 가능. 단, 네임스페이스 외 리소스에는 권한 없음.
읽기/쓰기 제한	edit	네임스페이스	네임스페이스 내 대부분 리소스 생성/수정 가능. RoleBinding 생성은 불가.
읽기 전용	view	네임스페이스	리소스 조회 가능(get, list, watch). 생성/수정/삭제 불가.
시스템용 최소 권한	system:discovery	클러스터	API 리소스 조회 가능. (kubectl api-resources 등에서 사용)
시스템용 제한 권한	system:basic-user	네임스페이스	로그인한 사용자에게 기본 조회 권한 제공

 

 

RoleBinding 생성 → 네임스페이스 ns-infra 내 서비스 계정 infra-sa에 Pod 관리 권한 부여

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-manager-binding
  namespace: ns-infra
roleRef:
  kind: Role
  name: pod-manager                          # ClusterRole 이름
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: ServiceAccount                     # ServiceAccount 에 권한 부여
    name: infra-sa
    namespace: ns-infra                      # ServiceAccount는 namespace 명시 필요

 

+기본 ClusterRole을 사용하는 경우에는 ,roleRef.name에 ClusterRole 이름을 적으면 된다. (예: admin)

 

2. ClusterRole & ClusterRoleBinding

ClusterRole 생성 → 클러스터 전체에서 pods, services, nodes를 읽기 전용 권한 부여

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole                                 # 클러스터 전체 권한 정의
metadata:
  name: read-only-cluster
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "nodes"]
    verbs: ["get", "list", "watch"]                # 읽기 전용

 

 

ClusterRoleBinding 생성 → 1번에서 만든 ClusterRole을 특정 사용자에게 부여

 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding                            # 클러스터 전체 권한 부여
metadata:
  name: read-only-cluster-binding
roleRef:
  kind: ClusterRole
  name: read-only-cluster                            # ClusterRole 이름
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: User                                       # 사용자에게 권한 부여
    name: jane.doe@example.com
    apiGroup: rbac.authorization.k8s.io

 

테스트

배포 후 kubectl auth can-i 명령어로 특정 사용자/서비스 계정이 특정 리소스에 대해 특정 작업을 수행할 수 있는지 확인한다.

$ kubectl auth can-i <verb> <resource> [--namespace=<namespace>] [--as=<user>] [--list]

• <verb>: 수행할 동작
  • 예: get, list, watch, create, update, delete
• <resource>: 리소스 종류
  • 예: pods, deployments, configmaps
• --namespace: 네임스페이스 단위 권한 확인 시 지정
• --as: 다른 사용자/서비스 계정 권한으로 확인
• --list: 해당 사용자/서비스 계정이 수행할 수 있는 모든 작업을 출력

특정 네임스페이스에 대한 모든 권한을 확인하는 방법:

$ kubectl auth can-i --list --namespace=<네임스페이스>

 

결과 예시:

Resources           Non-Resource URLs     Resource Names     Verbs
-----               -----------------     --------------     -----
pods                []                    []                  [get list watch create delete]
deployments.apps    []                    []                  [get list watch create update patch delete]
configmaps          []                    []                  [get list watch create update delete]

 

컬럼	의미
Resources	권한이 적용되는 리소스 종류 (pods, deployments.apps 등)
Non-Resource URLs	API 서버 경로(URL) 권한. (예: /healthz, /metrics)
Resource Names	특정 리소스 이름에만 적용되는 권한. 비워두면 네임스페이스 내 모든 리소스 대상
Verbs	허용되는 동작. (예: get, list, watch, create, update, delete, patch, *(모든동작허용))