RBAC(Role-Based Access Control)

쿠버네티스에서 리소스들은 모두 네임스페이스(namespace) 단위로 구분되어 관리된다.
즉, 하나의 클러스터 안에서도 여러 팀이나 프로젝트가 겹치지 않게 독립된 공간을 사용하는 개념이다.

예를 들어

• dev1 팀은 자신들의 파드, 서비스, 디플로이먼트를 관리하고
• dev2 팀은 별도의 네임스페이스에서 독립적으로 동작할 수 있다.

이렇게 구분해두면 서로 다른 팀이 동일한 리소스 이름을 사용하더라도 충돌이 발생하지 않는다.

또한, RBAC(Role-Based Access Control) 을 통해
“누가 어떤 네임스페이스의 리소스에 접근할 수 있는가”를 세밀하게 통제할 수 있다.

기본 개념 정리

개념	설명
Role	특정 네임스페이스(namespace) 내에서 권한 정의
ClusterRole	클러스터 전체 리소스에 대한 권한 정의
RoleBinding	Role을 특정 사용자 또는 ServiceAccount에 연결
ClusterRoleBinding	ClusterRole을 특정 사용자 또는 ServiceAccount에 연결
ServiceAccount(SA)	Pod가 API 서버에 접근할 때 사용하는 계정

즉,

Role/ClusterRole → “무엇을 할 수 있는가”
RoleBinding/ClusterRoleBinding → “누가 그걸 할 수 있는가”

로 구분할 수 있다.

실제 예시를 들어 설명

사실 위 기본 내용을 봐도 쉽게 와닿지가 않았다. 용어들도 생소하고 계층구조가 어떻게 되어있는지 중간 중간 혼란이 와서 정리 할 필요성을 느꼈다. 따라서 챗지피티한테 도움을 받아 일상 속 예시를 들어 설명하고, 이해를 돕고자 한다.

쿠버네티스 클러스터 = 회사 본사

쿠버네티스 클러스터는 하나의 큰 회사 본사라고 보면 이해하기 쉽다.
이 안에는 여러 팀(부서) 들이 따로 나뉘어 있고,
각 팀은 자기 팀 리소스만 관리하는 것이다.

즉,

Cluster = 전체 회사,
Namespace = 팀(부서)

네임스페이스(NameSpace) = 팀(부서)

각 팀마다 자기만의 공간이 존재한다.
예를 들어,

• dev1팀 → 개발 1팀
• dev2팀 → 개발 2팀

이렇게 나눠놓으면 서로의 리소스가 섞이지 않는다.
예를 들어 dev1팀이 만든 “web-app”이랑 dev2팀이 만든 “web-app”은 이름이 같아도 충돌 나지 않는다.
왜냐면 서로 다른 네임스페이스 안에 있기 때문이다..

즉, 네임스페이스는 “리소스의 독립된 공간”이다.

RBAC(Role-Based Access Control) = 사내 권한 제도

이제 회사에서 직원마다 권한이 다르듯이,
쿠버네티스에서도 누가 뭘 할 수 있는지를 정해야 한다.
그걸 RBAC가 담당하는 것이다.

RBAC = Role-Based Access Control
→ “역할(Role)”에 따라 접근 권한을 제한하는 시스템

Role, RoleBinding, ClusterRole, ClusterRoleBinding = 권한 문서

이건 회사의 “권한 문서”라고 보면 된다.

개념	실제 비유	설명
Role	팀 내 권한	네임스페이스 안에서만 쓸 수 있는 권한 (예: dev1팀 안에서만 리소스 조회 가능)
ClusterRole	본사 관리자 권한	전체 회사(모든 팀)에 대한 권한 (예: 모든 팀 리소스 관리 가능)
RoleBinding	팀 권한을 직원에게 연결	특정 직원(ServiceAccount)에게 Role을 적용
ClusterRoleBinding	관리자 권한을 직원에게 연결	특정 직원(ServiceAccount)에게 ClusterRole을 적용

ServiceAccount = 직원

쿠버네티스 안에서 Pod(컨테이너)가 API 서버에 접근할 때 쓰는 “계정”이다.

