Udemy CKA 강의 정리 139: Authentication

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

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

---

이미 살펴본 바와 같이 Kubernetes 클러스터는 물리적 또는 가상의 여러 노드와 함께 작동하는 다양한 컴포넌트로 구성됩니다.

Accounts

유저 중에 관리 작업을 수행하기 위해 클러스터에 액세스하는 관리자, 애플리케이션을 테스트하거나 배포하기 위해 클러스터에 액세스하는 개발자가 있습니다. 클러스터에 배포된 애플리케이션에 액세스하는 엔드 유저도 있고 통합 목적으로 클러스터에 액세스하는 타사 애플리케이션도 있습니다.

이 섹션에서는 내부 컴포넌트 간의 통신을 보호하고 authentication 및 authorization 메커니즘을 통해 클러스터에 대한 관리 액세스를 보호하여 클러스터를 보호하는 방법에 대해 설명합니다. 이번 강의에서는 authentication 메커니즘을 사용하여 Kubernetes 클러스터에 대한 액세스를 보호하는 데 중점을 둡니다. 위에서 우리는 클러스터에 액세스할 수 있는 여러 사용자에 대해 이야기했습니다. 클러스터에 배포된 애플리케이션에 액세스하는 엔드 유저의 보안은 내부적으로 애플리케이션 자체에서 관리합니다. 따라서 우리는 이것은 논의에서 제외합니다.

우리의 초점은 관리 목적으로 Kubernetes 클러스터에 대한 사용자의 액세스에 있습니다. 따라서 관리자 및 개발자와 같은 사람과 클러스터에 대한 액세스가 필요한 다른 프로세스 또는 서비스 또는 애플리케이션과 같은 로봇의 두 가지 유형의 사용자를 고려할 수 있습니다.

Kubernetes는 자체적으로 사용자 계정을 관리하지 않습니다. 이러한 사용자를 관리하기 위해서 사용자 세부 정보가 있는 파일이나 인증서 또는 LDAT와 같은 타사 indentity service와 같은 외부 소스에 의존합니다. 따라서 Kubernetes 클러스터에서 사용자를 생성하거나 이와 같은 사용자 목록을 볼 수 없습니다.

그러나 서비스 계정의 경우 Kubernetes에서 관리할 수 있습니다. Kubernetes API를 사용하여 서비스 계정을 만들고 관리할 수 있습니다. 서비스 계정에 대해 더 자세히 살펴보고 연습할 수 있는 service accounts 섹션이 있습니다. 이번 강의에서는 쿠버네티스의 사용자에 초점을 맞춥니다.

kubectl tool을 통해 클러스터에 액세스하든 API를 직접 액세스하든 관계없이 모든 사용자 액세스는 API 서버에서 관리합니다. 이러한 모든 요청은 Kube API 서버를 통과합니다. Kube API 서버는 요청을 처리하기 전에 먼저 요청을 인증합니다.

Authentication Mechanisms

Kube API 서버는 어떻게 인증할까요? 구성할 수 있는 다양한 인증 메커니즘이 있습니다. static password file에 사용자 이름 및 password 목록이 있거나, static token file 에 사용자 이름 및 토큰 목록이 있거나, 인증서를 사용하여 인증할 수 있습니다. 또 다른 옵션은 LDAT, Kerberos 등과 같은 타사 인증 프로토콜에 연결하는 것입니다.

Authentication Mechanisms - Basic

가장 이해하기 쉬운 static password 및 토큰 파일부터 시작하겠습니다. 가장 간단한 형태의 인증입니다.

csv 파일에 사용자 및 password 목록을 생성하고 이를 사용자 정보의 소스로 사용할 수 있습니다. 파일에는 암호, 사용자 이름 및 사용자 ID의 세 열이 있습니다. 이 파일 이름을 Kube API 서버에 대한 옵션으로 전달합니다. Kube API 서버 서비스와 이 과정의 앞부분에서 살펴본 다양한 옵션을 기억하나요? 여기서 이 옵션을 지정해야 합니다.

kube-apiserver configuration

이러한 옵션을 적용하려면 Kube API 서버를 다시 시작해야 합니다. kubeadm tool을 사용하여 클러스터를 설정한 경우, Kube API 서버 파드 definition 파일을 수정해야 합니다.

이 파일을 업데이트하면 kubeadm tool이 자동으로 Kube API 서버를 다시 시작합니다.

Authenticate User

API 서버에 접속하는 동안 basic credentials을 사용하여 인증하려면 다음과 같이 curl 커맨드에 사용자와 암호를 지정합니다.

우리가 본 user-details.csv 파일에서 선택적으로 사용자를 특정 그룹에 할당하기 위한 그룹 세부 정보가 포함된 네 번째 열을 가질 수 있습니다.

마찬가지로 static password 파일 대신 여기에 static token 파일을 사용할 수 있습니다. password 대신 토큰을 지정하면 됩니다. 토큰 파일을 option token auth file로 Kube API 서버에 전달하고 인증하는 동안 토큰을 요청에 대한 authorization bearer token으로 지정합니다.

이번 강의는 여기까지입니다. 사용자 이름, password 및 토큰을 일반 텍스트로 static 파일에 저장하는 이 인증 메커니즘은 안전하지 않으므로 권장되지 않습니다. 하지만 이것이 쿠버네티스 인증의 기본을 이해하는 가장 쉬운 방법이라고 생각했습니다. 앞으로 다른 인증 메커니즘을 살펴보겠습니다. 또한 kubeadm setup에서 이 작업을 시도하는 경우 auth 파일을 전달할 볼륨도 고려해야 한다는 점을 언급하고 싶습니다. 이에 대한 자세한 내용은 다음 문서에서 확인할 수 있으며 새 사용자에 대한 authorization를 설정해야 합니다. authorization에 대해서는 이 과정의 뒷부분에서 살펴볼 것입니다.