GKE Identity Service に OIDC プロバイダを構成する

このドキュメントでは、選択した OpenID Connect（OIDC） ID プロバイダを GKE Identity Service 用に構成する方法について説明します。GKE Identity Service の詳細については、概要をご覧ください。

このドキュメントは、組織のプラットフォーム管理者または ID 設定の管理者を対象としています。クラスタ管理者またはアプリケーション オペレータの場合は、フリートレベルの GKE Identity Service 用クラスタの構成する前、または OIDC で GKE Identity Service のクラスタを構成する前に、このセクションに記載された処理を行うようプラットフォーム管理者に依頼してください。

プロバイダに GKE Identity サービスを登録する

GKE Identity Service の設定では、1 つのクライアント ID と ID プロバイダのシークレットが必要です。この ID とシークレットは、ユーザーの認証フローの一環として、プロバイダへの接続時に GKE Identity Service によって使用されます。これらの情報を取得するには、選択したプロバイダの標準の手順に沿って、クライアント アプリケーションとしてプロバイダに GKE Identity Service を登録する必要があります。一般的なプロバイダに固有の登録情報については、次のセクションをご覧ください。

リダイレクト URL には、次の値を指定します。

  • https://console.cloud.google.com/kubernetes/oidc は、Google Cloud コンソールのリダイレクト URL です。
  • http://localhost:PORT/callback は、gcloud CLI のリダイレクト URL です。1024 より大きい任意のポート番号を指定できます。
  • APISERVER-URL:11001/finish-login は、FQDN アクセスを使用して認証することを選択した場合のリダイレクト URL です。APISERVER-URL は、クラスタ サーバーの FQDN を含む URL に置き換えます。たとえば、APISERVER-URL が https://cluster.company.com の場合、redirect_uri は https://cluster.company.com:11001/finish-login になります。

登録手順で取得したクライアント ID とシークレットを保存します。GKE Identity Service を設定する必要があるクラスタ管理者と、これらの詳細情報を共有します。次の処理が完了していることを確認する必要があります。

  • APISERVER-URL をコントロール プレーンの VIP（仮想 IP アドレス）に解決するように、ドメイン ネーム サービス（DNS）を構成します。ユーザーはこのドメイン名を使用してクラスタにアクセスできます。
  • 信頼できるエンタープライズの認証局（CA）が発行した Server Name Indication（SNI）証明書を使用します。この証明書では、APISERVER-URL が有効なドメインとして明記されているため、証明書に関する警告がユーザーに表示されることはありません。SNI 証明書はクラスタの作成時に指定できます。SNI 証明書を使用した認証の詳細については、SNI 証明書認証をご覧ください。
  • SNI 証明書が使用できない場合は、クラスタ CA 証明書を信頼するようにすべてのユーザー デバイスを構成します。これにより、証明書の警告は回避されます。ただし、クラスタ CA 証明書をすべてのユーザーに配布する必要があります。

これらの証明書を使用したユーザー ログイン アクセスの詳細については、FQDN アクセスを使用して認証するをご覧ください。

プロバイダの設定情報

このセクションでは、GKE Identity Service の登録に関するプロバイダ固有の追加情報について説明します。プロバイダがここに一覧表示されている場合は、次の手順で、クライアント アプリケーションとしてプロバイダに GKE Identity Service を登録します。

Microsoft AD FS

一連の AD FS 管理ウィザードを使用して、AD FS サーバーと AD ユーザー データベースを構成します。

  1. AD FS 管理ペインを開きます。

  2. [Application Groups] > [Actions] > [Add an Application Group] の順に選択します。

  3. [Server Application] を選択します。名前と説明を入力します。[Next] をクリックします。

  4. 前記の 2 つのリダイレクト URL を入力します。クライアント ID が付与されます。これにより、AD FS サーバーは GKE Identity Service を識別します。後で使用するために、クライアント ID を保存します。

  5. [Generate a shared secret] を選択します。GKE Identity Service は、この Secret を使用して AD FS サーバーに対する認証を行います。後で使用するために Secret を保存します。

