Kubernetes 클러스터의 액세스 보호 및 인증 메커니즘
Kubernetes는 분산 시스템으로 여러 개의 노드에서 실행되며, 다양한 사용자와 프로세스가 클러스터에 접근합니다. 클러스터에 배포된 애플리케이션에 대한 액세스를 포함하여, 관리 작업을 위한 사용자의 접근을 안전하게 제어해야 합니다. 이 과정에서 Kubernetes의 authentication(인증)과 authorization(권한 부여) 메커니즘은 매우 중요한 역할을 합니다. 본 글에서는 authentication에 중점을 두고, Kubernetes 클러스터에 대한 안전한 접근을 보장하기 위한 방법을 다룹니다.
사용자 및 서비스 유형
Kubernetes 클러스터에서는 여러 유형의 사용자가 존재합니다. 이들 사용자는 클러스터에서 다양한 작업을 수행하며, 각기 다른 방식으로 클러스터에 액세스합니다:
- 관리자: 클러스터의 관리 작업을 수행하는 사용자는 클러스터의 설정을 변경하거나 유지보수 작업을 진행합니다.
- 개발자: 애플리케이션을 배포하거나 테스트하기 위해 클러스터에 접근하는 사용자입니다.
- 애플리케이션 사용자: 클러스터에서 배포된 애플리케이션에 접근하는 최종 사용자입니다. 이는 클러스터 내부에서 관리되는 것이 아니라 애플리케이션 자체에서 관리됩니다.
- 타사 애플리케이션: 클러스터와 외부 시스템 간의 통합을 위해 클러스터에 접근하는 외부 애플리케이션입니다.
이 글에서는 관리자와 개발자 같은 내부 사용자의 인증과 권한 부여를 다루며, 클러스터에 액세스하는 서비스 계정도 주요 사용자로 다룹니다. 애플리케이션 사용자는 애플리케이션 내에서 관리되므로 본 논의에서는 제외됩니다.
Kubernetes 사용자 관리

Kubernetes 자체는 사용자 계정을 직접 관리하지 않습니다. 대신, Kubernetes는 외부 인증 시스템(예: LDAP, OAuth2, 인증서, 토큰 파일)에 의존하여 사용자 인증을 처리합니다. 이 외부 시스템에서 관리되는 사용자 세부 정보를 바탕으로 Kubernetes는 API 서버를 통해 인증을 수행합니다. 따라서 Kubernetes 내에서 직접 사용자를 생성하거나 삭제하는 것이 불가능하며, 서비스 계정만 Kubernetes 내에서 관리할 수 있습니다. 서비스 계정은 애플리케이션이나 프로세스가 Kubernetes 클러스터에 접근할 수 있도록 하는 계정입니다. 이러한 서비스 계정은 Kubernetes API를 통해 생성되고 관리됩니다.
Kubernetes API 서버 및 인증

- Kubernetes 클러스터 내에서 모든 사용자와 애플리케이션의 액세스 요청은 Kube API 서버를 거칩니다. API 서버는 사용자의 요청을 처리하기 전에 인증을 수행합니다. 따라서 클러스터에 대한 모든 요청은 먼저 API 서버에 의해 인증됩니다.
인증 메커니즘

Kubernetes는 여러 가지 인증 메커니즘을 제공합니다. 주요 인증 방법은 다음과 같습니다:
- 정적 패스워드 파일: 사용자 이름과 패스워드 목록을 포함하는 파일을 사용하여 인증을 수행합니다.
- 정적 토큰 파일: 사용자 이름과 토큰 목록을 포함한 파일을 사용하여 인증합니다.
- TLS 인증서: 클라이언트 인증을 위해 인증서를 사용할 수 있습니다.
- 외부 인증 프로토콜: LDAP, Kerberos 등 외부 시스템을 통해 인증을 처리할 수 있습니다.
이 외에도 Kubernetes는 다양한 인증 메커니즘을 제공하며, 사용자는 필요에 따라 인증 방식을 선택하고 설정할 수 있습니다.
기본 인증 (Basic Authentication)

