Cloud/Kubernetes

[Zero Trust Architecture in Kubernetes] Chapter 1

veriperi 2025. 4. 8. 01:09
728x90
본 글은 O`REILLY의 'Zero Trust Architecutre in Kubernetes' 도서를 기반으로 정리한 내용입니다.
https://learning.oreilly.com/library/view/zero-trust-architecture/9781098138646/

Chapter 1. Authentication and Authorization

📌 제로 트러스트(Zero Trust)란?
네트워크 내의 가능한 모든 벡터에서 데이터 전송 및 상호작용이 인증되도록 보장하는 개념
즉, 어떠한 장치, 사용자 또는 네트워크 세그먼트도 신뢰하지 않고 잠재적 위협 요소로 처리하는 보안 모델로 네트워크 리소스에 엑세스하는 모든 장치와 사람은 인증 및 승인을 받아야 함.
→ 쿠버네티스에 ZTA(제로 트러스트 아키텍처) 적용을 위해서는 플랫폼 내에서 인증과 인가의 작동 방식을 이해해야 함.

참고 자료) https://www.hpe.com/kr/ko/what-is/zero-trust.html

 

✅ 쿠버네티스 클러스터란?
쿠버네티스의 클러스터는 컨테이너를 실행하는 노드의 집합으로, 쉽게 컴퓨터의 집합이라고 생각할 수 있다.
✅ 쿠버네티스 객체란?
YAML 구성 파일을 통해 정의되거나 구성될 수 있는 모든 엔터티

A User in K8S cluster

→ "User"은 인증 자격 증명을 가지고 있으며, 사람 또는 기계에 의해 제어되는 인증서가 부여된 계정

  1. 서비스 계정 (Service Account)
    • 쿠버네티스 기반 시스템 내부에서 생성되어 내부 서비스에 의해 사용됨
    • 쿠버네티스가 직접 관리함
  2. 일반 사용자 (Normal USer)
    • 외부 서비스에 의해 관리됨
    • But, 쿠버네티스는 일반 사용자 계정을 나타내는 객체(Object)를 가지고 있지 않기 때문에 API 호출을 통해 해당 계정을 클러스터에 추가할 수 없음
📂 관련 자료
https://velog.io/@cks8483/Kubernetes-Service-Account
https://jibinary.tistory.com/82#google_vignette

 

 

Authentication of Normal Users

🔐 인증 대상

클러스터 외부의 일반 사용자를 대상으로 하는 인증 방식으로, 사용자들은 보통 웹 혹은 쿠버네티스 내부/외부 등을 통해 접근할 수  있다.

🔍 인증 방법

쿠버네티스는 외부 기기 식별 정보(ex. TLS 인증서)를 사용하여 사용자를 식별할 수 있다.

사용자는 클러스터의 인증기관(CA)이 서명한 유효한 인증서를 가지고 있어야 인증이 가능하다.

→ 이 방식은 HTTPS 웹사이트가 사용자와 안전하게 통신하기 위해 TLS를 사용하는 방법과 유사

🧩 인증 처리 방법

쿠버네티스는 일반 사용자를 직접 관리하지 않고, 외부 시스템(제3자 서비스)이 사용자의 인증 정보(ex. 사용자 이름, 비밀번호 목록, 관리자 개인 키, 구글 계정 등)를 담당하여 관리한다.

이러한 외부 인증 시스템을 통해 사용자는 안전하게 쿠버네티스 클러스터에 접근할 수 있다.

 

 

Authentication of Kubernetes-Managed Users

쿠버네티스의 사용자 인증 방식

쿠버네티스는 클러스터 내부에서 실행되는 애플리케이션은 서비스 계정(Service Account)을 이용해 인증을 수행한다. 이 서비스 계정은 다양한 인증 방식(ex. 부트스트랩 토큰, JWT_JSON Web Token, 클라이언트 인증서 등)을 사용할 수 있고,  여러 인증 모듈이 순차적으로 시도되어 하나라도 성공하면 인증이 완료된다. 이 구조는 다양한 애플리케이션과 쿠버네티스 API 간 호환성을 높이는 데 기여한다.

 

  • 인증 실패 시: HTTP 상태코드 "401 Unauthorized"로 요청 거부됨
  • 인증 성공 시: 다음 단계로 인가(Authorization)가 수행 즉, 누군지 확인했으니 이제 무엇을 할 수 있는지 판단하는 단계로 넘어감

 

 

Authorization

🔍 인가 판단을 위한 정보

쿠버네티스는 사용자가 무엇을 할 수 있는지 판단하기 위해 REST API 요청에 담긴 속성들을 기준으로 한다. 이러한 속성 정보는 쿠버네티스 API 외에도 외부 접근 제어 시스템과 연동 가능하도록 설계 되었다.

[ REST API 요청에 포함되는 정보들 ]

  • user: 요청한 사용자 ID
  • group: 해당 사용자가 속한 그룹
  • namespace: 요청 대상 리소스가 속한 네임 스페이스
  • 요청 경로
  • HTTP 메서드: GET, POST, DELETE 등
📂 REST API란?
- API: 클라이언트와 웹 리소스 사이의 네트워크 통신을 위한 게이트웨이
- REST: 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미
- REST API: REST를 기반으로 서비스 API를 구현한 것

참고자료) https://junvelee.tistory.com/107

📌 쿠버네티스의 인가 모드

인가 모드 설명
RBAC (Role-Based Access Control) 사용자나 그룹에 역할(role)을 할당하여 리소스 접근 권한을 제어함.
가장 일반적이고 널리 사용됨.
ABAC (Attribute-Based Access Control) 사용자 속성, 리소스 속성, 동작 등에 기반해 JSON 정책 파일로 인가 제어.
유연하지만 복잡함.
Webhook 외부 인가 서버에 HTTP 콜백을 보내 인가 여부를 위임함.
조직 내부 시스템과 통합할 때 유용.
Node kubelet이 실행 중인 노드에 따라 인가를 수행.
주로 Pod가 노드 수준에서 특정 리소스에 접근할 때 사용.

 

 

Zero Trust Authentication and Authorization

제로 트러스트의 인증 및 인가

쿠버네티스에서 제로 트러스트 인증 및 인가가 제대로 동작하기 위해서는 서비스 메시(service mesh) 와 인그레스 컨트롤러(Ingress controller) 가 필요하다. 이 구성 요소들은 기기 식별 정보를 통한 인증 수행 및 쿠버네티스 API 요청에 대한 인가를 수행해주는 역할을 한다. 또한, 서비스 디스커버리, 트래픽 관리, 쿠버네티스 배포 상태 확인 등 다양한 부가 기능도 제공한다.

 

  1. 서비스 메시 (Service mesh)
    • 동-서 방향의 내부 애플리케이션 간 트래픽 관리
    • 쿠버네티스와 제로 트러스트 보안을 구현하는 데 적합하게 설계됨
      • 동-서 트래픽은 제어 평면(Control Plane)에 의해 제어됨.
      • 이는 다시 데이터 평면(Data Plane)에 의해 실제 트래픽 전달을 담당함.
  2. 인그레스 컨트롤러(Ingress controller)
    • 남-북 방향의 클러스터 내부와 외부 간 트래픽 관리
    • 인증 및 접근 제어의 관문 역할 수행
💡 서비스 메시, 인그레스 컨트롤러, 인증 기관(CA), 전체 공개 키 기반 구조(PKI)를 적절히 구성하는 것은 쿠버네티스 내에서 인증과 인가를 자동화하는 데 필수적이며, 제로 트러스트 아키텍처 구현의 핵심이 된다.

 

 

Summary

효과적인 인증 및 인가 기능 구현은 모든 컴퓨터 시스템의 보안에 필수이며, 쿠버네티스도 예외는 아니다. ZTA는 가능한 많은 백터에서 강력한 인증과 인가가 필요하다.

 

[ ZTA in K8S에서의 유의사항 ]

1. 현재 인증 컨텍스트 및 역할 검토

권한 부여 시에는 최소 권한의 원칙을 반드시 적용하여야 한다. 즉, 계정은 작업 수행에 필요한 권한만 부여받아야 한다.

 

2. 클러스터의 API 서버를 안전하게 구성한 후 애플리케이션 엔드포인트도 함께 보호

쿠버네티스의 역할 기반 권한 설정은 클러스터를 보호할 수는 있지만, 애플리케이션 자체를 보호하지는 못할 수 있다. 따라서, 서비스 NodePort, 포트 포워딩, 보안되지 않은 Ingress 경로 등을 통한 접근을 점검해야 한다.

728x90