[5주차] CHAPTER-22 역활 기반 제어(RBAC)

이정훈님이 집필하신 "24단계 실습으로 정복하는 쿠버네티스" 로 진행하는 CloudNet@ 팀의 PKOS 5주차 정리입니다.

🧿 RBAC (Role-Based Access Control) 주요 구성요소

✔ Role / RoleBinding

✔ ClusterRole / ClusterRoleBinding

✔ ServiceAccount (Token)

✅ Role / RoleBinding 과 ClusterRole / ClusterRoleBinding

🧿 Role

  ✔ 네임스페이스 내에서 액세스 권한을 정의

 

🧿 ClusterRole 

  ✔ 클러스터 전체에서 액세스 권한을 정의

 

🧿 특정 namespace(wordpress)의 전체 리소스에 대해 모든 권한을 가지는 Role YAML 파일

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: wordpress-namespace-full-access
  namespace: wordpress
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

✔ namespace: wordpress

  ◾ role은 namespace 단위로 할당되므로 namespace를 지정합니다.

✔ apiGroup: ["", "extentions", "apps"], resources: ["*"]

  ◾ 리소스가 속한 apigroup 이름을 명시합니다.

  ◾ "*" 는 전체 리소스를 의미합니다.

✔ verbs: ["*"]

  ◾ 리소스가 create, get등 특정 권한을 동사 형태로 지정합니다.

 

🧿 Role을 생성합니다.

✔ 해당 Role을 사용자에게 적용하려면 RoleBinding이 필요합니다.

Role (실제권한 지정) / RoleBinding (해당권한을 사용자에게 할당)

🧿 wordpress 네임스페이스에 대한 RoleBinding YAML 파일

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: wordpress-namespace-full-access-rb
  namespace: wordpress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: wordpress-namespace-full-access
subjects:
- kind: ServiceAccount
  name: wordpress-sa
  namespace: wordpress

✔ roleRef: name: wordpress-namespace-full-access

  ◾ RoleBinding이 지정하는 Role을 name으로 지정합니다.

✔ subjects: -kind: ServiceAccount

  ◾ RoleBinding을 사용하는 주체(ServiceAccount, User, Group)을 지정합니다.

✔ name: wordpress-sa

  ◾ ServiceAccount 이름을 임의로 (wordpress-sa) 지정합니다.

 

🧿 RoleBinding을 생성합니다.

 

✅ ServiceAccount와 User, kubeconfig 파일

✔  RoleBinding을 사용하기 위해 ServiceAccount를 사용합니다.

 

🧿 ServiceAccount

  ✔ 사용자가 쿠버네티스 API 서버를 이용하기 위한 인증 과정을 처리하는 역활

 

🧿 wordpress 네임스페이스의 ServiceAccount YAML 파일

apiVersion: v1
kind: ServiceAccount
metadata:
  name: wordpress-sa
  namespace: wordpress

✔ name: wordress-sa

  ◾ RoleBinding을 생성할 때 지정한 이름

 

🧿 ServiceAccount을 생성합니다.

🧿 RoleBinding 상세 내역에서 RoleBinding과 연결된 ServiceAccount(wordpress-sa) 확인

🧿 ServiceAccount 를 쿠버네티스 사용자와 연결합니다.

 

✔ ServiceAccount 를 생성하면 해당 ServiceAccount의 Token이 생성됩니다. 

✔ 이 Token 정보를 kubeconfig 설정 파일({HOME}/.kube/config)의 사용자 Token 정보에 등록 

       => 사용자와 ServiceAccount를 연결

 

🧿 1.24 버전 이후에는 Token정보가 보이지 않습니다.

🧿 Token을 수동으로 생성합니다.

🧿 Token 정보를 kubeconfig(~/.kube/config)에 저장합니다.

🧿 kubeconfig 파일

✔ cluster:

  ◾ 원격 클러스터의 API 파드 IP와 포트 정보를 입력합니다.

✔ context:

  ◾ 외부에서 API로 접속했을 떄 사용하게 되는 Cluster, Namespace, User 정보

✔ users:

  ◾ 쿠버네티스 인증은 파일 기반(x509, Token) 입니다.

 

🧿 특정 Namespace에서만 모든 권한을 가진 새로운 사용자를 생성합니다.

- context:
    cluster: cluster.local
    namespace: wordpress
    user: wordpress-user
  name: wordpress@cluster.local


- name: wordpress-user
  user:
    token: eyJhbGciOiJSUzI1NiIsImtp

 

✅ 멀티테넌시(다중 사용자) 환경의 쿠버네티스 구성

✔ 쿠버네티스 환경의 멀티테넌시(다중 사용자)환경 구현은 Namespace 단위로 구분합니다.

✔ 사용자마다 구분하여 특정 Namespcae 권한을 가지고 다른 Namespcae의 리소스는 조회하거나 생성하지 못하도록 합니다.

 

🧿 사용자를 변경합니다.

🧿 wordpress 네임스페이스에서 deployment 리소스를 생성합니다.

🧿 다른 네입스페이스(default)에서는 Pod 조회나 생성이 되지 않습니다.

🧿 wordpress@cluster.local 컨텍스트는 Namespace 단위의 권한을 가지는 Role만 설정되어 있어 

   => 전체 Cluster단위의 ClusterRole은 설정되지 않았습니다.

     => 따라서, 전체 Namespace 단위의 권한이 필요한 namespace, pv 등의 리소스는 조회되지 않습니다.

개별 Namespace 권한을 가지는 사용자로 멀티테넌시(다중사용자) 환경의 클러스터를 운용할 수 있습니다.