Kubernetes RBAC란 무엇인가: Role, ClusterRole, Binding으로 권한 설계하기

Kubernetes RBAC(Role-Based Access Control)는 "누가, 어떤 리소스에, 어떤 작업을 할 수 있는가"를 정의하는 권한 제어 시스템입니다. 클러스터 내 모든 API 요청은 RBAC 정책을 통과해야 실행됩니다.

핵심 요약

RBAC는 Kubernetes API Server의 인가(Authorization) 단계에서 동작합니다. 인증(Authentication)을 통과한 요청이 허용된 작업인지 판단합니다.
4개의 핵심 오브젝트로 구성됩니다: Role, ClusterRole, RoleBinding, ClusterRoleBinding.
Role은 "무엇을 할 수 있는가"를 정의하고, Binding은 "누구에게 부여할 것인가"를 연결합니다.
네임스페이스 범위(Role/RoleBinding)와 클러스터 범위(ClusterRole/ClusterRoleBinding)를 구분하여 설계합니다.
기본 원칙은 최소 권한(Least Privilege)입니다. 필요한 권한만 명시적으로 부여하고, 거부(Deny) 규칙은 없습니다.

1. 왜 RBAC가 필요한가

개발팀 5명이 하나의 Kubernetes 클러스터를 공유합니다. 모든 사람이 cluster-admin 권한을 갖고 있다면 어떤 일이 벌어질까요?

개발자가 실수로 kubectl delete namespace production을 실행합니다. 프로덕션 서비스가 전부 사라집니다.
인턴이 kube-system 네임스페이스의 CoreDNS 설정을 변경합니다. 클러스터 전체의 DNS가 깨집니다.
누군가 Secret을 조회해서 데이터베이스 비밀번호를 외부에 공유합니다. 감사 로그를 봐도 누가 했는지 구분이 안 됩니다.

이런 상황을 방지하려면 "각 사용자가 자신의 업무에 필요한 권한만 갖도록" 제어해야 합니다. 이것이 RBAC의 목적입니다.

문제	RBAC로 해결하는 방식
실수로 다른 팀 리소스 삭제	네임스페이스별로 접근 범위를 제한
시스템 컴포넌트 무단 변경	kube-system 접근 권한을 관리자에게만 부여
Secret 무단 조회	Secret 읽기 권한을 필요한 서비스 계정에만 부여
책임 추적 불가	개별 계정에 개별 권한을 부여하여 감사 가능
CI/CD 파이프라인의 과도한 권한	배포에 필요한 최소 권한만 서비스 계정에 부여

2. RBAC의 위치: API 요청 처리 흐름

kubectl get pods를 실행하면 API Server 내부에서 3단계 검증이 순서대로 실행됩니다.

단계	역할	실패 시
1. Authentication (인증)	"이 요청을 보낸 사람이 누구인가?" — 인증서, 토큰, OIDC 등으로 신원 확인	401 Unauthorized
2. Authorization (인가)	"이 사람이 이 작업을 할 수 있는가?" — RBAC가 여기서 동작	403 Forbidden
3. Admission Control	"이 요청이 정책을 충족하는가?" — 리소스 제한, 보안 정책 등 검증	요청 거부 또는 변형

RBAC는 2단계에서 동작합니다. 인증을 통과한 요청에 대해 "이 주체(Subject)가 이 리소스(Resource)에 이 동작(Verb)을 수행할 권한이 있는가?"를 판단합니다.

중요한 특성: RBAC는 허용(Allow) 기반입니다. 명시적으로 허용된 작업만 가능하고, 거부(Deny) 규칙은 존재하지 않습니다. 권한이 부여되지 않은 모든 작업은 기본적으로 거부됩니다.

3. RBAC 핵심 구성 요소

RBAC는 4개의 Kubernetes 오브젝트로 구성됩니다. "무엇을 할 수 있는가"를 정의하는 Role 계열과, "누구에게 부여하는가"를 연결하는 Binding 계열로 나뉩니다.

오브젝트	범위	역할
Role	네임스페이스	특정 네임스페이스 내 리소스에 대한 권한 정의
ClusterRole	클러스터 전체	클러스터 범위 리소스 또는 모든 네임스페이스에 대한 권한 정의
RoleBinding	네임스페이스	Role 또는 ClusterRole을 특정 네임스페이스의 주체에 연결
ClusterRoleBinding	클러스터 전체	ClusterRole을 클러스터 전체 범위로 주체에 연결

