Udemy CKA 강의 정리 158: Authorization

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

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

---

지금까지 authentication에 대해 이야기했습니다. 우리는 사람 또는 머신이 클러스터에 액세스할 수 있는 다양한 방법을 보았습니다. 액세스 권한을 얻은 후에는 무엇을 할 수 있나요? 바로 그것이 authorization이 정의하는 것들입니다.

Why do you need Authorization in your cluster?

먼저 클러스터에서 authorization이 필요한 이유는 무엇입니까? 클러스터의 관리자로서 파드, 노드, 배포와 같은 다양한 오브젝트 보기나 파드 또는 클러스터의 노드 추가, 삭제와 같은 오브젝트 생성,삭제  같은 모든 종류의 작업을 클러스터에서 수행할 수 있었습니다.

$ kubectl get nodes
$ kubectl get pods
$ kubectl delete node worker-2

관리자로서 우리는 모든 작업을 수행할 수 있지만 곧 다른 관리자, 개발자, 테스터 또는 모니터링 애플리케이션이나 Jenkins 등과 같은 지속적 배포 애플리케이션과 같은 기타 애플리케이션과 같은 다른 것들이 클러스터에 액세스하게 될 것입니다.

따라서 이전 강의에서 본 것처럼 username과 password 또는 토큰 또는 서명된 TLS 인증서 또는 서비스 계정을 생성하여 클러스터에 액세스할 수 있는 계정을 생성할 것입니다. 그러나 우리는 그들 모두가 우리와 같은 수준의 액세스 권한을 갖기를 원하지 않습니다.

예를 들어 개발자가 노드 추가, 삭제 또는 스토리지 또는 네트워킹 configuration과 같은 클러스터 configuration을 수정할 수 있는 액세스 권한을 원하지 않습니다. 볼 수는 있지만 수정할 수는 없고, 애플리케이션 배포에 액세스할 수는 있습니다.

서비스 계정도 마찬가지입니다. 필요한 작업을 수행하는 데 필요한 최소한의 액세스 수준만 외부 애플리케이션에 제공하려고 합니다. 다른 조직이나 팀 간에 클러스터를 공유할 때 namespace를 사용하여 클러스터를 논리적으로 분할하여 namespace에서만 사용자 액세스를 제한하려고 합니다. 이것이 authorization이 클러스터 내에서 할 수 있는 것들입니다.

Authorization Mechanisms

노드 authorization, 속성 기반 authorization, 역할 기반 authorization, 웹후크와 같이 Kubernetes에서 지원하는 다양한 authorization 메커니즘이 있습니다.

• Node Authorization
• Attribute-based Authorization (ABAC)
• Role-Based Authorization (RBAC)
• Webhook

Node Authorization

Kube API 서버는 우리와 같은 사용자가 관리 목적으로 클러스터 내 노드의 kubelet에 액세스한다는 것을 알고 있습니다. kubelet은 API 서버에 액세스하여 서비스 및 포인트, 노드 및 파드에 대한 정보를 읽습니다. kubelet은 또한 상태와 같은 노드 정보와 함께 Kube API 서버에 보고합니다. 이러한 요청은 노드 authorizer라고 하는 특수 authorizer가 처리합니다. 이전 강의에서 인증서에 대해 논의할 때 kubelet은 시스템 노드 그룹의 일부여야 하며 시스템 노드라는 접두사가 붙는 이름을 가져야 한다고 얘기했습니다. 따라서 이름이 시스템 노드이고 시스템 노드 그룹의 일부인 사용자로부터 오는 모든 요청은 노드 authorizer에 의해 권한이 부여되고, kubelet에도 마찬가지입니다. 이것이 클러스터 내 액세스입니다.

ABAC

API에 대한 외부 액세스에 대해 이야기해 보겠습니다. 예를 들어 사용자입니다. 속성 기반 authorization는 사용자 또는 사용자 그룹을 권한 집합과 연결하는 곳입니다.

