5분만에 이해하는 kube2iam의 구조

Kubernetes (EKS)에서 각 포드별로 IAM 역할을 관리하려면 jtblin/kube2iam을 사용하는 것이 일반적입니다. 이번에는 그 kube2iam이 어떤 구조로 움직이고 있는지를 설명한다.

TL;DR

EC2 메타데이터 가져오기( 169.254.169.254 )를 kube2iam 포드로 흐르게 하기(iptables 편집)

kube2iam이 요청 소스 포드를 기반으로 IAM 역할을 결정하고 자격 증명을 반환합니다

후발 kiam보다 간편하게 도입할 수 있다(단, 고부하 시에 다른 롤이 할당되는 불량도)

kube2iam의 전체 이미지

EC2 메타 데이터 요청 가로 채기

EC2의 IAM 역할에서 다른 IAM 역할의 자격 증명 생성

생성 된 자격 증명을 반환합니다

kube2iam 배포

kube2iam은 Daemonset (각 EC2 인스턴스에서 하나 이상 실행되는 Pod)으로 배포됩니다

kube2iam이 iptables를 터치하도록 SecurityContext를 privilege로 설정하여 루트 권한 전달

공식 Github에 yaml의 예이 있습니다

Helm도 Stable로 공개 됨

EC2 메타데이터

인스턴스 메타데이터 AWS 문서에서 알 수 있듯이 /iam/security-credentials/role-name에 요청하면 EC2 인스턴스에 할당 된 IAM 역할의 자격 증명을 얻을 수 있습니다.
AWS계의 대부분의 라이브러리는, 인증 정보가 지정되어 있지 않는 한, 이렇게 메타데이터 API로부터 자격 증명을 취득하고 있다.

kiam과의 차이

kube2iam 외에도 uswitch/kiam도 있습니다. kube2iam이 2016년에 등장해, 그 후 발로서 2017년에 kiam이 등장했다.

kiam의 특징은 「Node 자체가 IAM 롤을 가지지 않는다」 「Daemonset로서 기동하고 있는 Agent로부터 Master에 리퀘스트한다」라고 하는 것이 있다. 보다 보안을 의식한 설계이지만, 셋업의 간편함으로는 kube2iam이 우세로 되어 있고, GitHub의 스타수도 kube2iam이 많다. (kube2iam 998 : kiam 415)



kube2iam에는 고부하 시에 다른 역할이 할당된다는 Issue도 있어, 그러한 문제를 고려하면 kiam도 옵션에 들어간다. (kiam의 컨셉으로 kube2iam보다 빠르고, 이 버그를 해결하기 위한 두 가지가 있다.)

보다 자세한 것은 해외의 기사 「IAM Access in Kubernetes: kube2iam vs kiam」에서도 해설되고 있다. (본 기사의 참고)