배경
AWS EKS Cluster 의 새로운 인증 방식인 AccessEntry 에 대한 정리 한다.
내용
AWS-AUTH
보통 엔지니어가 AWS EKS Cluster 를 구성할 때는 아래와 같은 방법들이 있다.
•
Hashicorp Terraform
•
AWS 콘솔에서 수동 구성
•
AWS CloudFormation
•
YAML {eksctl}
아마도 어떤 방법이였던간에 AWS EKS Cluster 를 배포한 이후, 해당 EKS 로 접근을 시도하면 Access Denied 가 발생할 수 있다.
엔지니어의 IAM 권한이 AdministratorAccess 포함되어있다고해도 AWS 콘솔에서 EKS Cluster 의 리소스를 확인 해보면 아래처럼 주요 리소스들은 볼 수 없다.
당연히 해당 EKS 로 API 호출-확인할 수 있는 kubectl 도 불가능하다.
그렇기 때문에 EKS 로의 접근을 할 수 있는 인증이 필요하다.
이럴때 aws-auth 라는 Configmap 에 IAM 을 추가하게 된다.
이 방식은 굉장히 비효율적으로 느껴지고, aws-auth 의 Configmap 을 건든다는 것에서 부터 반감이 생긴다.
만약 엔지니어가 본인의 IAM 으로 로컬에서 Terraform 혹은 AWS 콘솔에서 EKS 를 배포시에는 aws-auth 에 본인의 IAM 만 추가될 수 있다.
이 경우 담당 엔지니어가 조직에서 퇴사or이탈 후 IAM 이 삭제될 경우 해당 EKS 로는 아무도 접근 할 수 없게 된다.
특히 Terraform 으로 모듈을 만들때 이 aws-auth 는 한번쯤 스트레스로 다가올 수 있다.
국/내외를 막론하고 비슷한 이슈에 대해 고민하는 것을 확인해볼 수 있다.
참고 링크
이제 EKS 로의 접근을 위해서 aws-auth Configmap 에 IAM 을 추가하게 되면 대략 아래와 같은 흐름으로 EKS 에 접근이 가능해진다.
AccessEntries
하지만, 이제 드디어 AWS 에서 aws-auth 에 대한 지원을 중단하고 정식으로 새로운 인증 방식을 추가 했다.
새로운 인증 방식은 Configmap 과는 전혀 별개로 인증하게 된다.
이제 Configmap 을 수정하고 운영&관리할 필요가 없어졌다.
참고 문서 링크
AWS 콘솔에서는 AccessEntries 메뉴가 존재하고, 해당 메뉴로 접근해서 확인 할 수 있으며 더 직관적이고 쉽게 관리할 수 있다.
AWS EKS 에서 지원하는 인증 방식은 총 3가지가 되었다.
•
EKS API
•
EKS API and ConfigMap
•
ConfigMap
기존에 EKS Cluster 의 인증방식이 ConfigMap 이였다면, 이제 EKS API and ConfigMap 으로 변경 되었다.
AccessEntries 인증은 아래와 같은 흐름으로 EKS 에 접근이 가능해진다.
