Udemy CKA 강의 정리 162: Cluster Roles and Role Bindings

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이전 강의에서 롤과 롤바인딩에 대해 논의했습니다. 이 강의에서는 클러스터 롤 및 클러스터 롤바인딩에 대해 설명합니다.

Roles

롤과 롤바인딩에 대해 이야기할 때 롤과 롤바인딩은 네임스페이스가 지정되어 있으며 이는 네임스페이스 내에서 생성된다는 의미입니다. 네임스페이스를 지정하지 않으면 default 네임스페이스에 생성되며, 해당 네임스페이스 내에서만 액세스를 제어합니다.

Namespaces

이전 강의 중 하나에서 우리는 네임스페이스에 대해 살펴보았고,  파드와 배포 및 서비스와 같은 리소스를 그룹화하거나 격리하는 데 어떻게 도움이 되는지에 대해 논의했습니다. 그러나 노드와 같은 다른 리소스는 어떻습니까? 네임스페이스 내에서 노드를 그룹화하거나 격리할 수 있나요? node01이 dev 네임스페이스의 일부라고 말할 수 있을까요? 아니요, 클러스터 전체 또는 클러스터 범위 리소스입니다. 노드는 특정 네임스페이스에 연결할 수 없습니다.

따라서 리소스는 네임스페이스 또는 클러스터 범위로 분류됩니다. 이제 우리는 파드, ReplicaSets, jobs, 배포, 서비스, secret과 같은 이 과정 전반에 걸쳐 많은 네임스페이스 리소스를 보았고, 지난 강의에서는 두 가지 새로운 롤과 롤바인딩을 보았습니다. 이러한 리소스는 리소스를 생성할 때 지정한 네임스페이스에 생성됩니다. 네임스페이스를 지정하지 않으면 default 네임스페이스에 생성됩니다. 이를 보거나 삭제하거나 업데이트하려면 항상 올바른 네임스페이스를 지정해야 합니다.

클러스터 범위 리소스는 이 강의에서 살펴볼 클러스터 롤 및 클러스터 롤바인딩을 포함하여 노드, persistent volume과 같이 리소스를 생성할 때 네임스페이스를 지정하지 않는 리소스입니다. 앞에서 본 인증서 서명 요청과 네임스페이스 오브젝트 자체는 물론 네임스페이스 범위 리소스가 아닙니다.

네임스페이스가 있는 리소스와 네임스페이스가 없는 리소스의 전체 목록을 보려면 네임스페이스가 있는 옵션을 설정하여 kubectl api-resources 커맨드를 실행하십시오.

$ kubectl api-resources --namespaced=true

$ $ kubectl api-resources --namespaced=false

Cluster Roles and Cluster Role Bindings

이전 강의에서 사용자에게 네임스페이스 리소스에 대한 권한을 부여하는 방법을 살펴보았습니다. 이를 위해 롤과 롤바인딩을 사용했습니다. 그러나 사용자에게 노드 또는 persistent volume과 같은 클러스터 범위 리소스에 대한 권한을 부여하는 방법은 무엇일까요? 여기에서 클러스터 롤 및 클러스터 롤바인딩을 사용합니다.

클러스터 롤은 클러스터 범위 리소스에 대한 것이라는 점을 제외하면 롤과 같습니다. 예를 들어 클러스터 관리자 롤을 생성하여 클러스터에서 노드를 보거나 생성하거나 삭제할 수 있는 클러스터 관리자 권한을 제공할 수 있습니다. 마찬가지로 스토리지 관리자 롤을 생성하여 스토리지 관리자에게 persistent volume 및 클레임(?)을 생성할 수 있는 권한을 부여할 수 있습니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-administrator
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["nodes"]
  verbs: ["get", "list", "delete", "create"]

kind를 ClusterRole로 지정하는 클러스터 롤 definition 파일을 만들고 이전과 같이 rules을 지정합니다. 이 경우 resources는 nodes입니다.

다음 단계는 사용자를 해당 클러스터 롤에 연결하는 것입니다. 이를 위해 클러스터 롤바인딩이라는 또 다른 오브젝트를 만듭니다.

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

롤바인딩 오브젝트는 사용자를 롤에 연결합니다. metadata > name을 cluster-admin-role-binding으로 지정했습니다. kind는 ClusterRoleBinding입니다. subjects 아래에서 사용자 세부 정보(이 경우 cluseter-admin)를 지정합니다. roleRef 섹션은 생성한 클러스터 롤의 세부 정보를 제공하는 곳입니다.

kubectl create 커맨드를 사용하여 롤바인딩을 생성합니다.

$ kubectl create -f cluster-admin-role.yaml
$ kubectl create -f cluster-admin-role-binding.yaml

주의할 점이 하나 있습니다. 우리는 클러스터 롤과 바인딩이 클러스터 범위 리소스에 사용된다고 말했지만 이는 엄격한 규칙이 아닙니다. 네임스페이스 리소스에 대한 클러스터 롤도 생성할 수 있습니다. 그렇게 하면 사용자는 모든 네임스페이스에서 이러한 리소스에 액세스할 수 있습니다. 이전에 사용자에게 파드 액세스 권한을 부여하는 롤을 생성할 때 사용자는 특정 네임스페이스에서만 파드에 액세스할 수 있었습니다. 클러스터 롤을 사용하여 사용자에게 파드에 대한 액세스 권한을 부여하면 사용자는 클러스터 전체의 모든 파드에 대한 액세스 권한을 얻습니다. Kubernetes는 클러스터가 처음 설정될 때 default로 여러 클러스터 롤을 생성합니다.