クラスターの OIDC 認証を設定する

注記

これは beta 機能で、beta_user 権限を付与されたアカウントのみ利用できます。Portal にこのセクションが表示されない場合は、FKE チームに連絡して beta プログラムへの参加を依頼してください。

チーム全体で 1 つの admin kubeconfig(client certificate)を共有する代わりに、Managed GPU Cluster を会社の既存の Identity Provider(IdP、Keycloak、Azure AD、Okta、または標準準拠の OIDC provider)に接続できます。設定後、各メンバーは自分の SSO アカウントでクラスターにログインします。

注記

この機能は authentication(誰であるかの確認)のみを扱います。authorization(何ができるか)は Kubernetes RBAC で別途設定する必要があります。OIDC を有効化した後、ログインに成功しても RoleBinding がない user は kubectl get pods などのコマンドで 403 Forbidden になります。これは想定どおりの動作で、設定エラーではありません。

この設定は、admin kubeconfig をすでに持っている Cluster Admin が行います。適用されるのは kube-apiserver の認証層のみで、ノードや pod は再起動されないため、実行中の GPU workload(training、inference など)は中断されません。設定はいつでも更新・削除できます。

この機能を使うべき人

役割	説明
Cluster Admin	GPU クラスターを管理し、admin kubeconfig(client certificate)を保有 — この設定を行う
DevOps / MLOps Engineer	GPU workload を使うチームのアクセス制御を担当 — 通常、FKE チームに beta 登録を依頼する担当者

1. SSO / OIDC セクションを開きます。

   AI infrastructure → Managed GPU cluster に移動し、設定したいクラスターを開き、Essential properties タブで SSO / OIDC セクションまでスクロールします(設定するまで Status は Disabled と表示されます)。Edit を選択します。

   

2. 基本的な接続情報を入力します。

   Edit を選択すると SSO / OIDC 設定フォームが開き、Enable SSO / OIDC トグルは既定で OFF になっています。ON にすると(下のフィールドが有効になります)、次を入力します。

   • Issuer URL(必須): Identity Provider のベースアドレス — クラスターがログイントークンの検証をリクエストする先です。https:// から始まる完全な URL を、末尾に ?(クエリ文字列)や #(フラグメント)を付けずに入力します。通常は IdP の "Realm settings" または "OIDC discovery" ページからそのままコピーします。
     • Keycloak: https://keycloak.mycompany.com/realms/production
     • Azure AD: https://login.microsoftonline.com/{tenant-id}/v2.0
     • Okta: https://mycompany.okta.com/oauth2/default
   • Client ID(必須): IdP に登録した「アプリケーション」(このクラスター)の識別子です。例えば Keycloak では Clients → Create client で作成します。1 つの値のみ入力できます — 現在、1 クラスターに対して複数の Client ID はサポートされていません。
   • Username Claim(任意): ログイントークン内で Kubernetes の username として使うフィールドです。既定値は email です。フィールドを完全に空にすると sub(IdP の内部 ID。通常読みにくい UUID)が使われます。時間が経っても変わらない安定した値を持つ claim を選んでください — email が変わると既存の RBAC binding が一致しなくなります。
   • Groups Claim(任意): user が所属する group の一覧を含むトークン内のフィールドで、個人単位ではなく group 単位で権限を割り当てる際に使います(例: 「MLOps team」や「GPU admins」)。一般的な値は groups(Keycloak/Okta の既定)や client_roles(Keycloak の client roles)です。group ベースの認可が不要な場合は空のままにします。

   

   ヒント

   クラスターの control plane から Issuer URL へのネットワーク経路が必要です。IdP が社内ネットワークにある場合は、保存前にクラスターから到達できることを確認してください。