3.1 Role: 네임스페이스 범위 권한 정의

Role은 특정 네임스페이스 안에서 "어떤 리소스에 어떤 동작을 허용하는가"를 정의합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team
  name: pod-reader
rules:
- apiGroups: [""]          # core API group (Pod, Service, ConfigMap 등)
  resources: ["pods"]       # 대상 리소스
  verbs: ["get", "list", "watch"]  # 허용할 동작

rules 필드 구성:

필드	설명	예시
apiGroups	API 그룹. `""`은 core group	`""`, `"apps"`, `"batch"`
resources	대상 리소스 종류	`"pods"`, `"deployments"`, `"secrets"`
verbs	허용할 동작	`"get"`, `"list"`, `"create"`, `"update"`, `"delete"`
resourceNames	특정 리소스 이름으로 제한 (선택)	`["my-config"]`

사용 가능한 Verbs:

Verb	설명	kubectl 대응
get	단일 리소스 조회	`kubectl get pod <name>`
list	리소스 목록 조회	`kubectl get pods`
watch	리소스 변경 감시	`kubectl get pods --watch`
create	리소스 생성	`kubectl create`, `kubectl apply` (신규)
update	리소스 수정	`kubectl apply` (기존), `kubectl edit`
patch	리소스 부분 수정	`kubectl patch`
delete	리소스 삭제	`kubectl delete`
deletecollection	리소스 일괄 삭제	`kubectl delete pods --all`

3.2 ClusterRole: 클러스터 범위 권한 정의

ClusterRole은 두 가지 용도로 사용됩니다:

클러스터 범위 리소스에 대한 권한: Node, PersistentVolume, Namespace 등 네임스페이스에 속하지 않는 리소스
모든 네임스페이스에 걸친 권한: RoleBinding으로 특정 네임스페이스에 바인딩하면 해당 네임스페이스에서만 적용

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["persistentvolumes"]
  verbs: ["get", "list"]

3.3 RoleBinding: 네임스페이스 범위 권한 연결

RoleBinding은 Role(또는 ClusterRole)을 특정 주체(Subject)에 연결합니다. 연결 대상은 User, Group, ServiceAccount 중 하나입니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: dev-team
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

이 RoleBinding은 "jane 사용자에게 dev-team 네임스페이스에서 pod-reader Role의 권한을 부여한다"는 의미입니다.

ClusterRole을 RoleBinding으로 연결하는 패턴:

ClusterRole을 RoleBinding으로 바인딩하면, 해당 ClusterRole의 권한이 RoleBinding이 속한 네임스페이스에서만 적용됩니다. 이 패턴은 공통 권한 세트를 여러 네임스페이스에 재사용할 때 유용합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-view-binding
  namespace: dev-team
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole      # ClusterRole을 참조하지만
  name: view             # 이 RoleBinding의 네임스페이스(dev-team)에서만 적용
  apiGroup: rbac.authorization.k8s.io

3.4 ClusterRoleBinding: 클러스터 전체 권한 연결

ClusterRoleBinding은 ClusterRole을 클러스터 전체 범위로 주체에 연결합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: User
  name: admin-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

주의
ClusterRoleBinding은 클러스터 전체에 권한을 부여합니다. cluster-admin ClusterRole을 ClusterRoleBinding으로 연결하면 모든 네임스페이스의 모든 리소스에 대한 전체 권한이 부여됩니다. 운영 환경에서는 이 바인딩을 최소한의 관리자에게만 부여해야 합니다.

3.5 Subject: 권한을 받는 주체

Subject 종류	설명	사용 시나리오
User	외부 인증 시스템에서 관리되는 사용자	개발자, 운영자의 kubectl 접근
Group	사용자 그룹	팀 단위 권한 부여 (developers, ops-team)
ServiceAccount	클러스터 내부에서 Pod가 사용하는 계정	CI/CD 파이프라인, 컨트롤러, 애플리케이션

Kubernetes는 User와 Group을 직접 관리하지 않습니다. 외부 인증 시스템(OIDC, 인증서 CN/O 필드, AWS IAM 등)에서 제공하는 정보를 사용합니다. 반면 ServiceAccount는 Kubernetes가 직접 관리하는 오브젝트입니다.

