8주차. 쿠버네티스 인증, 인가

kube-apiserver

아키텍처

출처 : https://netpple.github.io/docs/deepdive-into-kubernetes/k8s-certificates


출처 : 쿠버네티스 인 액션 11장


출처 : https://netpple.github.io/docs/deepdive-into-kubernetes/k8s-apiserver

인증 절차

1. 사용자가 kubectl 명령어 수행
2. kubectl → POST 요청 → kube-api-server의 HTTP 핸들러에 요청 처리

3. kube-api-server에 구성된 인증(Authentication) 플러그인 수행

인증 요청하는 클라이언트 종류
- 실제 사람(사용자)
- Pod(파드내에서 실행되는 애플리케이션)

방법
- 클라이언트의 인증서
- HTTP 헤더로 전달된 인증 토큰
- 기본 HTTP 인증
- 기타

추출 정보 : 사용자 이름, 사용자 ID, 그룹 (해당 데이터는 다음 인가 단계에서 사용됨)

4. 인가(Authorization) 플러그인 수행

API 서버를 1개 이상의 인증(Authentication) 플러그인으로 구성 가능

Authentication vs Authorization

https://www.mobile-mentor.com/insights/understanding-authentication-and-authorization/

kubernetes authentication (쿠버네티스 인증)

출처 : https://happycloud-lee.tistory.com/259

authentication 방식

1) TLS (인증서)
2) Token (ServiceAccount)
3) Proxy

사용자 종류( categories of users)

1) 실제 사용자
2) Pod(애플리케이션)

authentication 방식별 장단점

공식문서

https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes

2가지 카테고리의 유저가 있음

Service Account
normal user

Kubernetes는 일반 사용자 계정(normal user)을 나타내는 객체를 가지고 있지 않음.

API 호출을 통해 일반 사용자를 추가할 수는 없지만,
클러스터의 인증 기관(CA)에 의해 서명된 유효한 인증서를 제시하는 모든 사용자는 인증된 것 처리
Kubernetes는 인증서의 'subject'에 있는 일반 이름 필드(예: "/CN=bob")에서 사용자 이름을 결정

Service Account 은 Kubernetes API에서 관리하는 사용자
특정 네임스페이스에 바인딩
API 서버에 의해 자동 생성 or 수동 생성 가능
Pod에 Secret으로 Token이 마운트됨

쿠버네티스 Token 방식 인증 (Service account JWT based authentication)

kubectl describe 명령어 결과 > Volume > secret 볼륨이 자동으로 연결되어 있음

kubectl describe pod 결과 > Mounts > secret 볼륨이 마운트된 정보

kubectl exec 명령어로 pod에 마운트된 secret 파일 목록 조회

네임스페이스 생성시 SA가 자동으로 생성되는거에 대해서 쿠버네티스 코드를 확인해보면 되지 않나?

X.509 인증서 방식 인증

TLS, 인증서 개념 정리

사용자 유형	인증방식
외부사용자	인증서(Certificate)
외부사용자	Bearer토큰
쿠버네티스의 그룹	시스템 할당
쿠버네티스의 그룹	사용자 지정 그룹
서비스어카운트(SA)	ServiceAccount