はじめに
これは、Kubernetesアドベントカレンダー2の20日目の記事です。
これの話です。
ただし俺はもうEKS全然使ってないから意味ない件😢
なんの話？
待ってたとは
4年前に、AWSでコンテナ使ってる人ならお馴染みのaws/containers-roadmapにこんなIssue(もとい、Feature Request)を作りました。
また、これに関連するIssueとしてはその半年ほど前に作られていて
自分としてはこのIssueを立てる前から技術選定の時点でずっと悩んでいたポイントだったので、かれこれ5年近く待っていたことになります。ようやくリリースされて本当によかった。まあ今はいらないんだけど、、、
どんな内容か
これまでのEKSの課題点
EKSでクラスター管理者や運用者を指定する上で欠かせないのが、Kubernetesのユーザー/ロールとAWS IAMのマッピングです。マネージドKubernetesの便利ポイントとしてクラウドのユーザーアカウントとKubernetesクラスターの操作権限を関連づけられるというものがありますが、従来のEKSでは以下のようなKubernetesリソースを使って管理していました。
apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapAccounts: | [] mapRoles: | - "groups": - "system:bootstrappers" - "system:nodes" "rolearn": "arn:aws:iam::000000000000:role/dk-prd-mng-spot-eks-node-group-20230717021135172900000001" "username": "system:node:{{EC2PrivateDNSName}}" mapUsers: | - "groups": - "system:masters" "userarn": "arn:aws:iam::000000000000:user/inductor" "username": "inductor"
一方で、「クラスター自体をデフォルトで管理する」ための権限というのは、そのクラスターを作成したIAMロールに紐づいており、特にCloudFormationなどのユースケースを考えるとわかりやすいですが、CI/CDの自動化や、あるいは手動で適用する場合も自分の権限にはない強い権限でないとリソースの作成ができないため、一時的にロールを自分のユーザーとは違う状態で適用しますよね。これが厄介で、CIで新規作成されたEKSクラスターが誰もいじれないただの金食い虫になってしまう、と言った状態になりかねませんでした。後から追加されたカスタムリソースの機能を使えばどうにかこうにかいけそうですが、設計としては再現性に欠けるためいまいちですし、僕がZOZOでクラスター管理をしていた頃にはなかったのでやはり不便だなと感じていました。
TerraformやCDKを使う場合も作成時に指定をすればよいのですが、結局ConfigMapを手で書かないといけないですし、手間な上に解決策としては綺麗なやり方とは言えません。
そのため、AWSリソース作成時にパラメータとしてクラスターロールを指定できるような機能が欲しいと感じていました。
そこで今回出てきた新しい機能がこちらです。
EKS APIにアクセス管理用の機能が生えたので、それを通じて直接IAMプリンシパルによるKubernetes権限が定義できるようになりました。
authenticationModeにはCONFIG_MAP、API_AND_CONFIG_MAP、APIの3種類が指定できるのもいいですね。既存の構成を壊すことなく段階的に移行することもできますし、何かの理由でAPIモードを使いたくない場合も既存と同様の構成をとることができます。namespace adminを指定することもできるようになったので、マイクロサービス基盤の中でより綿密な権限管理ができるようになったと言えます。
詳しくはDeep Diveのセクションを見ると良さそうです。その他これに関して何か有益情報があれば教えてください。
それでは今日はこのへんで！