セキュリティ グループの構成（省略可）

  1. AD FS Management で、[Relying party trusts] > [Add a new relying party trust] の順に選択します。

  2. [Claims aware] を選択し、[Start] をクリックします。

  3. [Enter data about relying party manually] を選択します。

  4. 表示名を入力します。

  5. 次の 2 つの手順はスキップします。

  6. [Relying party trust identifier] を入力します。例: token-groups-claim。

  7. Access control policy には、[Permit everyone] を選択します。これは、すべてのユーザーが、gcloud CLI および Google Cloud コンソールと、セキュリティ グループ情報を共有することを意味します。

  8. [Finish] をクリックします。

LDAP 属性のクレーム名へのマッピング

  1. AD FS Management で、[Relying party trusts] > [Edit claim issuance policy] の順に選択します。

  2. [Send LDAP Attributes as Claims] をオンにしてから [Next] をクリックします。

  3. [Claim rule name] に「groups」と入力します。

  4. [Attribute store] で [Active Directory] を選択します。

  5. テーブルの [LDAP Attribute] で、以下を選択します。

    • AD FS バージョン 5.0 以降: Token-Groups Qualified by Domain name
    • バージョン 5.0 より前の AD FS: Token Groups - Qualified Names

  6. [Outgoing Claim Type] には、以下を選択します。

    • AD FS バージョン 5.0 以降: Group
    • バージョン 5.0 より前の AD FS: groups

  7. [Finish] をクリックし、[Apply] をクリックします。

AD FS を利用した GKE Identity サービスの登録

管理者モードで PowerShell ウィンドウを開き、次のコマンドを入力します。

