쿠버네티스 API 서버의 인증 인가 처리 단계는 다음과 같다.
쿠버네티스 API 서버는 하나 이상의 인증 플러그인을 구성할 수 있고
이 플러그인 중에서 인증 요청을 처리하면 나머지 플러그인의 호출을 뛰어넘어서
인가 단계를 진행하게 된다.
EKS는 Webhook Token Authentication과 OIDC Token, Service Account Token을 지원한다.
인가 단계에서는 RBAC 플러그인 등을 거치면서
해당 요청이 특정 리소스에 대해 허용되었는지 검사하고,
Adminission Control을 통해서 분산저장소인 ETCD에 저장한다.
쿠버네티스의 권한 인가 체계인 RBAC은
보안주체인 사람을 나타내는 user나 group과
애플리케이션이 사용하는 보안 주체(Subject)인 Service Account를 특정 리소스에 대해서 어떤 액션을 수행할 수 있는지를 정의한 Role이나 Clusterrole과 Role Binding이나 Clusterrole Binding으로 연결해서 권한 인가 체계를 구성하게 된다.
인증인가 체계를 이해하기 위해 kubectl 명령
실행 시 흐름을 알아야 하는데, 흐름에 대한 이미지는 다음과 같다
여기서, 이 값을 디코딩 하면 Secure token service의 GetCallerIdentity를 호출하는 Pre-Siged URL인 것을 확인할 수 있다.
여기서, Kubectl의 Client-Go 라이브러리는 이 Pre-Siged URL을 Bearer Token으로 EKS API Cluster Endpoint로 요청을 보내면 IAM-Authentication Server는 Token Authentication Webhook이 호출되고 STS GetCallerIdentity 호출해서 해당 호출에 대한 인증을 거친 뒤 UserID와 User나 Role에 대한 ARN을 반환하게 된다.
Amazon EKS 마이그레이션 요점정리 - 강인호 솔루션즈 아키텍트, AWS :: AWS Summit Korea 2022