4. Role vs ClusterRole, RoleBinding vs ClusterRoleBinding 선택 기준

어떤 조합을 사용할지는 "권한의 범위"와 "적용 대상"에 따라 결정됩니다.

시나리오	사용할 조합	이유
개발자가 자기 네임스페이스의 Pod만 조회	Role + RoleBinding	네임스페이스 범위로 충분
개발자가 여러 네임스페이스에서 동일 권한 필요	ClusterRole + 각 네임스페이스에 RoleBinding	ClusterRole을 재사용하되 범위는 제한
운영자가 모든 네임스페이스의 Pod를 조회	ClusterRole + ClusterRoleBinding	클러스터 전체 범위 필요
Node, PV 등 클러스터 리소스 관리	ClusterRole + ClusterRoleBinding	네임스페이스에 속하지 않는 리소스
특정 네임스페이스에서만 Deployment 배포	Role + RoleBinding	배포 범위를 제한

설계 원칙:

가능한 한 좁은 범위를 선택합니다. ClusterRoleBinding보다 RoleBinding을 우선 검토합니다.
공통 권한은 ClusterRole로 정의하고 RoleBinding으로 재사용합니다. Role을 네임스페이스마다 중복 생성하는 것보다 관리가 쉽습니다.
ClusterRoleBinding은 정말 클러스터 전체 접근이 필요한 경우에만 사용합니다. 모니터링 시스템, 클러스터 관리자 등 제한된 용도입니다.

5. 기본 제공 ClusterRole

Kubernetes는 설치 시 자주 사용되는 권한 세트를 기본 ClusterRole로 제공합니다. 직접 Role을 만들기 전에 이 기본 역할이 요구사항에 맞는지 먼저 확인하는 것이 좋습니다.

ClusterRole	권한 범위	용도
`cluster-admin`	모든 리소스에 대한 모든 동작	클러스터 최고 관리자
`admin`	네임스페이스 내 대부분의 리소스 관리 (RBAC, ResourceQuota 제외)	네임스페이스 관리자
`edit`	네임스페이스 내 리소스 생성/수정/삭제 (Role, RoleBinding 제외)	개발자 (배포 권한 필요)
`view`	네임스페이스 내 리소스 읽기 전용 (Secret 제외)	읽기 전용 접근

# 기본 제공 ClusterRole 목록 확인
kubectl get clusterroles | grep -v "system:"

# 특정 ClusterRole의 권한 상세 확인
kubectl describe clusterrole edit

Tip
view ClusterRole은 Secret 읽기 권한을 포함하지 않습니다. Secret에 접근해야 하는 경우 별도 Role을 추가로 바인딩해야 합니다. 이는 의도적인 설계로, 읽기 전용 사용자가 민감 정보에 접근하는 것을 방지합니다.

6. 실무 시나리오: 팀별 네임스페이스 권한 분리

시나리오

스타트업에서 하나의 EKS 클러스터를 백엔드 팀과 프론트엔드 팀이 공유합니다. 각 팀은 자기 네임스페이스에서만 작업해야 하고, 다른 팀의 리소스를 변경할 수 없어야 합니다. 운영팀은 모든 네임스페이스를 모니터링할 수 있어야 합니다.

요구사항

주체	권한	범위
backend-team 그룹	Pod, Deployment, Service, ConfigMap CRUD	backend 네임스페이스만
frontend-team 그룹	Pod, Deployment, Service, ConfigMap CRUD	frontend 네임스페이스만
ops-team 그룹	모든 리소스 읽기	모든 네임스페이스
deploy-bot (ServiceAccount)	Deployment 업데이트만	backend 네임스페이스만

구현

1단계: 네임스페이스 생성

kubectl create namespace backend
kubectl create namespace frontend

2단계: 백엔드 팀 권한 설정

# backend-developer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: backend
  name: backend-developer
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["pods/log", "pods/exec"]
  verbs: ["get", "create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: backend-developer-binding
  namespace: backend
subjects:
- kind: Group
  name: backend-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: backend-developer
  apiGroup: rbac.authorization.k8s.io

3단계: 운영팀 — 클러스터 전체 읽기 권한

# ops-viewer-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ops-viewer-binding
subjects:
- kind: Group
  name: ops-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view              # 기본 제공 ClusterRole 재사용
  apiGroup: rbac.authorization.k8s.io

4단계: CI/CD 서비스 계정 — 최소 권한 배포

# deploy-bot-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: deploy-bot
  namespace: backend
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: backend
  name: deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "patch", "update"]