즉, Pod = 직원이라면
ServiceAccount = 그 직원의 사번(ID카드)

구조 요약

[Cluster 전체 회사]
│
├── ClusterRole (pod-admin)
│     └── ClusterRoleBinding → sa-pod-admin 계정
│
├── Namespace: dev1
│     ├── Role: role-get-dev1
│     ├── RoleBinding → dev1-hoon 계정 연결
│     └── ServiceAccount: dev1-hoon (읽기 전용)
│
└── Namespace: dev2
      ├── Role: role-gct-dev2
      ├── RoleBinding → dev2-moon 계정 연결
      └── ServiceAccount: dev2-moon (생성 가능)

실습 흐름 정리

단계	내용	파일명
1	dev1, dev2 네임스페이스 및 서비스계정 생성	ns-sa-dev-both.yaml
2	각 네임스페이스별 Role(권한) 정의	role-get-dev1.yaml / role-gct-dev2.yaml
3	RoleBinding으로 Role과 계정 연결	rolebinding-dev1.yaml / rolebinding-dev2.yaml
4	클러스터 전체에 적용되는 ClusterRole 생성 및 바인딩	sa-pod-admin.yaml / clusterrole.yaml / clusterrolebinding.yaml

이 과정을 거치면

• dev1-hoon 계정은 조회만 가능한 사용자,
• dev2-moon 계정은 생성까지 가능한 사용자,
• sa-pod-admin 계정은 클러스터 전체 관리자로 동작하게 된다.

네임스페이스 및 실습 구조도

위 다이어그램은 이번 실습에서 구성한 쿠버네티스 RBAC 전체 구조를 시각적으로 표현한 것이다.

• dev1 네임스페이스

  • ServiceAccount: dev1-hoon
  • Role: role-get-dev1
  • RoleBinding: rolebinding-dev1
    → 읽기 전용(get, list) 권한만 부여된 사용자로, 리소스 조회만 가능하다.

• dev2 네임스페이스

  • ServiceAccount: dev2-moon
  • Role: role-gct-dev2
  • RoleBinding: rolebinding-dev2
    → 생성(create)까지 가능한 사용자로, dev1보다 한 단계 높은 권한을 가진다.

• 클러스터 전체 관리자 영역

  • ServiceAccount: sa-pod-admin
  • ClusterRole: pod-admin
  • ClusterRoleBinding: clusterrolebinding-pod-admin
    → 모든 네임스페이스를 포함한 클러스터 전역 권한을 가지며, 모든 리소스에 접근하고 제어할 수 있다.

즉, 정리하자면

• dev1 → 읽기 전용 Role 연결
• dev2 → 생성까지 가능한 Role 연결
• pod-admin → 클러스터 전체 관리자

1. 네임스페이스 & 서비스 계정 생성

먼저 dev1, dev2라는 네임스페이스와 각각의 서비스 계정을 만든다.

파일명 : ns-sa-dev-both.yaml

# dev1 namespace와 serviceaccount
apiVersion: v1
kind: Namespace
metadata:
  name: dev1
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev1-hoon
  namespace: dev1
---
# dev2 namespace와 serviceaccount
apiVersion: v1
kind: Namespace
metadata:
  name: dev2
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev2-moon
  namespace: dev2

적용 명령어
kubectl apply -f ns-sa-dev-both.yaml

적용하면 다음과 같이 네임스페이스와 서비스 어카운트가 생성되는 것을 확인할 수 있다.

생성 확인 명령어

bash
코드를 입력하세요

# 네임스페이스 목록 확인
kubectl get ns

# dev1 네임스페이스의 ServiceAccount 확인
kubectl get sa -n dev1

# dev2 네임스페이스의 ServiceAccount 확인
kubectl get sa -n dev2

이렇게 명령어를 통해 get 해보면 dev1, dev2 각각에 전용 ServiceAccount가 준비된 상태가 된 것을 확인할 수 있다.

2.Role 생성 - 각 네임스페이별 권한 정의

파일명 : role-get-dev1.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev1
  name: role-get-dev1
