この記事は LAPRAS Advent Calendar 2019 の4日目です．
AWS上にkubernetesクラスタを構築していると，Pod内のコンテナから，AWSのAPIを叩きたいことがある． そのためにはもちろんAWSの認証を通す必要があり，AWSのAccess Tokenとか，IAM Roleを使って認証を通すことになる．
一般的に，productionで運用するEC2の中に，IAM UserのAccess Tokenを置くことは推奨されず，大抵の場合はIAM Roleで解決すると思う．もちろん，kubernetesクラスタであっても，ノードはただのEC2なのでInstance Profileを使えばIAM Roleでの認証は可能になる． しかし，kubernetesはクラスタだ．もちろんノードはいっぱいあり，その上で様々なPodが動いている．ということは，ノードのインスタンスからIAM Roleでの認証をする場合，そのRoleは，クラスタ内で動くすべてのPodが要求する権限を保有する必要がある．これはかなり強大な権限を持つRoleになってしまう． おまけに，この状態だと，実はセキュリティ的にAWSへのアクセスを許可しないPodであっても，容易にAWSへの認証を通ってしまうことになる．
こういう状態を避けるために，kube2iamやkiamといったOSSが開発されてきた．
で，このkube2iamに結構なバグがあったため，kopsで構築していたkubernetesクラスタに関しては，kiamに載せ替えたことがあった．
しかし，kiamはmasterノードにPodを配置する必要があり，masterノードに手を入れられないEKSでは，kiamを使うことができなかった．
これを完全に解決する方法として，今年9月にIAM Role for Service Accountが発表された．
というわけで，EKS運用しているクラスタのIAM認証を，このIRSAに載せ替えた．
IRSAの仕組みについては，上記記事を参照してほしい．ここでは詳しい動作原理については説明しない．
続きを読む