- apiGroups: ["apps"]
  resources: ["replicasets"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: deploy-bot-binding
  namespace: backend
subjects:
- kind: ServiceAccount
  name: deploy-bot
  namespace: backend
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

설계 의사결정

결정	이유	대안
팀별 Role을 직접 정의	기본 `edit` ClusterRole은 Secret 접근을 포함하므로 범위가 넓음	`edit`을 사용하되 Secret은 별도 정책으로 제한
운영팀에 기본 `view` ClusterRole 사용	읽기 전용이면 충분하고, Secret 접근이 제외되어 안전	커스텀 ClusterRole 생성 (관리 부담 증가)
deploy-bot에 Deployment patch/update만 부여	CI/CD는 이미지 태그 변경만 하면 되므로 create/delete 불필요	`edit` Role 부여 (과도한 권한)

7. ServiceAccount와 RBAC

ServiceAccount는 Pod 내부에서 실행되는 애플리케이션이 Kubernetes API에 접근할 때 사용하는 신원(Identity)입니다. 사람이 아닌 워크로드에 권한을 부여할 때 사용합니다.

기본 동작

모든 네임스페이스에는 default ServiceAccount가 자동 생성됩니다.
Pod를 생성할 때 ServiceAccount를 지정하지 않으면 default가 자동 할당됩니다.
Kubernetes 1.24부터 ServiceAccount에 자동으로 영구 토큰이 생성되지 않습니다. 대신 TokenRequest API를 통해 시간 제한이 있는 토큰이 발급됩니다.

실무 권장 사항

# Pod에서 ServiceAccount 지정
apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: backend
spec:
  serviceAccountName: my-app-sa    # 명시적으로 지정
  automountServiceAccountToken: false  # API 접근이 불필요하면 토큰 마운트 비활성화
  containers:
  - name: app
    image: my-app:1.0

원칙	설명
Pod마다 전용 ServiceAccount 사용	default SA를 공유하면 권한 분리가 불가능
불필요한 토큰 마운트 비활성화	API 접근이 필요 없는 Pod는 `automountServiceAccountToken: false` 설정
최소 권한 Role 바인딩	ServiceAccount에 필요한 최소한의 권한만 부여
네임스페이스 격리	ServiceAccount는 네임스페이스에 속하므로 교차 네임스페이스 접근을 제한

Security Note
default ServiceAccount에 권한을 부여하면 해당 네임스페이스의 모든 Pod가 그 권한을 갖게 됩니다. 운영 환경에서는 default SA에 추가 권한을 부여하지 않고, 각 워크로드에 전용 ServiceAccount를 생성하는 것이 안전합니다.

8. RBAC 권한 확인과 디버깅

kubectl auth can-i

현재 사용자 또는 특정 ServiceAccount의 권한을 확인하는 명령어입니다.

# 현재 사용자가 default 네임스페이스에서 Pod를 생성할 수 있는지 확인
kubectl auth can-i create pods
# yes

# 특정 네임스페이스에서 확인
kubectl auth can-i delete deployments -n production
# no

# 특정 ServiceAccount의 권한 확인 (--as 플래그)
kubectl auth can-i get pods -n backend \
  --as=system:serviceaccount:backend:deploy-bot
# yes

# 현재 사용자의 모든 권한 나열
kubectl auth can-i --list -n backend

403 Forbidden 디버깅 흐름

API 요청이 거부되었을 때 원인을 찾는 순서입니다.

# 1. 에러 메시지 확인
kubectl get pods -n production
# Error from server (Forbidden): pods is forbidden: User "jane" cannot list
# resource "pods" in API group "" in the namespace "production"

# 2. 해당 사용자의 RoleBinding 확인
kubectl get rolebindings -n production -o wide
kubectl get clusterrolebindings -o wide | grep jane

# 3. 바인딩된 Role의 규칙 확인
kubectl describe role <role-name> -n production
kubectl describe clusterrole <clusterrole-name>

# 4. 권한 테스트
kubectl auth can-i list pods -n production --as=jane

Tip
403 에러 메시지에는 "누가(User), 무엇을(verb + resource), 어디서(namespace)" 실패했는지가 명시됩니다. 이 정보를 기반으로 누락된 RoleBinding이나 Role 규칙을 찾을 수 있습니다.

9. 매니지드 Kubernetes에서의 RBAC

EKS, AKS, GKE 같은 매니지드 환경에서는 클라우드 IAM과 Kubernetes RBAC가 함께 동작합니다. 클라우드 IAM이 "클러스터에 접근할 수 있는가"를 제어하고, Kubernetes RBAC가 "클러스터 안에서 무엇을 할 수 있는가"를 제어합니다.

플랫폼	인증 방식	IAM → K8s 매핑
EKS	AWS IAM + aws-auth ConfigMap 또는 EKS Access Entry	IAM Role/User → K8s User/Group
AKS	Azure AD (Entra ID) 통합	Azure AD Group → K8s Group
GKE	Google Cloud IAM	IAM 계정 → K8s User

EKS 예시: IAM Role을 Kubernetes 그룹에 매핑

# aws-auth ConfigMap (EKS)
apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::123456789012:role/BackendDeveloper
      username: backend-dev
      groups:
        - backend-team    # 이 그룹에 RoleBinding을 연결
    - rolearn: arn:aws:iam::123456789012:role/OpsEngineer
      username: ops-eng
      groups:
        - ops-team

이 설정으로 AWS IAM Role BackendDeveloper를 가진 사용자가 kubectl을 실행하면, Kubernetes 내부에서는 backend-team 그룹으로 인식됩니다. 앞서 설정한 RoleBinding이 이 그룹에 권한을 부여합니다.

주의
EKS에서 aws-auth ConfigMap을 잘못 수정하면 클러스터 접근이 완전히 차단될 수 있습니다. 수정 전에 반드시 클러스터 생성자(기본 관리자)의 접근이 유지되는지 확인해야 합니다. EKS Access Entry(신규 방식)를 사용하면 이 위험을 줄일 수 있습니다.

10. 보안 고려사항

Security Note
RBAC는 Kubernetes 보안의 핵심 계층입니다. 잘못된 RBAC 설계는 권한 상승(Privilege Escalation), 데이터 유출, 클러스터 전체 장악으로 이어질 수 있습니다.

위험한 권한 조합

권한	위험	완화 방법
Secret에 대한 get/list	데이터베이스 비밀번호, API 키 노출	필요한 ServiceAccount에만 부여, 감사 로그 활성화
Pod에 대한 create + 임의 ServiceAccount 지정	다른 SA의 권한을 탈취할 수 있음	PodSecurity Admission으로 SA 지정 제한
pods/exec 권한	실행 중인 컨테이너에 셸 접근 가능	프로덕션에서는 제한, 감사 로그 필수
escalate, bind verb	자신보다 높은 권한의 Role을 생성/바인딩 가능	클러스터 관리자에게만 부여
wildcard (*) 사용	향후 추가되는 리소스/동작에도 자동 적용	명시적으로 필요한 리소스와 verb만 나열

RBAC 보안 체크리스트

# 1. cluster-admin 바인딩 확인 — 최소한이어야 함
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

# 2. 모든 네임스페이스에서 Secret 접근 가능한 주체 확인
kubectl auth can-i get secrets --all-namespaces --as=system:serviceaccount:default:default

# 3. wildcard 권한을 가진 Role 확인
kubectl get roles,clusterroles -A -o json | \
  jq '.items[] | select(.rules[]?.verbs[]? == "*") | .metadata.name'

최소 권한 설계 원칙

필요한 verb만 부여합니다. 읽기만 필요하면 get, list, watch만 부여합니다.
리소스를 명시합니다. resources: ["*"] 대신 구체적인 리소스 이름을 나열합니다.
resourceNames로 범위를 좁힙니다. 특정 ConfigMap만 읽어야 한다면 이름을 지정합니다.
정기적으로 권한을 감사합니다. 사용하지 않는 RoleBinding은 제거합니다.
ServiceAccount 토큰 마운트를 제한합니다. API 접근이 불필요한 Pod는 토큰을 마운트하지 않습니다.

11. 자주 하는 실수

1. default ServiceAccount에 권한을 부여

default SA에 권한을 부여하면 해당 네임스페이스의 모든 Pod가 그 권한을 갖습니다. 의도하지 않은 워크로드가 API에 접근할 수 있습니다.

해결: 각 워크로드에 전용 ServiceAccount를 생성하고, 해당 SA에만 필요한 권한을 부여합니다.

2. ClusterRoleBinding을 남용

"편하니까" ClusterRoleBinding으로 모든 권한을 부여하면, 한 네임스페이스에서만 작업해야 하는 사용자가 다른 네임스페이스의 리소스까지 접근할 수 있습니다.

해결: 네임스페이스 범위로 충분한 경우 RoleBinding을 사용합니다.

3. RoleBinding 수정 후 roleRef 변경 시도

RoleBinding의 roleRef 필드는 생성 후 변경할 수 없습니다(immutable). 다른 Role을 참조하려면 기존 RoleBinding을 삭제하고 새로 생성해야 합니다.

# roleRef 변경 시도 → 에러 발생
# Error: roleRef cannot be updated

# 해결: 삭제 후 재생성
kubectl delete rolebinding old-binding -n dev-team
kubectl apply -f new-binding.yaml

4. API Group을 잘못 지정

Pod, Service, ConfigMap은 core API group("")에 속하고, Deployment는 apps group에 속합니다. API group을 잘못 지정하면 권한이 적용되지 않습니다.

# 리소스의 API group 확인
kubectl api-resources | grep deployment
# deployments    deploy    apps/v1    true    Deployment

5. 권한 변경 후 즉시 반영을 기대

RBAC 변경은 즉시 반영됩니다. 캐시 지연이 없습니다. 권한 변경 후에도 403이 발생한다면 RoleBinding의 subjects나 roleRef가 올바른지 다시 확인해야 합니다.

12. 비용/운영 고려사항

RBAC 자체는 추가 비용이 발생하지 않습니다. 다만 RBAC 설계와 운영에는 관리 비용이 있습니다.

항목	고려사항
초기 설계 비용	팀 구조, 네임스페이스 전략, 권한 매트릭스를 사전에 설계해야 함
관리 복잡도	팀이 늘어날수록 Role/Binding 수가 증가. GitOps로 YAML 관리 권장
감사 비용	API Server 감사 로그(Audit Log) 활성화 시 스토리지 비용 발생
도구 비용	RBAC 시각화/관리 도구(rbac-lookup, Kubernetes Dashboard 등) 도입 검토

운영 팁

전략	설명
RBAC YAML을 Git으로 관리	변경 이력 추적, PR 리뷰로 권한 변경 통제
네임스페이스 = 팀/서비스 단위	권한 경계를 명확하게 설정
기본 ClusterRole 우선 활용	`view`, `edit`, `admin`으로 충분한 경우 커스텀 Role 생성 불필요
정기 감사 자동화	`kubectl auth can-i --list`를 스크립트로 주기적 실행
Aggregated ClusterRole 활용	라벨 기반으로 ClusterRole을 자동 병합하여 관리 부담 감소

13. 정리

RBAC는 Kubernetes API Server의 인가 단계에서 "누가, 무엇을, 어디서 할 수 있는가"를 제어합니다.
4개 오브젝트(Role, ClusterRole, RoleBinding, ClusterRoleBinding)의 조합으로 권한을 설계합니다.
기본 원칙은 최소 권한입니다. 허용 기반(Allow-only)이므로 명시적으로 부여하지 않은 권한은 모두 거부됩니다.
네임스페이스 범위(Role + RoleBinding)를 우선 사용하고, 클러스터 전체 접근이 필요한 경우에만 ClusterRoleBinding을 사용합니다.
매니지드 Kubernetes에서는 클라우드 IAM과 RBAC가 함께 동작합니다. IAM이 클러스터 접근을, RBAC가 클러스터 내부 권한을 제어합니다.
ServiceAccount에는 전용 계정을 생성하고, 불필요한 토큰 마운트를 비활성화하는 것이 보안 기본입니다.

참고 문서

'Kubernetes' 카테고리의 다른 글

Kubernetes HPA가 동작하지 않는 이유 (0)	2026.06.07
EKS vs AKS vs GKE: 매니지드 Kubernetes 비교 (0)	2026.06.06
Kubernetes Service 종류: ClusterIP, NodePort, LoadBalancer, Ingress 비교 (0)	2026.05.31
Kubernetes 아키텍처 기본 구조: Control Plane과 Worker Node (0)	2026.05.31