rules:
  - apiGroups: [""]
    resources: ["pods", "deployments"]
    verbs: ["get", "list"]

파일명 : role-gct-dev2.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev2
  name: role-gct-dev2
rules:
  - apiGroups: [""]
    resources: ["pods", "deployments"]
    verbs: ["get", "list", "create"]

이렇게 yaml파일 생성 및 적용하여 각 dev1, dev2에 권한을 정의하였다.

dev1은 조회만 가능(get, list)
dev2는 생성(create)까지 가능하도록 설정하였다.

3.RoleBinding — Role과 ServiceAccount 연결

이제 앞서 만든 Role을 각 ServiceAccount와 연결해야 한다.
이 과정을 통해 “어떤 계정이 어떤 권한을 사용할 수 있는가”를 정의하게 된다.

파일명 : rolebinding-dev1.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rolebinding-dev1
  namespace: dev1
subjects:
  - kind: ServiceAccount
    name: dev1-hoon
    namespace: dev1
roleRef:
  kind: Role
  name: role-get-dev1
  apiGroup: rbac.authorization.k8s.io

파일명 : rolebinding-dev2.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rolebinding-dev2
  namespace: dev2
subjects:
  - kind: ServiceAccount
    name: dev2-moon
    namespace: dev2
roleRef:
  kind: Role
  name: role-gct-dev2
  apiGroup: rbac.authorization.k8s.io

roleBinding 확인 명령어

kubectl get rolebinding -n dev1
kubectl get rolebinding -n dev2

이렇게 나오면 각 네임스페이스의 서비스계정(dev1-hoon, dev2-moon)에 Role이 정상적으로 연결된 것이다.
즉, 이제 dev1-hoon은 읽기(get, list)만 가능하고, dev2-moon은 읽기 및 생성(create) 권한까지 가지게 된다.

4.ClusterRole과 ClusterRoleBinding

지금까지는 네임스페이스 단위(Role) 로 권한을 부여했다면,
이번에는 클러스터 전체(ClusterRole) 에 권한을 부여하는 방법이다.
즉, 클러스터 안의 모든 네임스페이스에 대해 접근할 수 있는 관리자(admin) 계정을 만드는 것이다.

파일명 : sa-pod-admin.yaml

# 1. 서비스 계정 생성
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-pod-admin

파일명 : clusterrole.yaml

# 2. 클러스터 전체 권한 정의
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-admin
rules:
  - apiGroups: ["*"]
    resources: ["pods", "deployments", "deployments/scale"]
    verbs: ["*"]

파일명 clusterrolebinding.yaml

# 3. 서비스 계정과 권한 연결
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: clusterrolebinding-pod-admin
subjects:
  - kind: ServiceAccount
    name: sa-pod-admin
    namespace: default
roleRef:
  kind: ClusterRole
  name: pod-admin
  apiGroup: rbac.authorization.k8s.io

이렇게 적용을 하였으며 성공적으로 적용된 것을 확인할 수 있다.

생성 및 바인딩 확인

# 서비스계정 확인
kubectl get sa | grep sa-pod-admin

# 클러스터롤 확인
kubectl get clusterrole pod-admin

# 클러스터롤바인딩 확인
kubectl get clusterrolebinding clusterrolebinding-pod-admin

이렇게 세 가지가 모두 정상적으로 조회되면
클러스터 전체에 대한 관리자 권한(ClusterRole) 이
sa-pod-admin 서비스 계정에 바인딩된 상태가 된다.

이 계정을 이용하면 다른 네임스페이스의 리소스도 전부 접근 및 제어 가능하며,
RBAC 구조의 최상위 권한 계정이라 보면 된다.

실습 정리

구분	리소스	역할
dev1	Role(get, list)	읽기 전용
dev2	Role(get, list, create)	생성까지 가능
pod-admin	ClusterRole(*)	클러스터 전체 관리자

참고자료 :
[쿠버네티스 공식 홈페이지 - Using RBAC Authorization]
https://kubernetes.io/docs/reference/access-authn-authz/rbac/?utm_source=chatgpt.com