RBAC

RBAC 란,
"누가", "무엇을", "어디서" 할 수 있는지 설정하는 제어 시스템

쿠버네티스 RBAC

쿠버네티스(Kubernetes)에서 보안은 매우 중요한 요소입니다. 특히 여러 팀이 같은 클러스터를 사용하는 환경에서는 적절한 접근 제어가 필수적입니다. 이를 위해 쿠버네티스는 RBAC(Role-Based Access Control)을 제공하여 사용자와 서비스 계정에 대한 세밀한 권한 관리를 가능하게 합니다.

 

• Role + RoleBinding → 네임스페이스 범위 권한
• ClusterRole + ClusterRoleBinding → 클러스터 전역 권한
• ClusterRole + RoleBinding → 네임스페이스에서 클러스터 역할 재사용 가능

 

쿠버네티스 접근 제어 체계

쿠버네티스의 접근 제어 체계는 크게 세 단계로 나뉩니다:

1. Authentication(인증): 사용자의 신분을 확인하는 단계 (신분증 확인)
2. Authorization(권한 부여): 인증된 사용자가 어떤 권한을 가지고 어떤 행동을 할 수 있는지 확인하는 단계
3. Admission Control(승인 제어): 인증과 권한 확인 이후 추가적인 요청 내용 검증 또는 요청 내용 강제 변경

이 중에서 Authorization을 담당하는 대표적인 메커니즘이 바로 RBAC입니다. RBAC는 누가(주체), 무엇을(동사), 어디에(네임스페이스) 실행할 수 있는지 결정하는 권한 또는 템플릿 집합을 수반하는 액세스 관리 형식입니다.

RBAC 개념 이해하기

쿠버네티스의 RBAC(Role-Based Access Control)은 역할(Role) 기반으로 쿠버네티스 시스템의 권한을 관리합니다. 특정 사용자(User)와 역할(Role) 두 가지를 조합하여 사용자에게 특정 권한을 부여할 수 있습니다.

RBAC의 핵심 구성 요소

쿠버네티스 RBAC 시스템은 다음과 같은 주요 구성 요소로 이루어져 있습니다:

1. Role: 특정 네임스페이스 내에서의 권한 규칙 집합
2. RoleBinding: Role과 사용자(User, Group, ServiceAccount)를 연결
3. ClusterRole: 클러스터 전체에 대한 권한 규칙 집합
4. ClusterRoleBinding: ClusterRole과 사용자를 연결

Role과 RoleBinding

Role은 특정 API, 리소스(Pod, Deployment 등), 사용 권한(get, list 등)을 매니페스트 파일에 명시해둔 규칙의 집합이며, 특정 네임스페이스에 대한 권한을 관리합니다.

RoleBinding은 Role과 특정 사용자를 묶어주는 역할을 수행합니다. 지정한 사용자들에 한해서 Role에 명시한 규칙들을 기준으로 권한을 사용할 수 있도록 관리합니다.

예를 들어, 개발팀에게는 개발 전용 네임스페이스를 따로 만들어주고, 개발 전용 네임스페이스만 컨트롤할 수 있는 계정을 부여하거나, 특정 네임스페이스에서 조회(get)만 가능한 계정을 부여하는 것이 가능합니다.

ClusterRole과 ClusterRoleBinding

ClusterRole은 namespace 단위가 아닌 클러스터 단위의 권한을 정의할 때 사용합니다. 즉, 사용할 리소스가 네임스페이스에 속하는 리소스인지 아닌지에 따라 Role 또는 ClusterRole을 선택하게 됩니다.

ClusterRoleBinding은 ClusterRole을 사용자와 연결하며, 한 클러스터에 있는 모든 네임스페이스에 ClusterRole을 적용합니다.

예를 들어, 'cluster-admin'이라는 ClusterRole은 모든 리소스에 대해 모든 동작이 가능한 권한을 가지고 있습니다.

동작 방식 이해하기

쿠버네티스는 리소스 조작을 API Server에 집약시키고 있으며, API Server는 REST 형식으로 요청을 받습니다. URL로 리소스를 표현하고 HTTP 메서드로 조작을 합니다.

쿠버네티스의 RBAC에서는 조작을 'Verb'라고 부릅니다. 아래 표는 HTTP 메서드와 Verb의 관계를 보여줍니다:

HTTP Method	Verb	Verb(컬렉션)
GET, HEAD	get(watch)	list(watch)
POST	create	-
PUT	update	-
PATCH	patch	-
DELETE	delete	deletecollection

---

RBAC 실습

1. 실습 환경 준비

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

# 테스트용 네임스페이스 생성
kubectl create namespace dev

# 서비스 계정 생성
kubectl create serviceaccount dev-user -n dev

1-2. default, dev 각 ns 별 pod 생성

kubectl run test-default-ns --image nginx
kubectl run rbac-test-pod --image nginx -n dev

---

2. Role + RoleBinding

dev-user 가 dev ns 에서만 pods 조회 가능

2-1. role 생성

# role-pod-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

2-2. rolebinding 생성

# rolebinding-pod-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: dev
subjects:
- kind: ServiceAccount
  name: dev-user
  namespace: dev
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

2-3. 배포