3. 詳細設定を行います(任意)。

   以下の 4 つのフィールドはすべて任意で、互いに独立しています — 1 つを入力しても他を入力する必要はありません。

   • Username Prefix: 通常 : で終わる短い文字列で、Kubernetes にマッピングする際に Username Claim の値の前に自動的に付加されます。例えば oidc: を設定すると、email = an.nguyen@mycompany.com は Kubernetes の username oidc:an.nguyen@mycompany.com になります。SSO user とシステム user やその他の方法で作成された user を区別しやすくなり、特に複数チームが同じ GPU クラスターを共有する場合に便利です。system: から始めることはできません — この prefix は Kubernetes のシステム group 用に予約されています。空のままにすると、Kubernetes は claim の値をそのまま username として使うため、他の user と重複するリスクがあります。
   • Groups Prefix: Username Prefix と同様の考え方を group 名に適用します。例えば oidc: を設定すると、group gpu-admins は Kubernetes 内で oidc:gpu-admins になります。同じ system: の制限が適用されます。
   • CA Bundle (PEM): クラスターが IdP への HTTPS 接続を信頼するために使う CA 証明書です。IdP が自己署名証明書や社内 CA を使っている場合にのみ必要です — Let's Encrypt や DigiCert などのパブリック CA を使っている場合は空のままにします。.pem または .crt ファイルの内容全体を、-----BEGIN CERTIFICATE----- から -----END CERTIFICATE----- まで、間に有効な base64 本体を含めて貼り付けます。
   • Required Claims: IdP 上で有効なアカウントを持つ user であっても、ログイントークンが一致しなければならない条件のリストです。+ Add claim を選択し、各行に Claim(トークンのフィールド名)と Value(一致すべき値)を入力します — 各行で両方のフィールドが必須で、同じ claim 名を複数行で宣言することはできません。例えば Claim hd、Value mycompany.com を設定すると、IdP が個人の Gmail アカウントも扱っている場合でも、mycompany.com ドメインの Google Workspace アカウントのみログインできます。

   

4. Save を選択します。

   変更が適用される間、クラスターは処理中の状態に切り替わります — クラスター詳細ページ上部の全体ステータスで進行状況を確認できます。クラスターが Succeeded/Running に戻ると設定が有効になり、その間、実行中だった GPU workload は中断されません。

結果

チームは kubelogin/OIDC plugin を使った kubeconfig を取得し、共有の admin kubeconfig の代わりに自分の SSO アカウントで GPU クラスターにログインできるようになります。結果として得られる username または group(設定した prefix を含む)に対応する RBAC binding(RoleBinding/ClusterRoleBinding)は、admin kubeconfig を使って自分で作成する必要があります。この手順は Portal では自動化されません。

エンドユーザー側の設定手順、RBAC の例、GPU quota のガイダンスは SSO でクラスターにログインする を参照してください。

設定の更新・削除

いつでも SSO / OIDC セクションで再度 Edit を選択すると、既存の設定を変更できます。

• 値を更新する — 任意のフィールドを変更し(例: IdP 側の変更後に Issuer URL や Client ID をローテーションする)、Save を選択します。
• 設定を削除する — Enable SSO / OIDC トグルを OFF にして Save を選択します。確認ダイアログが表示され、変更が適用されると(数分以内に)現在の OIDC ログインセッションがすべて無効になること、admin kubeconfig(client certificate)には影響しないことが警告されます。続行する場合は確認、取りやめる場合はキャンセルを選択します。

設定を削除しても admin kubeconfig には影響せず、いつでもフォールバックできます。実行中の GPU workload にも影響しません。

よくある問題

問題	原因 / 対処方法
"This feature isn't available for your account yet"	アカウントに beta_user 権限がまだ付与されていません — FKE チームに連絡して登録してください
Save や delete を選択したときに "This cluster is still processing" と表示される	クラスターが別の変更を処理中です — 数分待ってから再試行してください
設定が正しく見えるのに SSO ログインが拒否される	RBAC binding が正しい username/group(設定した prefix を含む)と一致しているか、トークンに設定した Required Claims がすべて含まれているか確認してください
system: から始まる Prefix を入力できない	これは意図的な制限です — Kubernetes のシステム group との衝突を防ぎ、権限昇格のリスクを避けるためです
フィールド(Issuer URL、CA Bundle など)が無効なのにエラーメッセージが表示されない	現在の beta 版の既知の制限です — フィールドの枠が赤くなるだけで説明文は表示されません。必要な形式(Issuer URL は query/fragment なしの HTTPS、CA Bundle は有効な PEM)を再確認してください
実行中の GPU workload(training、inference ジョブ)への影響が心配	OIDC の有効化・更新・削除は kube-apiserver の認証層にのみ影響し、ノードや pod は再起動されないため、GPU workload は中断されません

ヒント

• チーム全体が依存する production クラスターに適用する前に、まず staging の GPU クラスターで IdP 接続を試してください。
• admin kubeconfig はフォールバックとして保持してください — OIDC の有効化・無効化による影響を受けません。
• Required Claims でログインできる範囲を絞り込んでください — 例えば hd = yourcompany.com を持つトークンのみを受け入れることで、IdP を複数組織で共有している場合に社外のアカウントを排除できます。
• ログや監査で SSO user とシステム user を区別しやすくするため、明確な Username Prefix(例: oidc:)を設定してください。特に GPU クラスターを複数チームで共有している場合に有用です。
• Access a cluster の Essential properties タブで、クラスターの他の設定と合わせて SSO / OIDC の状態を確認できます。