Kubernetes（EKS）で各PodごとにIAMロールを管理するには、jtblin/kube2iamを使うのが一般的である。今回はそのkube2iamがどのような仕組みで動いているかを解説する。
TL;DR
- EC2のメタデータ取得（
169.254.169.254）をkube2iamのPodに流れるようにする（iptablesの編集） - kube2iamがリクエスト元Podに基づいてIAMロールを決定し、クレデンシャルを返す
- 後発のkiamよりも手軽に導入できる（ただし高負荷時に異なるロールが割り当てられる不具合も）
kube2iamの全体像
- EC2メタデータのリクエストを横取り
- EC2のIAMロールから別のIAMロールのクレデンシャルを生成
- 生成したクレデンシャルを返す
kube2iamのデプロイ
- kube2iamはDaemonset（各EC2インスタンス上で1つ以上動くPod）としてデプロイしている
- kube2iamがiptablesを触れるよう、SecurityContextを
privilegeにしてroot権限を渡す - 公式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よりもより速く、そしてこの不具合の解決をするためというの2つがある。）
より詳しくは海外の記事「IAM Access in Kubernetes: kube2iam vs kiam」でも解説されている。（本記事の参考）