[kubernetes] RBAC와 role

1. ClusterRole vs Role

RBAC에서 권한(permissions) 을 정의하는 두 가지 리소스가 있다.

 

• Role
  • 특정 네임스페이스(namespace) 내에서만 유효한 권한을 정의한다.
  • 특정 네임스페이스 내의 리소스(예: pods, services, configmaps)에 대한 접근을 제어할 때 사용된다.
  • 네임스페이스에 종속적이므로, metadata.namespace 필드를 지정해야 한다.

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

• ClusterRole
  • 클러스터 전역에서 적용되는 권한을 정의한다.
  • 네임스페이스에 종속되지 않으며, ClusterRole을 사용하면 모든 네임스페이스의 리소스를 관리할 수 있다.
  • 네임스페이스를 지정할 수 없으며, 클러스터 전반의 리소스(nodes, namespaces, persistentvolumes 등)에 대한 접근 권한을 설정할 때 유용하다.

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: cluster-admin-role
  rules:
  - apiGroups: [""]
    resources: ["nodes", "pods", "services"]
    verbs: ["get", "list", "watch"]

  
  yaml

   

---

2. RoleBinding vs ClusterRoleBinding

위에서 정의한 Role과 ClusterRole을 특정 사용자(User), 그룹(Group), 또는 서비스 계정(ServiceAccount)에 할당할 때 사용된다.

• RoleBinding
  • 특정 네임스페이스 내에서만 Role을 사용자 또는 서비스 계정에 할당한다.
  • 특정 네임스페이스 내의 리소스에 대한 권한을 부여한다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: my-namespace
subjects:
- kind: User
  name: example-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

• ClusterRoleBinding
  • ClusterRole을 사용자(User), 그룹(Group), 또는 서비스 계정(ServiceAccount)에 할당한다.
  • 클러스터 전체에서 특정 사용자나 그룹에게 권한을 부여할 수 있다.
  • 특정 네임스페이스가 아닌 클러스터 전체에서 권한을 부여해야 할 경우 사용한다.

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

---

3. RBAC를 통한 Kubernetes 리소스 관리 방식

Kubernetes의 모든 리소스에 대한 접근을 RBAC로 관리하는 방법은 다음과 같다:

(1) 최소 권한 원칙 적용 (Least Privilege)

• 사용자가 필요 이상의 권한을 가지지 않도록 역할을 세분화하여 관리한다.
• 예를 들어, 개발자에게 pods 조회(get, list, watch) 권한만 부여하고, 삭제(delete)는 금지한다.

(2) ClusterRole과 Role을 적절히 활용

• 클러스터 전체를 관리해야 하는 경우 ClusterRole을 사용하고, 특정 네임스페이스만 관리해야 하는 경우 Role을 사용한다.
• 예제:
  • ClusterRole: 모든 네임스페이스의 nodes 및 persistentvolumes를 관리할 수 있도록 설정.
  • Role: 특정 네임스페이스에서 configmaps을 수정할 수 있도록 설정.

(3) 사용자 및 서비스 계정과 RoleBinding/ClusterRoleBinding 연결

• 특정 사용자나 그룹이 역할(Role 또는 ClusterRole)에 바인딩되도록 설정한다.
• CI/CD 시스템이나 애플리케이션 Pod에서 사용하는 ServiceAccount에 맞는 Role을 할당한다.

(4) 사전 정의된 ClusterRole 활용

• Kubernetes에는 기본적으로 사전 정의된 ClusterRole이 제공되며, 이를 활용하면 더욱 효율적으로 권한을 설정할 수 있다.

kubectl get clusterroles

•  기본 제공되는 주요 ClusterRole:
  • cluster-admin: 클러스터 내 모든 리소스에 대한 모든 권한 부여
  • admin: 특정 네임스페이스 내에서 대부분의 리소스를 관리할 수 있는 권한 부여
  • edit: 특정 네임스페이스 내에서 리소스를 생성 및 수정할 수 있는 권한 부여
  • view: 특정 네임스페이스 내의 리소스를 조회할 수 있는 권한 부여

(5) RBAC 변경 사항 적용 및 테스트

• 변경된 RBAC 설정을 적용하고 제대로 동작하는지 테스트하기 위해 kubectl auth can-i 명령을 사용한다.

# 특정 사용자가 pod을 조회할 수 있는지 확인
kubectl auth can-i get pods --as=example-user

• 특정 RoleBinding이 적용된 사용자가 접근 가능한 리소스를 확인하려면:

kubectl auth can-i list services --as=example-user -n my-namespace

---

4. 요약

 

RBAC 리소스	설명	적용 범위
Role	특정 네임스페이스 내에서만 권한 부여	네임스페이스
ClusterRole	클러스터 전체에서 권한 부여	클러스터
RoleBinding	특정 네임스페이스 내에서 Role을 사용자 또는 그룹에 할당	네임스페이스
ClusterRoleBinding	클러스터 전체에서 ClusterRole을 사용자 또는 그룹에 할당	클러스터

RBAC를 통해 Kubernetes 리소스 접근을 관리하면 보안성을 강화할 수 있으며, 최소 권한 원칙을 준수하여 불필요한 권한 남용을 방지할 수 있다. Kubernetes 운영 시 RBAC를 체계적으로 설정하여 효율적인 접근 제어를 적용하는 것이 중요하다.