- 기본 인증 방식은 가장 간단한 형태의 인증 방식으로, 정적 패스워드 파일을 사용합니다. 이 방법은 다음과 같은 절차로 구성됩니다.
- 사용자 정보 파일 생성: CSV 파일 형식으로 사용자 이름, 암호, 사용자 ID가 포함된 목록을 생성합니다.

- Kube API 서버에 옵션 전달: 이 파일은 Kube API 서버의 옵션으로 전달됩니다. 이 옵션을 설정하려면 Kube API 서버를 다시 시작해야 합니다.

- 인증 절차: 사용자는 클러스터에 요청을 보낼 때 기본 인증 방식을 사용하여 자신의 사용자 이름과 패스워드를 제출합니다.
주요 특징은 다음과 같습니다.
- 파일 기반 인증: 사용자 이름과 패스워드를 포함한 정적 파일을 사용하여 인증을 수행합니다.
- 보안상 위험: 패스워드가 평문으로 저장되므로 보안 위험이 존재합니다. 실제 환경에서는 권장되지 않는 방식입니다.
토큰 인증 (Token Authentication)

정적 토큰 파일을 사용하여 인증을 수행하는 방식입니다. 이 방식은 패스워드 대신 토큰을 사용하여 인증을 처리합니다. 이 방법은 기본 인증과 유사하지만, 사용자는 패스워드 대신 Authorization Bearer Token을 사용하여 요청을 보냅니다. 주요 특징은 아래와 같습니다.
- Bearer Token 사용: 요청에 포함된 토큰을 통해 인증을 수행합니다.
- 보안성: 패스워드보다 보안적으로 더 안전하며, 토큰을 사용하여 인증할 수 있습니다.
외부 인증 프로토콜
Kubernetes는 LDAP 또는 Kerberos와 같은 외부 인증 시스템을 통해 인증을 처리할 수 있습니다. 이를 통해 조직에서 사용하는 디렉터리 서비스나 보안 인증 시스템과 통합할 수 있습니다. 이 방식은 대규모 클러스터에서 유용하며, 외부 시스템에서 관리되는 사용자 정보를 활용합니다.
Kube API 서버 설정
Kubernetes 클러스터의 Kube API 서버는 다양한 인증 메커니즘을 처리할 수 있도록 설정할 수 있습니다. kubeadm을 사용하여 클러스터를 설정한 경우, Kube API 서버의 설정 파일을 수정하여 인증 메커니즘을 추가하고, 이를 통해 클러스터의 인증을 구성할 수 있습니다.
- Kube API 서버 설정: 설정 파일에서 인증 방식을 정의하고, 이를 kubeadm 툴을 사용하여 Kube API 서버에 적용합니다.
- 서비스 재시작: 설정을 변경한 후에는 Kube API 서버를 재시작하여 변경 사항을 적용해야 합니다.
Kubernetes 인증 보안 고려 사항
정적 패스워드 파일이나 정적 토큰 파일을 사용하는 방식은 보안상 위험이 있습니다. 해당 방식은 기본적인 인증 방법을 제공하지만, 보안이 중요한 환경에서는 사용을 피하는 것이 좋습니다. 보안적인 측면에서는 TLS 인증서나 외부 인증 프로토콜을 사용하는 것이 더 안전합니다.
'Kubernetes & EKS > k8s 공부 기록' 카테고리의 다른 글
| [kubernetes] Role Based Access Controls (RBAC) (0) | 2025.04.19 |
|---|---|
| [kubernetes] Authentication & Authorization 02 (0) | 2025.04.19 |
| [kubernetes] EKS 파드 스케줄링: topologySpreadConstraints (0) | 2025.03.31 |
| [kubernetes] EKS 파드 스케줄링: podAntiAffinity (0) | 2025.03.31 |
| [kubernetes] Taint and Tolerance (0) | 2025.03.31 |