Udemy CKA 강의 정리 159: Role Based Access Controls

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

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

---

이번 강의에서는 역할 기반 접근 제어에 대해 훨씬 더 자세히 살펴보겠습니다.

How do we create a role?

어떻게 역할을 생성할까요? 우리는 역할 오브젝트를 생성하여 이를 수행합니다. 그래서 우리는 API 버전이 rbac.authorization.k8s.io/v1으로 설정된 role definition 파일을 만듭니다. kind는 Role 입니다. metadata에 name을 developer로 지정합니다. 다음으로 rules를 지정합니다. 각 rule에는 apiGroups, resources, verbs 세 가지 섹션이 있습니다.

• apiGroups
• resources
• verbs

이전 강의 중 하나에서 이야기했던 것과 같은 것입니다. Core 그룹의 경우 API 그룹 섹션을 비워 둘 수 있습니다. 다른 그룹의 경우 그룹 이름을 입력해야 합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "list", "update", "delete", "create"]
- apiGroups: [""]
  resources: ["ConfigMap"]
  verbs: ["create"]

우리가 개발자에게 액세스 권한을 부여하려는 리소스는 파드입니다. 수행할 수 있는 작업(verb)은 나열, 가져오기, 생성 및 삭제입니다. 마찬가지로 개발자가 config map을 만들 수 있도록 config map을 만드는 다른 규칙을 추가합니다. 이와 같이 단일 역할에 대해 여러 규칙을 추가할 수 있습니다.

kubectl create role 커맨드를 사용하여 역할을 생성합니다.

$ kubectl create -f developer-role.yaml

The next step is to link the user to that role.

다음 단계는 사용자를 해당 역할에 연결하는 것입니다. 이를 위해 롤 바인딩이라는 또 다른 오브젝트를 만듭니다. 롤 바인딩 오브젝트는 사용자 오브젝트를 역할에 연결합니다. 우리는 그것을 devuser-developer-binding.yaml로 이름을 지정할 것입니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devuser-developer-binding
subjects:
- kind: User
  name: dev-user # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

kind는 RoleBinding입니다. 두 개의 섹션이 있습니다. subjects는 사용자 세부 정보를 지정하는 곳입니다. roleRef 섹션은 우리가 생성한 롤의 세부 정보를 제공하는 곳입니다. kubectl create 커맨드를 사용하여 role binding을 만들 수 있습니다. 또한 역할 및 역할 바인딩은 네임스페이스 범위에 속합니다. 따라서 여기에서 dev-user는 default 네임스페이스 내에서 파드 및 config map에 액세스할 수 있습니다. 다른 namespace 내에서 dev-user의 액세스를 제한하려면 파일을 만드는 동안 definition 파일의 메타데이터 내에서 namespace을 지정하면 됩니다.

View RBAC

생성된 역할을 보려면 kubectl get roles 커맨드를 실행하십시오.

$ kubectl get roles

롤 바인딩을 조회하려면 kubectl get rolebindings 커맨드를 실행하십시오.

$ kubectl get rolebindings

역할에 대한 자세한 정보를 보려면 kubectl describe role 커맨드를 실행하십시오.

$ kubectl describe role developer

여기에서 각 리소스에 대한 리소스 및 권한에 대한 세부 정보를 볼 수 있습니다.

마찬가지로 롤 바인딩에 대한 세부 정보를 보려면 kubectl describe rolebinding 커맨드를 실행합니다.

$ kubectl describe rolebinding devuser-developer-binding

여기에서 롤 바인딩에 대한 세부 정보를 볼 수 있습니다.

Check Access

사용자가 클러스터의 특정 리소스에 대한 액세스 권한이 있는지 확인하려면 어떻게 해야 할까요? kubectl auth can-i 커맨드를 사용하여 배포를 만들거나 노드 삭제를 할 수 있는지 확인할 수 있습니다.

$ kubectl auth can-i create deployments
$ kubectl auth can-i delete nodes

관리자인 경우 다른 사용자로 가장하여 권한을 확인할 수도 있습니다. 예를 들어 사용자가 일련의 작업을 수행하는 데 필요한 권한 집합을 만드는 작업을 맡았고 작업을 수행했지만 수행한 작업이 작동하는지 테스트하고 싶다고 가정해 보겠습니다. 테스트하기 위해 사용자로 인증할 필요가 없습니다.

$ kubectl auth can-i create deployments --as dev-user
$ kubectl auth can-i create pods --as dev-user

대신 이와 같이 --as 사용자 옵션으로 커맨드를 사용하면 됩니다.

배포를 생성할 수 있는 개발자 권한을 부여하지 않았으므로 no를 반환합니다. 그러나 dev-user는 파드 생성에 액세스할 수 있습니다.

$ kubectl auth can-i create pods --as dev-user --namespace test

이와 같이 커맨드에 네임스페이스를 지정할 수도 있습니다. 위에서 결과를 보면 dev-user는 테스트 네임스페이스에 파드를 생성할 수 있는 권한이 없습니다.

Resource Names

리소스 이름에 대해 참고할 사항이 있습니다. 방금 네임스페이스 내의 파드과 같은 리소스에 대한 액세스를 사용자에게 제공하는 방법을 살펴보았습니다. 한 수준 아래로 이동하여 특정 리소스에 대한 액세스만 허용할 수 있습니다. 예를 들어 네임스페이스에 모든 파드가 아니라 사용자에게 파드에 대한 액세스 권한을 부여하려는 다섯 부분이 있다고 가정합니다.

rules에 리소스 resourceNames를 추가하여 blue 및 orange 파드에 대한 액세스만 제한할 수 있습니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "update", "create"]
  resourceNames: ["blue", "orange"]