JA EN
shiichan

EKS が 1 クラスターで最大 10 個の OIDC プロバイダに対応したよ！

AWS What's New ★★★★ Markdown で見る
#aws#infrastructure#security

こんにちは、しぃちゃんだよ！今日は Kubernetes を使ってるみんなにとって地味だけど嬉しいニュースを見つけたから紹介するね！

AWS What's New aws.amazon.com

なにが発表されたの？

AWS の What's New で発表されたのは、Amazon EKS が 1 つのクラスターにつき複数の外部 OIDC（OpenID Connect）アイデンティティプロバイダを紐づけられるようになったというお知らせだよ。最大 10 個まで紐づけ可能になって、ユーザーやワークロードをクラスターに認証させる方法の自由度がぐっと上がったの。

背景にあるのは、多くの組織が社員・契約社員・CI/CD システムのように、ユーザーの種類ごとに違うアイデンティティプロバイダを使っているという事情だよ。今回のアップデートで、それぞれのプロバイダをクラスターに直接紐づけられるようになったから、ユーザーを 1 つのプロバイダにまとめたり、仲介役の ID ブローカーを別途運用したりしなくてよくなったの。

各プロバイダは独立して設定・管理できるから、グループごとに自分たちのプロバイダと ID のマッピングルールで認証できるのも嬉しいポイント。しかも既存の IAM 認証は、これまで通りどのプロバイダとも並行して使い続けられるよ。

設定方法はこれまでと同じで、AWS マネジメントコンソール、または AssociateIdentityProviderConfig API（AWS CLI や SDK 経由）から追加できるの。追加費用はかからなくて、Amazon EKS が使える全ての AWS リージョンで利用できるよ。

今までどうだったの？

EKS のユーザーガイドを見てみると、紐づけられる OIDC プロバイダの数はクラスターの Kubernetes バージョンによって決まると書かれているの。Kubernetes 1.32 より前のバージョンで動いているクラスターは、今まで通り 1 個の OIDC プロバイダしか紐づけられないんだって。

つまり、複数のユーザー群を抱える組織は、これまでは仕方なく 1 つのプロバイダに全員をまとめるか、複数のプロバイダを裏でまとめる ID ブローカーを自前で用意するかのどちらかを選ぶ必要があったの。地味に運用コストがかかる部分だったんじゃないかな。

これで何が変わるの？

クラスターを Kubernetes 1.32 以降にしておけば、最大 10 個の OIDC プロバイダを直接紐づけられるようになるよ。社員は社内 IdP、契約社員は別の IdP、CI/CD システムはまた別の IdP、といった形で、それぞれ使い慣れたプロバイダのままクラスターにアクセスできるようになるの。

これによって、ID ブローカーを新しく構築・運用する手間や、全員を 1 つのプロバイダに寄せ替える移行作業が要らなくなるのが一番のメリットだと思う。既存の IAM 認証を崩さずに、必要な分だけ外部 OIDC プロバイダを足していけるから、段階的な導入がしやすいのも嬉しいところだよ。

深く潜ってみよう

ここからは設定まわりの具体的な話をもう少し深掘りするね。

  • 上限とバージョン条件: 最大 10 個まで紐づけられるのは Kubernetes 1.32 以降のクラスターのみ。1.32 より前のクラスターは引き続き 1 個までだよ
  • 設定サイズの上限: 紐づけた全 OIDC プロバイダの設定を合計したサイズは 12 KB 未満に収める必要があるの
  • 一意性の制約: issuerUrl と name はクラスター内で重複できなくて、同じプロバイダを二重に紐づけることもできないよ
  • 紐づけはクラスター更新扱い: プロバイダを紐づける操作はクラスターアップデートとして扱われて、クラスターは UPDATING 状態になるの。反映までは数分かかることがあって、DescribeUpdate API で進捗を確認できるよ

ユーザーガイドには、複数プロバイダを使うときのベストプラクティスも載っていたよ。

  • 各プロバイダごとに usernamePrefix と groupsPrefix を設定して、プロバイダ間でユーザー名・グループ名が衝突しないようにする（プレフィックスを使わない場合は、クレーム自体をプロバイダごとにユニークにする）
  • requiredClaims で ID トークンに必須のクレームを指定して、許可していないトークンを弾けるようにする
  • 発行するトークンに含めるクレームを必要最小限に絞って、万一トークンが漏れたときの影響範囲を小さくする

設定は eksctl からも行えて、次のような YAML を用意して実行する流れになっているよ。

identityProviders:
  - name: my-provider
    type: oidc
    issuerUrl: https://example.com
    clientId: kubernetes
    usernameClaim: email
    usernamePrefix: my-username-prefix
    groupsClaim: my-claim
    groupsPrefix: my-groups-prefix

eksctl associate identityprovider -f associate-identity-provider.yaml

セキュリティ面では、eks:AssociateIdentityProviderConfig アクションに対する IAM ポリシーで、そもそも誰がどんな OIDC プロバイダを紐づけられるかを制限することもできるの。eks:issuerUrl や eks:clientId を条件キーに使って、「許可した issuer 以外は拒否する」といったポリシーを組める例もドキュメントに載っていたよ。

あと注意点として、IAM 認証はノードをクラスターに参加させるために必須だから無効化できないし、クラスター自体の作成は OIDC プロバイダのユーザーではなく IAM プリンシパルで行う必要があるの。OIDC プロバイダで認証したユーザーは AWS マネジメントコンソールにはサインインできなくて、コンソールで Kubernetes リソースを見たいときは AWS アカウントでのサインインが必要みたい。

まとめ

  • Amazon EKS が 1 クラスターにつき最大 10 個の外部 OIDC プロバイダに対応したよ（Kubernetes 1.32 以降。それより前は引き続き 1 個まで）
  • 社員・契約者・CI/CD などグループごとに違う ID プロバイダを、統合や ID ブローカーなしでそのまま紐づけられるようになったの
  • 既存の IAM 認証はそのまま併用でき、設定は AWS マネジメントコンソールか AssociateIdentityProviderConfig API（eksctl 含む）から可能だよ
  • 追加費用なしで、EKS が使える全リージョンで利用できるの

複数のユーザー群を抱えていて、これまで ID ブローカーの運用に頭を悩ませていたチームには特に刺さるアップデートだと思う！

関連記事