Grant-AD FSApplicationPermission `
  -ClientRoleIdentifier "[CLIENT_ID]" `
 -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] `
  -ScopeName "allatclaims", "openid"

次のように置き換えます。

  • [CLIENT_ID] は、前の手順で取得したクライアント ID です。

  • [SERVER_ROLE_IDENTIFIER] は、前に入力したクレーム ID です。提案された ID は token-groups-claim でした。

Azure AD

Azure に OAuth クライアントを登録する

Azure に OAuth クライアントを登録するには、次のリンクの手順に沿って操作します。

  1. まだ行っていない場合は、Azure Active Directory にテナントを設定します。

  2. Microsoft Identity Platform にアプリケーションを登録します。

  3. Azure Portal で [App registrations] ページを開き、アプリケーションの名前を選択します。

  4. クライアント シークレットを作成します。

    1. [Essentials] の [Add a certificate or secret] をクリックします。証明書のリストとシークレットのリストが表示されます。

    2. [New client secret] をクリックします。シークレットに名前を付け、[Add] をクリックします。

    3. シークレットの値*を安全な場所に保存します。ページを閉じた後、またはページを更新した後にシークレットを取得することはできません。

  5. リダイレクト URI を追加します。

    1. アプリケーション ページに戻ります。

    2. [Essentials] で [Add a Redirect URI] を選択します。[Authentication] ページが表示されます。

    3. [Add a platform] を選択すると、右側に [Configure platforms] というパネルが表示されます。

    4. [Web] を選択します。[Redirect URIs] で、gcloud CLI ログインフローの「http://localhost:PORT/callback」を入力します。1,024 より大きい PORT を選択します。[Configure] ボタンをクリックします。

    5. [Add URI] ボタンをクリックして、Google Cloud コンソール ログイン用の別の URI（https://console.cloud.google.com/kubernetes/oidc）を追加します。

    6. 上部にある [Save] ボタンをクリックします。

これで、クライアントの登録は完了です。次の情報をクラスタの管理者と共有する必要があります。

  • 発行元 URI: https://login.microsoftonline.com/TENANT_ID/v2.0。テナント ID は、Azure ポータルのアプリケーション ページに Directory (tenant) ID として表示されます。

  • クライアント ID: クライアント ID は、Azure ポータルのアプリケーション ページに Application (client) ID として表示されます。

  • クライアント シークレット: 前のステップで渡されています。シークレットの作成時にページを閉じると、これを取得できなくなります。この値は必ず安全な場所に保存してください（なくした場合は、新しいシークレットを生成してください）。

Azure AD の高度な設定

この高度な設定は、Azure AD グループベースの認可ポリシーでクラスタを設定する場合にのみ使用してください。この場合、クラスタのユーザーは 200 を超える Azure AD グループに属します。Azure AD の高度な設定では、次のプラットフォームがサポートされています。

  • オンプレミスの GKE クラスタ（VMware とベアメタルの両方）: GKE Enterprise 1.14 以降
  • Anthos clusters on AWS: GKE Enterprise 1.14（Kubernetes バージョン 1.25 以降）から
  • Anthos clusters on Azure: GKE Enterprise 1.14（Kubernetes バージョン 1.25 以降）から
  • Anthos clusters on AWS（前世代）: GKE Enterprise 1.14 以降

始める前に、各ユーザーの Azure AD で ID として構成され、関連付けられたメールアドレスがあることを確認してください。GKE Identity Service は、ユーザーのメールを使用してユーザーの ID をアサートし、リクエストを認証します。

前のセクションで登録したクライアントに、Microsoft Graph API からユーザーとグループの情報を取得する権限が委任されるようにする必要があります。これらの権限により、GKE Identity Service プラグインは、グループ情報を取得する Microsoft Graph API エンドポイントにアクセスできます。この操作を行わないと、GKE Identity Service がユーザー グループを列挙できず、グループに基づく RBAC 認可ポリシーが期待どおりに機能しません。

この設定手順を実行するには、グローバル管理者または組織管理者の権限が必要です。

  1. Azure Portal にログインします。
  2. 複数のテナントにアクセスできる場合は、上部のメニューのディレクトリとサブスクリプションのフィルタを使用して、クライアント アプリの登録を含むテナントを選択します。
  3. [Azure Active Directory - App registrations] を選択し、クライアント アプリケーションを選択します。
  4. [API permissions - Add a permission - Microsoft Graph - Delegated permissions] を選択します。
  5. [Group] タブで [Group.Read.All] をオンにします。[User] タブで [User.Read.All] をオンにします。
  6. [Add permissions] をクリックして処理を完了します。
  7. [Grant admin consent for...] ボタンをクリックして、すべてのユーザーの代わりに同意を承諾します。管理者権限の付与について詳しくは、API 権限と管理者の同意の詳細をご覧ください。

プロバイダの詳細を共有する

クラスタ管理者がクラスタ構成に関する次の必要な情報を所有していることを確認します。

  • プロバイダの発行者 URI。
  • クライアント シークレット。
  • クライアント ID
  • gcloud CLI 用に指定したリダイレクト URI とポート
  • プロバイダがトークン内のユーザーの識別に使用するユーザー名フィールド（クレーム）（クラスタ構成時に想定されるデフォルトは sub）。
  • プロバイダがセキュリティ グループを返すために使用するグループ名フィールド（クレーム）。
  • 前のセクションで説明したプロバイダに固有の追加のスコープまたはパラメータ。たとえば、認可サーバーから Microsoft Azure と Okta の認証の同意を求めるプロンプトが表示された場合、クラスタ管理者はパラメータとして prompt=consent を指定する必要があります。セキュリティ グループ情報を提供するように ADFS を構成した場合、関連する追加パラメータは resource=token-groups-claim（または証明書利用者トラスト ID として選択した値）です。
  • （省略可）プロバイダが公開認証局によって署名された証明書を使用していない場合（自己署名証明書を使用している場合など）、ID プロバイダの証明書（または証明書チェーン）が必要になります。証明書（または証明書チェーン）には、少なくともルート証明書を含める必要があります（チェーンがルート証明書まで連続している限り、部分チェーンは受け入れられます）。ClientConfig でこの値を指定する場合は、Base64 でエンコードされた文字列としてフォーマットする必要があります。文字列を作成するには、完全な PEM でエンコードされた証明書を 1 つの文字列に連結し、base64 エンコードします。

GKE Identity Service の構成パラメータを網羅した一覧については、クラスタの構成をご覧ください。