• 쿠버네테스 클러스터는 다중 노드와 물리적, 가상적, 그리고 다양한 구성 요소로 함께 작동하는 구성 요소로 구성됨

1. 관리자인 유저는 관리 업무를 수행하기 위해 클러스터에 엑세스
2. 개발자는 앱을 테스트하거나 배포하기 위해 클러스터에 엑세스
3. 클러스터에 배포된 응용 프로그램에 액세스하는 엔드유저
4. 통합 용도를 위해 클러스터에 액세스하는 타사 응용 프로그램

이들의 액세스는 어떤 인증과 승인을 거치는가?

💡 enduser는 배포된 응용프로그램 자체에서 관리 되니 논외(클러스터 접근 X)

두 타입의 유저만 남음
1. User (관리자, 개발자)
2. Bots (Service Accounts) - 위에서 말한 타사 응용 프로그램 등

🪪 Account

• K8S는 사용자 계정을 직접 관리하지 않음
• 외부 소스에 의존함
  • LDAP (타사 ID 서비스)
  • 사용자 세부 정보나 인증서가 있는 파일 등
• K8S 클러스터에서 사용자를 생성하거나 리스트를 볼 수 없음

하지만 위 이미지와 같이 serviceaccount 라는 K8S API를 이용해 서비스 계정을 생성하고 관리 가능

👬 User(Admin, Developers)

• 모든 사용자 액세스는 API 서버에 의해 관리된다.
• kubectl 툴이나 API서버에 직접 액세스 하던 모든 요청이 API 서버로간다.
• kube-apiserver는 요청을 처리하기 전에 인증을 함

📋 Auth Mechanisms (인증 매커니즘)

1. Static Password File
2. Static Token File
3. Cetificates
4. Identity Service (LDAP, Kerberos)

| Auth Mechanisms - Basic

# user-detail.csv

password123,user1,u0001
password123,user2,u0002
password123,user3,u0003
password123,user4,u0004

• CSV 파일에 사용자 목록과 암호 작성
• 그걸 사용자 정보의 소스로 사용
• 세 개의 열(암호, 사용자 이름, ID)로 구성

# kube-apiserver options
--basic-auth-file=user-details.csv

• 파일 이름을 API 서버로 넘겼음
• 이런 옵션이 실행 되려면 kube-apiserver를 다시 시작 해야한다

👆🏻 왼쪽이 바이너리, 오른쪽이 kubeadm 파일

• kubeadm 툴은 파일을 업데이트하면 자동으로 KubeAPI 서버 재시작

기본 자격 증명을 이용해 API 서버에 액세스 가능!

• csv 파일 사용자 정보와 함께 선택적으로 네 번째 열에 그룹 정보가 있어 특정 그룹에 사용자 할당 가능

• 정적 암호 대신 토큰 사용 가능!
• 토큰 파일도 마찬가지로 --token-auth-file=user-details.csv 옵션으로 API 서버에 넘겨 줘야 함