kubernetes 기초 - RBAC(2)

1. ServiceAccount
2. Role
3. RoleBinding
4. ClusterRole                   ←  오늘 볼 내용
5. ClusterRoleBinding                   ←  오늘 볼 내용

---

4. ClusterRole

https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Using RBAC Authorization

 

 

내용이 이전이랑 다른 것이 거의 없어서 설명할 것이 적다.

ClusterRole은 특별한 것은 아니다.

이전 포스트에서 Role에 대해 언급한 바 있는데 Role은 특정 네임스페이스에 종속된 리소스에 대해 제어할 권한을 부여하는 것이었다.

ClusterRole은 클러스터 전체 범위에서 리소스에 대해 제어할 수 있는 권한을 가질 수 있다.

즉, 모든 네임스페이스에 적용된다는 것이다.

그래서 ClusterRole은 네임스페이스를 기재할 필요가 없다.

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

 

위 yaml 코드는 파드에 대해 get과 list를 사용할 수 있는 권한을 가진다.

하지만 Role과 다르게 네임스페이스가 기재되지 않으니 모든 네임스페이스에 있는 파드를 조회하는 권한을 가지는 것이다.

 

 

 

---

5. ClusterRoleBinding

ClusterRole은 ClusterRoleBinding으로 ServiceAccount나 User에 할당할 수 있다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-reader-binding
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

 

위와 같이 쿠버네티스에서 User를 생성하여 해당 유저에게 권한을 할당할 수도 있다.

 

알아둬야 할 것은 Role은 RoleBinding으로 할당할 수 있고,

ClusterRole은 ClusterRoleBinding으로 할당할 수 있다.

 

따로 분리한 이유이기도 하다.

 

Role이나 ClusterRole을 통해 권한을 할당하는 것은 보안적으로도 중요하다.

각 서비스계정이나 유저에게 필요한 최소한의 권한만 부여함으로 다른 리소스에 접근하지 못하게 할 수 있다.

발생하면 안되는 일이지만 불미스러운 사건으로 계정이 탈취되었다고 해도 특정 리소스에서 특정 명령만 사용할 수 있게 됨으로 피해를 최소화할 수 있다.

보안상으로 매우 중요하기 때문에 '최소 권한의 원칙' 이라는 말이 있다.

물론 권한만 제한한다고 모든 것을 막을 수 있는 것은 아니기에 etcd 암호화, secret을 사용한 데이터 암호화 등 다양한 부분에서도 주의를 기울여야 안전한 정보 시스템을 구축할 수 있다.

 

아직 공부하는 학생 신분이라 설명이 부족하고 깊은 탐구 수준이 아닐 수도 있지만 이 글을 보는 초보자도 쉽게 접근하고 개념을 파악할 수 있도록 하는 것이 목표이다.

공식 문서를 기반으로 설명하며 보기 어려운 공식 문서를 쉽게 풀어서 신뢰성있는 정보를 공유하고자 한다.

말이 길었지만 결론은 짧지만 양해부탁드립니다.