[Kubernetes] Kubernetes RBAC 간단 정리

개요

 

  Kuberenetes의 RBAC 인증은 API Server에서 제공하는 인가 방식 중 하나이다. 보안 접근 통제 모델의 RBAC를 클러스터에 적용할 수 있도록 만들어진 듯 하다.

 

  RBAC(Role-based Access Control)에서 나오는 Role은 실제 기업 내의 역할을 말한다. 실제 인프라에서 웹 관리자와 DB 관리자라는 역할이 나눠놓고 운영하는데 이러한 역할을 Kubernetes 클러스터에 적용하면 기업의 상황에 맞게 접근 통제 설정이 가능해진다.

 

  그래서 중요한 설정은 어떻게 하는 것인가 검색해보면 Role과 RoleBinding와 ClusterRole과 ClusterRoleBinding 이라는 놈들이 줄줄이 나오면서 뭔가 설정과 설명을 줄줄이 하고 있다. 글이 길어지면 읽기 싫어지니깐 간단하게 설명해주면 좋겠다. 그러니깐 간단하게 정리하고자 한다.

 

• Access Control(접근 제어) : '누가 어디서 무엇을 어떻게' 하는가?
• RBAC(Role-based Access Control) : 어떤 역할(Role)이 '어디서 무엇을 어떻게' 하는가?

 

Role과 ClusterRole

 

  Role과 RoleBinding와 ClusterRole과 ClusterRoleBinding 이라는 놈들이 줄줄이 있다고 했는데 간단히 정리하면 다음과 같다.

  

• Role : 특정 네임스페이스에 한정된 정책
  (특정 네임스페이스 + '어디서 무엇을 어떻게')
• ClusterRole : 클러스터 전체에 한정된 정책
  (클러스터 전체 + '어디서 무엇을 어떻게')
• RoleBinding : 역할이 특정 네임스페이스에 한정된 정책을 따르도록 적용
  (어떤 역할이 특정 네임스페이스에서 하는가?)
• ClusterRoleBinding : 역할이 클러스터 전체에 한정된 정책을 따르도록 적용
  (어떤 역할이 클러스터 전체에서 하는가?)

 

yaml 파일 작성

(yaml 내용을 더 자세하게 보려면 링크를 참조하면 된다.)

 

  용어는 알았으니 예시를 yaml 파일의 내용의 사진과 함께 볼 것이다. 전부 볼 필요없이 rules 쪽 내용만 봐도 되는데 일단은 전체에 대해서 정리하였다. 

• kind: Role
  • 특정 네임스페이스에 한정된 정책을 명시하는 파일이다. 라는 뜻
• apiVersion: rbac.authorization.k8s.io/v1
  • kind: Role 을 사용하기 위해서는 일단 필요
• metadata : 정책을 구분지을 메타데이터 값
  • namespace : 정책이 적용될 특정 네임스페이스
  • name : 정책의 이름
• rules : 정책
  ('어디서 무엇을 어떻게' 하는지를 적는 곳, "- apiGroups" 단위로 정책 한 뭉텅이)
  
  • apiGroups : resources가 속한 apiGroup, ''은 Core API Group을 말한다.
  • resources : 규칙을 적용할 리소스 목록, ResourceAll 은 모든 리소스를 나타낸다.
  • verbs : 리소스 접근 동사(접근 동사 목록은 link 참고)
• 요약(Role 파일의 내용)
  • Core API 그룹의 pods 리소스에 대해 get. list만을 허용한다.
  • Core API 그룹의 services 리소스에 대해 edit 만을 허용한다.

 

• kind: RoleBinding
  • 특정 네임스페이스에 한정된 정책을 명시하는 파일이다. 라는 뜻
• apiVersion: rbac.authorization.k8s.io/v1
  • kind: RoleBinding 을 사용하기 위해서는 일단 필요
• metadata : 정책을 구분지을 메타데이터 값
  • namespace : 정책이 적용될 특정 네임스페이스
  • name : 정책의 이름
• subjects : 주체('누가' 또는 어떤 역할)
  • kind : 주체의 종류 (User, Group, ServiceAccount 중 하나)
  • name : 주체의 이름
  • apiGroup : kind가 ServiceAccount이면 "", User나 Group 이면 rbac.authorization.k8s.io
• roleRef : 주체에 적용할 정책 목록
  
  • kind : 참조할건 정책이므로 Role
  • name : "kind: Role"의 metadata name.
  • apiGroup : "kind: Role"을 사용하기 위해서는 필요
• 요약(RoleBinding 파일의 내용)
  • nginxinc-reader라는 서비스 계정(Core API 그룹 소속)은read-nginxinc-role이라는 Role(rbac.authorization.k8s.io API 그룹 소속)이라는 리소스를 정책으로써 참조한다.

  정책을 정리하면 “nginxinc-reader라는 서비스 계정은 nginxinc라는 네임스페이스의 pod의 목록을 볼 수 있고, service에 대해서는 변경만 가능하다.” 라는 결론이 나온다.

 

  이번엔 ClusterRole에 대해서 볼 것이다. 위에서 한 번 자세히 설명했었고, 맥락은 비슷하니 내용의 결론만 볼 것이다. 참고로 해당 설정은 중간의 --- 로 Role과 Binding이 구분된다.

• ClusterRole의 내용
  • Core API 그룹의 pods 리소스에 대해 get, list, edit 만을 허용한다.
• ClusterRoleBinding의 내용
  • nginxinc-admin이라는 서비스 계정(Core API 그룹 소속)은 admin-nginxinc-role이라는 ClusterRole(rbac.authorization.k8s.io API 그룹 소속)이라는 리소스를 정책으로써 참조한다.

  정책을 정리하면 “nginxinc-admin이라는 서비스 계정은 nginxinc라는 클러스터 전체의 pod의와 service를 볼 수 있고 수정도 가능하다.” 라는 결론이 나온다.

 

 

결론

 

  복잡한거 같지만 이게 끝이다. 기업 내 역할만 잘 배분되어 있다면 해당 역할을 기반으로 한 설정은 그대로 맞춰주면 된다.

 

  실습은 RBAC에 대해서 더 자세히 설명한 글들이 많기 때문에 제외하였고, API Group에 대해서는 대충 설명했는데 다른 글에서 목록을 따로 정리할 예정이다. 일단은 참고 링크의 Kubernetes API v1.20 문서로도 API Group에 대해서 파악 가능하긴 하다.

 

 

참고 링크

• Kubernetes RBAC : link

Using RBAC Authorization

• Kubernetes API v1.20 : link

• Kubernetes RBAC Verb 목록 : link

인가 개요