이 경우 dev-user는 Pod를 보고, 만들고, 삭제할 수 있습니다. 이 파일을 위와 같이 API 서버로 전달하는 방식으로 인접한 형식으로 정의된 정책 세트로 policy 파일을 생성하면 됩니다.

마찬가지로 이 파일의 각 사용자 또는 그룹에 대한 policy definition 파일을 만듭니다. 이제 보안을 추가하거나 변경해야 할 때마다 이 정책 파일을 수동으로 편집하고 Kube API 서버를 다시 시작해야 합니다. 따라서 속성 기반 액세스 control configuration은 관리하기 어렵습니다.

RBAC

다음에 역할 기반 액세스 제어를 살펴보겠습니다. 역할 기반 액세스 제어를 통하면 위에서 말한 작업들이 훨씬 쉬워집니다.

역할 기반 액세스 제어를 사용하면 사용자 또는 그룹을 일련의 권한과 직접 연결하는 대신 사용자를 위한 역할을 정의합니다. 이 경우에는 개발자에게 필요한 권한 세트로 역할을 만든 다음 모든 개발자를 해당 역할에 연결합니다.

마찬가지로 보안 사용자에게 필요한 올바른 권한 세트가 있는 역할을 생성한 다음 사용자를 해당 역할에 연결합니다.

앞으로 사용자 액세스를 변경해야 할 때마다 역할을 수정하기만 하면 모든 개발자에게 즉시 반영됩니다. 역할 기반 액세스 제어는 Kubernetes 클러스터 내에서 액세스를 관리하는 보다 표준적인 접근 방식을 제공합니다.

다음 강의에서 역할 기반 액세스 제어에 대해 자세히 살펴보겠습니다.

Webhook

이제 모든 authorization 메커니즘을 아웃소싱하려면 어떻게 해야 할까요? 방금 논의한 기본 제공 메커니즘을 통하지 않고 외부에서 authorization을 관리하려 한다고 가정해 보겠습니다.

예를 들어 Open Policy Agent는 admission control 및 authorization에 도움이 되는 타사 도구입니다. Kubernetes가 다음 정보를 사용하여 Open Policy Agent에 대한 API 호출을 수행하도록 할 수 있습니다. 사용자와 사용자의 액세스 요구 사항을 확인하고 Open Policy Agent가 사용자의 허용 여부를 결정하도록 합니다. 해당 응답에 따라 사용자에게 액세스 권한이 부여됩니다.

Authorization Modes

이제 방금 본 것 외에 두 가지 모드가 더 있습니다. Always Allow, Always Deny입니다. 이름에서 알 수 있듯이 항상 허용은 인증 확인을 수행하지 않고 모든 요청을 허용합니다. 항상 거부는 모든 요청을 거부합니다. 그렇다면 이러한 모드를 어디에서 구성할까요? 어떤 것이 default일까요? 한 번에 여러 개를 가질 수 있을까요? 여러 개를 구성한 경우 인증은 어떻게 작동할까요?

모드는 Kube API 서버에서 authorization 모드 옵션을 사용하여 설정됩니다. 이 옵션을 지정하지 않으면 default로 항상 허용으로 설정됩니다. 사용하려는 여러 모드의 쉼표로 구분된 목록을 제공할 수 있습니다. 이 경우 node, rbac, webhook을 설정하고 있습니다. 여러 모드를 구성한 경우 지정된 순서대로 각 모드를 사용하여 요청에 권한이 부여됩니다.

예를 들어 사용자가 요청을 보내면 노드 authorizer가 먼저 처리합니다. Node Authorizer는 노드 요청만 처리하므로 요청을 거부합니다. 모듈이 요청을 거부할 때마다 요청은 체인의 다음 모듈로 전달됩니다. 역할 기반 액세스 제어 모듈은 검사를 수행하고 사용자 권한을 부여합니다. 인증이 완료되고 사용자에게 요청된 오브젝트에 대한 액세스 권한이 부여됩니다.

따라서 모듈이 요청을 거부할 때마다 체인의 다음 모듈로 이동하고 모듈이 요청을 승인하는 즉시 더 이상 확인이 수행되지 않고 사용자에게 권한이 부여됩니다.