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 よりも大きい任意のポート番号を指定できます。

別の認証プロセスを使用してプロバイダを登録する

プロバイダを登録する別の方法は、GKE Identity Service サーバー経由で直接認証することです。OIDC または Azure AD プロバイダを使用している場合は、クラスタ URL の形式に応じて redirect_uri を更新する必要があります。redirect_uri の形式は次のとおりです。

      https://CLUSTER-SERVER-FQDN.com:8443/finish-login

CLUSTER-SERVER-FQDN はクラスタ サーバーの名前で置き換えます。

たとえば、クラスタ URL が https://cluster.company.com の場合、redirect_uri は https://cluster.company.com:8443/finish-login になります。

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

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

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

プロバイダの設定情報

このセクションでは、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] を選択します。名前と説明を入力します。[次へ] をクリックします。

  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. [完了] をクリックします。

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 で [アプリの登録] ページを開き、アプリケーションの名前を選択します。

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

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

    2. [新しいクライアント シークレット] をクリックします。シークレットに名前を付け、[追加] をクリックします。

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

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

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

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

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

    4. [ウェブ] を選択します。[リダイレクト URI] で、gcloud CLI ログインフローの「http://localhost:PORT/callback」を入力します。1,024 より大きい PORT を選択します。[構成] ボタンをクリックします。

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

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

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

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

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

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

Azure AD の詳細設定

この詳細設定は、クラスタのユーザーが 200 を超える Azure AD グループに属している 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 ポータルにログインします。
  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 の構成パラメータを網羅した一覧については、クラスタの構成をご覧ください。