kubectl apply -f role-pod-reader.yaml
kubectl apply -f rolebinding-pod-reader.yaml

2-4. sa 토큰 수동 생성

kubectl -n dev create token dev-user

2-5. 생성된 토큰으로 API 테스트

curl -H "Authorization: Bearer <토큰>" --cacert /etc/kubernetes/pki/ca.crt https://<API_SERVER>:6443/api/v1/namespaces/dev/pods

---

3. clusterrole + clusterrolebinding

dev-user 가 모든 ns 에서 pods 조회

3-1. clusterrole 생성

# clusterrole-pod-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

3-2. clusterrolebinding 생성

# clusterrolebinding-pod-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-pod-reader-binding
subjects:
- kind: ServiceAccount
  name: dev-user
  namespace: dev
roleRef:
  kind: ClusterRole
  name: cluster-pod-reader
  apiGroup: rbac.authorization.k8s.io

3-3. 배포

kubectl apply -f clusterrole-pod-reader.yaml
kubectl apply -f clusterrolebinding-pod-reader.yaml

3-4. sa 토큰 발급

kubectl -n dev create token dev-user

3-5. API 서버에 접근하여 파드 조회

curl -k \
  -H "Authorization: Bearer <복사한-토큰>" \
  https://<API_SERVER>:6443/api/v1/pods

---

4. clusterrole + rolebinding

dev-user 가 특정 네임스페이스(dev) 에서만 pods 를 조회

4-1. clusterrole 은 앞에서 사용한 cluster-pod-reader 그래도 사용

4-2. rolebinding 생성

# rolebinding-to-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-only-access
  namespace: dev
subjects:
- kind: ServiceAccount
  name: dev-user
  namespace: dev
roleRef:
  kind: ClusterRole
  name: cluster-pod-reader
  apiGroup: rbac.authorization.k8s.io

4-3. 배포

kubectl apply -f rolebinding-to-clusterrole.yaml

4-4. sa 토큰 발급

kubectl -n dev create token dev-user

4-5. dev ns 에서만 pods 조회

curl -k \
  -H "Authorization: Bearer <토큰>" \
  https://<API_SERVER>:6443/api/v1/namespaces/dev/pods

4-6. 다른 ns 접근 시도

curl -k \
  -H "Authorization: Bearer <토큰>" \
  https://<API_SERVER>:6443/api/v1/namespaces/kube-system/pods

---

주요 차이점 이해하기

Role과 ClusterRole의 주요 차이점은 다음과 같습니다:

1. 범위:
   • Role은 특정 네임스페이스 내에서만 적용됩니다.
   • ClusterRole은 클러스터 전체에 적용됩니다.
2. 사용 사례:
   • Role은 네임스페이스 범위의 리소스(Pod, Service 등)에 대한 권한을 관리할 때 사용합니다.
   • ClusterRole은 네임스페이스에 속하지 않는 리소스(Node, PersistentVolume 등) 또는 모든 네임스페이스에 걸친 리소스에 대한 권한을 관리할 때 사용합니다.
3. 바인딩:
   • Role은 RoleBinding을 통해 특정 네임스페이스 내에서만 사용자와 연결됩니다.
   • ClusterRole은 ClusterRoleBinding을 통해 클러스터 전체에서 사용자와 연결되지만, RoleBinding을 통해 특정 네임스페이스 내에서도 사용할 수 있습니다.
4. 재사용성:
   • ClusterRole은 여러 네임스페이스에서 재사용할 수 있어, 관리가 용이합니다.

---

고급 RBAC 패턴 및 모범 사례

RBAC를 효과적으로 사용하기 위한 몇 가지 모범 사례를 살펴보겠습니다:

1. 최소 권한 원칙 적용

사용자나 서비스 계정에는 필요한 최소한의 권한만 부여합니다. 예를 들어, 운영팀에게는 운영 전용 네임스페이스에서만 권한을 부여하거나, 읽기 전용 계정은 get, list, watch 동사만 허용합니다.

2. 적절한 롤 설계

하나의 큰 롤보다는 목적별로 여러 개의 작은 롤을 설계하는 것이 권장됩니다. 이렇게 하면 권한 관리가 더 유연해집니다.

3. 네임스페이스 분리

다양한 팀이나 프로젝트에 대해 네임스페이스를 분리하고, 각 네임스페이스에 적절한 롤과 롤바인딩을 설정하는 것이 좋습니다.

4. 서비스 계정 활용

사용자 계정보다는 서비스 계정을 활용하여 Pod 또는 다른 워크로드에 대한 권한을 관리하는 것이 좋습니다.

---

결론

쿠버네티스의 RBAC 시스템은 클러스터 내에서 세밀한 권한 관리를 가능하게 합니다. Role과 RoleBinding은 네임스페이스 수준에서, ClusterRole과 ClusterRoleBinding은 클러스터 전체 수준에서 권한을 관리할 수 있게 해줍니다.

 

RBAC를 적절히 구성하면 여러 팀이 같은 클러스터를 사용하더라도 안전하게 리소스를 관리할 수 있습니다. 권한 설정 시 최소 권한 원칙을 적용하여 보안 사고를 예방하고, 필요에 따라 권한을 세밀하게 조정하는 것이 중요합니다.