[kubernetes] Authentication & Authorization 02

Kubernetes 클러스터에서의 Authorization: 권한 제어의 핵심

앞서 authentication을 통해 클러스터에 접근할 수 있는 사용자(사람 또는 머신)를 식별하는 방법을 알아보았습니다. 그러나 인증만으로는 충분하지 않습니다. 클러스터에 접근할 수 있다고 해서 모든 작업을 수행할 수 있는 것은 아니며, authorization은 "사용자가 무엇을 할 수 있는가?"를 정의합니다.

클러스터에서 Authorization이 필요한 이유

클러스터의 관리자는 다양한 리소스를 조회하거나 수정, 삭제하는 모든 권한을 갖고 있습니다. 예를 들어 다음과 같은 작업이 가능합니다:

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

하지만 실무에서는 관리자뿐만 아니라 개발자, 테스터, 운영 시스템(예: Jenkins, Prometheus) 등 다양한 주체가 클러스터에 접근하게 됩니다. 이때 이들이 모두 관리자와 동일한 권한을 가진다면 보안 사고 또는 운영 장애로 이어질 수 있습니다. 따라서 클러스터 접근 권한은 최소 권한 원칙(Principle of Least Privilege)에 따라 부여되어야 하며, 이 역할을 하는 것이 authorization입니다. 예를 들어

• 개발자는 파드를  조회하고 배포는 할 수 있지만, 노드를 삭제하거나 스토리지/네트워크 설정을 바꿀 수 없어야 합니다.
• 외부 애플리케이션(예: Jenkins)은 필요한 작업만 할 수 있어야 하며, 불필요한 접근은 차단해야 합니다.
• 여러 팀이 클러스터를 공유할 경우, 각 팀은 자신의 namespace 내에서만 리소스를 관리해야 합니다.

authorization은 이러한 요구 사항을 구현하는 핵심 구성 요소입니다.

Kubernetes Authorization 메커니즘

Kubernetes는 다음과 같은 다양한 authorization 방식을 지원합니다:

• Node Authorization
• Attribute-based Access Control (ABAC)
• Role-Based Access Control (RBAC)
• Webhook
• 그 외 AlwaysAllow / AlwaysDeny 모드

Node Authorization

클러스터 내의 노드(kubelet)가 API 서버에 요청을 보내는 경우를 제어하는 전용 authorizer입니다. 예를 들어

• 노드가 자신이 호스팅하는 파드의 정보를 API 서버로부터 읽는 경우
• 자신의 상태나 리소스 사용량을 보고하는 경우

이러한 요청은 일반 사용자와 달리 Node authorizer가 별도로 처리합니다. Node authorizer는 요청 주체가 system:nodes 그룹에 속하고 system:node: 노드명 형식을 따르는 인증서를 사용할 때만 권한을 부여합니다. kubelet은 이 인증서를 통해 인증되고, Node authorizer는 kubelet의 동작에 필요한 최소한의 리소스 접근을 허용합니다.

ABAC (Attribute-Based Access Control)

ABAC는 사용자 또는 그룹의 속성(attribute) 에 따라 권한을 부여하는 방식입니다. 예를 들어 dev-user가 pod에 대해 get, create, delete 권한을 갖도록 설정할 수 있습니다. 사용 방법은 다음과 같습니다. 

• JSON 형식의 정책 파일을 작성
• 해당 파일을 Kube API 서버에 옵션으로 전달
• 파일 변경 시 API 서버 재시작 필요

하지만 단점이 존재합니다. 

• 정책이 파일에 고정되어 있어 유지보수에 불리
• 변경 시 API 서버 재시작 필요
• 복잡한 권한 체계를 구성하기 어려움

실제 환경에서는 점차 사용되지 않으며, RBAC로 대체되는 추세입니다.

RBAC (Role-Based Access Control)

Kubernetes에서 가장 일반적이고 권장되는 권한 제어 방식입니다. RBAC는 역할(Role) 을 중심으로 권한을 정의하고, 사용자를 역할에 바인딩(binding) 시켜 권한을 부여합니다.

