Kubernetes 정리 158: Authorization

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

1. Cluster에서 Authorization이 필요한 이유는 무엇인가?

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

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

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

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

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

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

namespace에서만 사용자 액세스를 제한하려고 합니다. 이것이 authorization 이 클러스터 내에서 할 수 있는 것들입니다.

 

2. Authorization Mechanisms

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

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

 

3. Node Authorization

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

 

 

4. ABAC

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

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

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

 

5. RBAC

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

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

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

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