• 동작 방식
  • Role 또는 ClusterRole 객체를 정의하여 권한 집합을 생성
  • RoleBinding 또는 ClusterRoleBinding 을 통해 사용자/그룹/서비스 계정을 권한에 매핑
• 예시
  • 개발자를 위한 dev-role 을 만들고, 모든 개발자를 여기에 바인딩
  • 역할만 수정하면 모든 연결된 사용자에게 일괄 적용
• 장점
  • 유연하고 중앙 집중적 관리 가능
  • namespace 단위 및 클러스터 단위 권한 제어 가능
  • kubectl 등 Kubernetes 도구와의 통합이 뛰어남

Webhook Authorization

Webhook은 외부 시스템(예: Open Policy Agent, 내부 보안 플랫폼)을 통해 authorization을 위임하는 방식입니다. Kubernetes는 요청을 외부 서비스에 전달하고, 승인 여부를 응답으로 수신합니다.

• 예시
  • Open Policy Agent (OPA)를 사용해 세밀한 정책을 관리
  • 사내 보안 팀에서 운영하는 승인 시스템과 통합 가능
• 장점
  • 복잡한 정책 논리를 외부로 위임 가능
  • 실시간 정책 변경 가능
• 주의점
  • 외부 서비스의 가용성에 따라 클러스터 요청이 지연 또는 실패할 수 있음
  • 성능 영향 고려 필요

Authorization 모드

Kubernetes API 서버는 하나 이상의 authorization 모드를 설정할 수 있으며, 기본값은 AlwaysAllow입니다. 사용 가능한 모드는 아래와 같습니다.

• AlwaysAllow: 모든 요청 허용 (비추천)
• AlwaysDeny: 모든 요청 거부
• Node: 노드 요청 처리
• RBAC: 역할 기반 제어
• Webhook: 외부 시스템 위임

구성 방법

API 서버 실행 시 --authorization-mode 옵션을 통해 설정합니다.

--authorization-mode=Node,RBAC,Webhook

 

쉼표로 구분된 순서대로 각 authorizer가 요청을 검사하며, 첫 번째로 요청을 승인한 authorizer가 최종 결정권을 가집니다. 하나라도 요청을 승인하면 그 즉시 처리가 완료되며, 이후 authorizer는 실행되지 않습니다. 모든 authorizer가 요청을 거부하면 최종적으로 접근이 차단됩니다.

예를 들어 사용자가 요청을 보내면 노드 authorizer가 먼저 처리합니다. Node Authorizer는 노드 요청만 처리하므로 요청을 거부합니다.

모듈이 요청을 거부할 때마다 요청은 체인의 다음 모듈로 전달됩니다. 역할 기반 액세스 제어 모듈은 검사를 수행하고 사용자 권한을 부여합니다. 인증이 완료되고 사용자에게 요청된 오브젝트에 대한 액세스 권한이 부여됩니다. 따라서 모듈이 요청을 거부할 때마다 체인의 다음 모듈로 이동하고 모듈이 요청을 승인하는 즉시 더 이상 확인이 수행되지 않고 사용자에게 권한이 부여됩니다.

정리

• 인증(Authentication)은 누가 요청하는지를 판별합니다.
• 권한 부여(Authorization)는 무엇을 할 수 있는지를 결정합니다.
• Kubernetes는 다양한 authorization 방식을 제공하지만, RBAC이 가장 일반적이고 관리하기 쉬운 방식입니다.
• 보안 강화를 위해 최소 권한 부여 원칙을 준수해야 하며, Webhook과 같은 외부 통합도 가능합니다.
• authorization은 API 서버 설정을 통해 유연하게 구성되며, 복수 모드 조합도 가능합니다.

Kubernetes 보안을 강화하기 위해서는 인증과 권한 부여를 함께 고려한 정교한 접근 제어 전략이 필수적입니다.