フリートレベルで GKE Identity Service を使用してクラスタを設定する

このドキュメントは、クラスタで GKE Identity Service を設定するクラスタ管理者またはアプリケーションオペレーターを対象としています。任意の ID プロバイダを使用して、クラスタに対してフリートレベルで GKE Identity Service を設定する方法について説明します。

API を有効にする

利用を開始するには、関連する API を有効にする必要があります。

コンソール

クラスタが登録されているプロジェクトを選択していることを確認します。

Enable the GKE Hub and Kubernetes Engine APIs.
Enable the APIs

gcloud

次のコマンドを実行して、設定に必要な API を有効にします。

gcloud services enable 

gkehub.googleapis.com 

container.googleapis.com

クラスタを構成する

選択したプロバイダを使用するようにクラスタを構成するには、ID プロバイダの詳細、ユーザー ID として ID プロバイダが提供する JWT トークンの情報、クライアントアプリケーションとして GKE Identity Service を登録する際に提供されたその他の情報を指定する必要があります。たとえば、プロバイダが次のフィールドを含む ID トークンを作成するとします。ここで、iss は ID プロバイダの URI、sub はユーザー、groupList はユーザーが属するセキュリティグループのリストです。

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

ユーザー側の構成には、次のように対応するフィールドが含まれている必要があります。

issueruri: 'https://server.example.com'
username: 'sub'
group: 'groupList'
...

構成の作成に必要な情報のほとんどは、プラットフォーム管理者または組織の ID 管理者から提供されます。よく使用される ID プロバイダの構成の例については、プロバイダ固有の構成をご覧ください。

GKE Identity Service では、Google Cloud コンソールまたは Google Cloud CLI を使用して、この構成を作成または更新できます。

コンソール

GKE Identity Service を有効にする

Google Cloud コンソールで、[機能マネージャー] ページに移動します。

機能マネージャーに移動
[Identity Service] パネルで [有効にする] をクリックし、表示されたペインで [有効にする] を再度クリックします。これにより、フリートのクラスタ内で GKE Identity Service のライフサイクルを管理する新しい GKE Identity Service コントローラインスタンスが作成されます。

クラスタを選択

[機能マネージャー] ページに戻り、[Identity Service] パネルの [詳細] をクリックして、サービスの詳細ペインを開きます。ここには、プロジェクトのクラスタとそのフリートレベルの GKE Identity Service のステータスが表示されます。
[Identity Service の更新] をクリックして、設定ペインを開きます。
構成するクラスタを選択します。選択できるのはサポートされているクラスタタイプのみです。個々のクラスタを選択するか、すべてのクラスタを同じ ID 構成にするように指定できます。フリートレベルのデフォルトを構成している場合、構成はデフォルトに再調整されます。詳細については、フリートレベルのデフォルトを構成するをご覧ください。
[ID プロバイダ] プルダウンで、クラスタの構成方法を選択します。クラスタに既存の GKE Identity Service 構成がある場合は、それを更新することもできます。既存の登録済みクラスタに使用する GKE Identity Service 構成がある場合は、その構成を選択したクラスタにコピーできます。まったく新しい構成を作成するには、次のセクションで説明するように、選択したプロバイダの手順に沿って操作します。

プロバイダの詳細を設定する

追加するプロバイダの詳細は、構成で使用する ID プロバイダのタイプによって異なります。

OIDC

[新しい OpenID Connect] を選択して、新しい OIDC 構成を作成します。
この構成を識別するために使用する名前を [プロバイダ名] フィールドで指定します。通常は ID プロバイダ名を指定します。名前の先頭は英字で、それに続く最大 39 文字の英小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。構成を作成した後は、この名前を編集することはできません。
プロバイダに GKE Identity Service を登録するときに返されたクライアント ID を、[クライアント ID] フィールドに指定します。
[クライアントシークレット] フィールドに、クライアントアプリケーションと ID プロバイダの間で共有する必要があるクライアントシークレットを指定します。
[発行元（URL）] には、ID プロバイダに対して認可リクエストを行う URI を指定します。
[次へ] をクリックして、OIDC 属性を設定します。

Azure AD

[新しい Azure Active Directory] を選択して、新しい Azure AD 構成を作成します。
この構成を識別するために使用する名前を [プロバイダ名] フィールドで指定します。通常は ID プロバイダ名を指定します。名前の先頭は英字で、それに続く最大 39 文字の英小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。構成を作成した後は、この名前を編集することはできません。
プロバイダに GKE Identity Service を登録するときに返されたクライアント ID を、[クライアント ID] フィールドに指定します。
[クライアントシークレット] フィールドに、クライアントアプリケーションと ID プロバイダの間で共有する必要があるクライアントシークレットを指定します。
[テナント] に、認証する Azure AD アカウントであるテナントを指定します。
[次へ] をクリックして、Azure AD 属性を設定します。

LDAP

[LDAP] を選択して、新しい LDAP 構成を作成します。
この構成を識別するために使用する名前を [プロバイダ名] フィールドで指定します。通常は ID プロバイダ名を指定します。名前の先頭は英字で、それに続く最大 39 文字の英小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。構成を作成した後は、この名前を編集することはできません。
[次へ] をクリックします。
ホスト名（必須）、LDAP 接続タイプ、LDAP サーバーの base64 でエンコードされた CA 証明書を指定します。
[次へ] をクリックしてサーバーを構成します。
ユーザーの識別名、フィルタ、ログイン属性、識別子属性を指定します。
[次へ] をクリックして、ユーザーの詳細を設定します。
グループを使用する場合は、グループの識別名、フィルタ、識別子属性を指定します。
[次へ] をクリックして、グループの詳細を設定します。
サービスアカウントのユーザー名とパスワードを指定します。
[完了] をクリックして、サービスアカウント名を設定します。

属性を設定する

追加する必要がある属性は、ID プロバイダと、GKE Identity Service のプロバイダを構成する際にプラットフォーム管理者が選択した設定オプションによって変わります。

OIDC

構成属性に次の値を入力します。
- kubectl リダイレクト URI: gcloud CLI で使用され、プラットフォーム管理者が登録時に指定したリダイレクト URL とポート（通常は http://localhost:PORT/callback の形式）。
- 認証局（省略可）: プラットフォーム管理者が指定した場合は、ID プロバイダ用の PEM エンコードの証明書の文字列。
- グループクレーム（省略可）: プロバイダがアカウントのセキュリティグループを返すために使用する JWT クレーム（フィールド名）。
- グループ接頭辞（省略可）: 複数の ID プロバイダの構成がある場合に、アクセス制御ルールの既存の名前と競合しないように、セキュリティグループ名に追加する接頭辞（通常はプロバイダ名）。
- プロキシ（省略可）: ID プロバイダへの接続に使用するプロキシサーバーのアドレス（該当する場合）。たとえば、クラスタがプライベートネットワークにあり、パブリック ID プロバイダに接続する必要がある場合に設定する必要があります。例: http://user:password@10.10.10.10:8888。
- スコープ（省略可）: ID プロバイダが必要とする追加のスコープ。Microsoft Azure と Okta には offline_access スコープが必要です。必要に応じてさらにスコープを追加するには、[スコープを追加] をクリックします。
- ユーザークレーム（省略可）: プロバイダがアカウントを識別するために使用する JWT クレーム（フィールド名）。ここに値が指定されていないと、GKE Identity Service は「sub」を使用します。これは多くのプロバイダで使用されるユーザー ID クレームです。OpenID プロバイダによっては、email や name などのクレームを選択することもできます。名前が競合しないように、email 以外のクレームには、発行元の URL が先頭に付加されます。
- ユーザー接頭辞（省略可）: デフォルトの接頭辞を使用しない場合に、既存の名前との競合を避けるために、ユーザークレームに追加する接頭辞。
- Extra Params（省略可）: 構成に必要な追加パラメータ。パラメータ Key と Value で指定します。[param を追加] をクリックして、必要に応じてパラメータを追加します。
- アクセストークンの有効化（省略可）: 有効にすると、Okta などの OIDC プロバイダのグループをサポートできます。
- Deploy Google Cloud console proxy（省略可）: 有効にすると、インターネット経由で一般公開されていないオンプレミスの ID プロバイダに Google Cloud コンソールを接続できるプロキシがデプロイされます。

Azure AD

構成属性に次の値を入力します。
- kubectl リダイレクト URI: gcloud CLI で使用され、プラットフォーム管理者が登録時に指定したリダイレクト URL とポート（通常は http://localhost:PORT/callback の形式）。
- ユーザークレーム（省略可）: プロバイダがアカウントを識別するために使用する JWT クレーム（フィールド名）。ここに値が指定されていないと、GKE Identity Service は email、preferred_username、sub の順番で値を使用して、ユーザーの詳細情報を取得します。
- プロキシ（省略可）: ID プロバイダへの接続に使用するプロキシサーバーのアドレス（該当する場合）。たとえば、クラスタがプライベートネットワークにあり、パブリック ID プロバイダに接続する必要がある場合に設定する必要があります。例: http://user:password@10.10.10.10:8888。

ID プロバイダを追加する

フリートで構成する ID プロバイダが他にある場合は、ここでプロバイダを追加できます。手順に沿って、追加の ID プロバイダを指定します。

構成を更新する

[構成の更新] をクリックします。これにより、必要に応じて GKE Identity Service がインストールされます。これは EKS クラスタの場合にのみ行われます。GKE クラスタにはデフォルトで GKE Identity Service がインストールされています。選択したクラスタにクライアント構成を適用します。

gcloud

構成ファイルを作成する

GKE Identity Service は、ClientConfig という Kubernetes カスタムリソースタイプ（CRD）を使用してクラスタを構成します。ClientConfig には、GKE Identity Service が ID プロバイダとやり取りするために必要なすべての情報のフィールドが含まれています。以降のセクションでは、OIDC と LDAP の構成について説明します。ここでは、構成ファイル auth-config.yaml を作成します。

OIDC

次のファイルは、oidc 構成と azuread 構成の両方を示しています。oidc または azuread の使用方法の詳細については、プロバイダ固有の構成をご覧ください。

  apiVersion: authentication.gke.io/v2alpha1
  kind: ClientConfig
  metadata:
    name: default
    namespace: kube-public
  spec:
    authentication:
    - name: NAME
      proxy: PROXY_URL
      oidc:
        certificateAuthorityData: CERTIFICATE_STRING
        clientID: CLIENT_ID
        clientSecret: CLIENT_SECRET
        deployCloudConsoleProxy: PROXY_BOOLEAN
        extraParams: EXTRA_PARAMS
        groupsClaim: GROUPS_CLAIM
        groupPrefix: GROUP_PREFIX
        issuerURI: ISSUER_URI
        kubectlRedirectURI: http://localhost:PORT/callback
        scopes: SCOPES
        userClaim: USER_CLAIM
        userPrefix: USER_PREFIX
    - name: NAME
      proxy: PROXY_URL
      azureAD:
        clientID: CLIENT_ID
        clientSecret: CLIENT_SECRET
        tenant: TENANT_UUID
        kubectlRedirectURI: http://localhost:PORT/callback

複数の ID プロバイダを構成している場合は、前述の構成と同じ形式で、auth-config.yaml ファイルの authentication アンカーの下に複数の認証構成を記述できます。次の表に、ClientConfig oidc オブジェクトと azuread オブジェクトのフィールドを示します。ほとんどのフィールドは省略できます。追加する必要があるフィールドは、ID プロバイダと、GKE Identity Service のプロバイダを構成する際にプラットフォーム管理者が選択した設定オプションによって変わります。

フィールド	必須	説明	形式
name	○	この構成を識別するために使用する名前で、通常は ID プロバイダ名です。構成名の先頭は英字で、それに続く最大 39 文字の英小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。	文字列
certificateAuthorityData	×	プラットフォーム管理者が指定した場合は、ID プロバイダ用の PEM エンコードの証明書の文字列。`certificateAuthorityData` では、結果の文字列が 1 行に含まれます。	文字列
clientID	○	プロバイダに GKE Identity Service を登録際に返されたクライアント ID。	文字列
clientSecret	○	プロバイダに GKE Identity Service を登録際に返されたクライアントシークレット。	文字列
deployCloudConsoleProxy	×	Google Cloud コンソールから一般公開されていないオンプレミスの ID プロバイダにインターネット経由で接続できるようにするプロキシがデプロイされているかどうかを表します。デフォルトの設定値は `false` です。	ブール値
extraParams	×	ID プロバイダに送信する追加の Key=Value パラメータ。カンマ区切りのリストとして指定します。例: prompt=consent,access_type=offline。	カンマ区切りのリスト
enableAccessToken	×	有効になっている場合、GKE Identity Service は、ユーザーがコマンドラインからログインしたときに、ID プロバイダの userinfo エンドポイントを使用してグループ情報を取得できます。グループクレームを提供するプロバイダ（Okta など）がある場合は、このエンドポイントからセキュリティグループを使用して認可を行えます。未設定の場合、これは `false` とみなされます。	ブール値
groupsClaim	×	JWT クレーム（フィールド名）。プロバイダがアカウントのセキュリティグループを返すために使用します。	文字列
groupPrefix	×	複数の ID プロバイダの構成がある場合に、アクセス制御ルールの既存の名前と競合しないように、セキュリティグループ名に追加する接頭辞（通常はプロバイダ名）。	文字列
issuerURI	○	ID プロバイダに対して認可リクエストを行う URI。URI には HTTPS を使用する必要があります。	URL 文字列
kubectlRedirectURI	○	gcloud CLI で使用され、プラットフォーム管理者が登録時に指定したリダイレクト URL とポート（通常は `http://localhost:PORT/callback` の形式）。	URL 文字列
scopes	○	OpenID プロバイダに送信する追加のスコープ。たとえば、Microsoft Azure と Okta では、`offline_access` スコープが必要です。	カンマ区切りのリスト
userClaim	×	プロバイダがユーザーアカウントの識別に使用する JWT クレーム（フィールド名）。ここに値が指定されていないと、GKE Identity Service は「sub」を使用します。これは多くのプロバイダで使用されるユーザー ID クレームです。OpenID プロバイダによっては、email や name などのクレームを選択することもできます。名前が競合しないように、email 以外のクレームには、発行元の URL が先頭に付加されます。	文字列
userPrefix	×	デフォルトの接頭辞を使用しない場合にユーザークレームの先頭に付加する接頭辞。これにより、既存の名前と競合しないようにします。	文字列
tenant	○	認証する Azure AD アカウントの種類。サポートされている値は、テナント ID または特定のテナントに属するアカウントのテナント名です。テナント名はプライマリドメインとしても知られています。これらの値を確認する詳しい方法については、Microsoft Azure AD テナント ID とプライマリドメイン名を確認するをご覧ください。	文字列
proxy	×	ID プロバイダへの接続に使用するプロキシサーバーのアドレス（該当する場合）。たとえば、クラスタがプライベートネットワークにあり、パブリック ID プロバイダに接続する必要がある場合に設定する必要があります。例: `http://user:password@10.10.10.10:8888`。	文字列

SAML

次のファイルは、SAML 構成を示しています。

   apiVersion: authentication.gke.io/v2alpha1
   kind: ClientConfig
   metadata:
     name: default
     namespace: kube-public
   spec:
     authentication:
     - name: NAME
       saml:
         idpEntityID: ENTITY_ID
         idpSingleSignOnURI: SIGN_ON_URI
         idpCertificateDataList: IDP_CA_CERT
         userAttribute: USER_ATTRIBUTE
         groupsAttribute: GROUPS_ATTRIBUTE
         userPrefix: USER_PREFIX
         groupPrefix: GROUP_PREFIX
         attributeMapping:
           ATTRIBUTE_KEY_1 : ATTRIBUTE_CEL_EXPRESSION_1
           ATTRIBUTE_KEY_2 : ATTRIBUTE_CEL_EXPRESSION_2
      certificateAuthorityData: CERTIFICATE_STRING
      preferredAuthentication: PREFERRED_AUTHENTICATION
      server: <>

次の表に、ClientConfig saml オブジェクトのフィールドを示します。追加する必要があるフィールドは、ID プロバイダと、GKE Identity Service のプロバイダを構成する際にプラットフォーム管理者が選択した設定オプションによって変わります。

フィールド	必須	説明	形式
name	○	この構成を識別するために使用する名前で、通常は ID プロバイダ名です。構成名の先頭は英字で、それに続く最大 39 文字の英小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。	文字列
idpEntityID	○	SAML プロバイダの SAML エンティティ ID（URI 形式で指定）。例: `https://www.idp.com/saml`。	URL 文字列
idpSingleSignOnURI	○	SAML プロバイダの SSO エンドポイント（URI 形式で指定）。例: `https://www.idp.com/saml/sso`。	URL 文字列
idpCertificateDataList	○	SAML レスポンスの検証に使用される ID プロバイダ証明書に対応します。これらの証明書は標準の Base64 エンコード形式と PEM 形式にする必要があります。ID プロバイダの証明書のローテーションを容易にするため、サポートされる証明書は 2 つまでです。	文字列
userAttribute	×	SAML レスポンスでユーザー名を保持する属性の名前。	文字列
groupsAttribute	×	ユーザーのグループ情報を保持する SAML レスポンスの属性名。	文字列
userPrefix	×	デフォルトの接頭辞を使用しない場合にユーザークレームの先頭に付加する接頭辞。これにより、既存の名前と競合しないようにします。	文字列
groupPrefix	×	複数の ID プロバイダの構成がある場合に、アクセス制御ルールの既存の名前と競合しないように、セキュリティグループ名に追加する接頭辞（通常はプロバイダ名）。	文字列
attributeMapping	×	追加のユーザー属性のマッピング。	文字列
certificateAuthorityData	×	プラットフォーム管理者が指定した場合は、ID プロバイダ用の PEM エンコードの証明書の文字列。結果の文字列は `certificateAuthorityData` に 1 行で含めます。	文字列
preferredAuthentication	×	クラスタで構成された優先認証方法の名前。	文字列

LDAP

次のファイルは、ldap 構成を示しています。

  apiVersion: authentication.gke.io/v2alpha1
  kind: ClientConfig
  metadata:
    name: default
    namespace: kube-public
  spec:
    authentication:
    - name: ldap
      ldap:
        server:
          host: HOST_NAME
          connectionType: CONNECTION_TYPE
          certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
        user:
          baseDn: BASE_DN
          loginAttribute: LOGIN_ATTRIBUTE
          filter: FILTER
          identifierAttribute: IDENTIFIER_ATTRIBUTE
        group:
          baseDn: BASE_DN
          filter: FILTER
          identifierAttribute: IDENTIFIER_ATTRIBUTE
        serviceAccount:
          simpleBindCredentials:
            dn: DISTINGUISHED_NAME
            password: PASSWORD

次の表に、ClientConfig ldap オブジェクトのフィールドを示します。追加する必要があるフィールドは、ID プロバイダと、GKE Identity Service のプロバイダを構成する際にプラットフォーム管理者が選択した設定オプションによって変わります。

フィールド	必須	説明	形式
name	○	この LDAP 構成を識別する名前	文字列
server
host	○	LDAP サーバーのホスト名または IP アドレス。ポートは省略可能であり、指定しない場合のデフォルトは 389 です。たとえば、`ldap.server.example.com` や、`10.10.10.10:389` です。	文字列
connectionType	○	LDAP サーバーへの接続時に使用する LDAP 接続タイプ。`starttls` または `ldaps` が指定されている場合、certificateAuthorityData フィールドは空にできません。	文字列
certificateAuthorityData	特定の LDAP 接続タイプで必須	LDAP サーバー用の Base64 エンコードされた PEM 形式の認証局証明書が含まれます。これは、`ldaps` 接続と `startTLS` 接続に対してのみ指定する必要があります。	文字列
user
baseDN	○	ユーザーエントリを検索する LDAP ディレクトリ内のサブツリーの場所。	DN 形式の文字列。
loginAttribute	×	入力ユーザー名と照合する属性の名前。LDAP データベースでユーザーを検索するために使用されます（例: `(<LoginAttribute>=<username>)`）。また、オプションのフィルタフィールドと組み合わせて使用されます。デフォルトは `userPrincipalName` です。	文字列
filter	×	ユーザーの検索時に適用するオプションのフィルタこれにより、ログインできるユーザーアカウントをさらに制限できます。指定されていない場合、デフォルトの `(objectClass=User)` が使用されます。	文字列
identifierAttribute	×	認証後にユーザーの ID として使用する属性を指定します。これは、ユーザーがユーザー名を使用してログインできるようにする `loginAttribute` フィールドとは別のものですが、実際の ID がメールアドレスか完全な識別名（DN）になります。たとえば、`loginAttribute` を `sAMAccountName`、identifierAttribute を `userPrincipalName` に設定すると、ユーザーは `bsmith` としてログインできるようになりますが、ユーザーの実際の RBAC ポリシーは `bsmith@example.com` として記述されます。ユーザーごとに一意になることから、`userPrincipalName` の使用をおすすめします。指定しない場合は、デフォルトの `userPrincipalName` が使用されます。	文字列
group（オプションフィールド）
baseDN	○	グループエントリを検索する LDAP ディレクトリ内のサブツリーの場所。	文字列
filter	×	ユーザーが所属するグループを検索するときに使用するフィルタ（省略可）。これを使用することで、特定のグループのみを明示的に照合して、各ユーザーから返されるグループの数を減らすことができます。デフォルトは `(objectClass=Group)` です。	文字列
identifierAttribute	×	ユーザーが所属する各グループの識別名。たとえば、これが `distinguishedName` に設定されている場合、RBAC やその他のグループの期待値は完全な DN として記述する必要があります。指定しない場合は、デフォルトの `distinguishedName` が使用されます。	文字列
serviceAccount/simpleBindCredentials
dn	○	サービスアカウントユーザーの識別名。	文字列
password	○	サービスアカウントユーザーのパスワード。	文字列

GKE Identity Service を有効にする

プロジェクトの GKE Identity Service を有効にするには、次のコマンドを実行します。

gcloud container fleet identity-service enable

これにより、フリートのクラスタ内で GKE Identity Service のライフサイクルを管理する新しい GKE Identity Service コントローラインスタンスが作成されます。このコマンドは、プロジェクトごとに 1 回実行すれば、そのプロジェクトフリートに登録されたすべてのサポート対象クラスタで GKE Identity Service を使用できます。

フリートレベルのデフォルト構成で GKE Identity Service を有効にできます。この設定を使用すると、指定した GKE Identity Service プロバイダ構成が、クラスタ作成時にフリートに登録された Google Cloud 上のすべての GKE クラスタに自動的に適用されます。詳細については、フリートレベルのデフォルトを構成するをご覧ください。

クラスタに構成を適用する

必要に応じて GKE Identity Service をインストールし、クラスタに構成を適用するには、次のコマンドを実行します（EKS クラスタのみ。他のサポートされているクラスタタイプには、デフォルトで GKE Identity Service がインストールされています）。

gcloud container fleet identity-service apply \
--membership=CLUSTER_NAME \
--config=/path/to/auth-config.yaml

CLUSTER_NAME は、フリート内のクラスタの一意の名前に置き換えます。このコマンドを実行すると、構成は GKE Identity Service コントローラによって管理されます。GKE Identity Service のクライアント構成にローカルで加えられた変更は、コントローラによってこの設定に指定された構成に戻されます。

これにより、GKE Identity Service は、Google ID でログインするユーザーアカウントの Google グループ情報を取得できます。この構成は、GKE Enterprise バージョン 1.13 以降の Google Distributed Cloud 上のクラスタ（VMware とベアメタルの両方）に適用されます。Google グループ機能の詳細については、Google グループで Connect Gateway を設定するをご覧ください。

認証オプションに関する既存の構成がクラスタに存在する場合、以下が適用されます。

OIDC プロバイダにクラスタレベルの構成がある場合、クラスタにフリートレベルの GKE Identity Service の構成を適用すると、既存のすべての認証仕様が上書きされます。
フリートレベルの構成で、サポートされていないプロバイダ用にクラスタレベルの構成が存在する場合、この設定は失敗します。フリートレベルの構成を適用するには、既存のプロバイダ構成を削除する必要があります。

GKE Identity Service コントローラが構成を管理する必要がなくなった場合（たとえば、別の認証オプションを使用する場合）は、GKE Identity Service 管理の無効化の手順に沿って、この機能を無効にできます。

プロバイダ固有の構成

このセクションでは、OIDC プロバイダ（Azure AD や Okta など）の構成ガイダンスについて説明します。これには独自の詳細をコピーして編集できる構成例も含まれます。

Azure AD

これは、Azure AD で GKE Identity Service を設定するためのデフォルトの構成です。この構成を使用すると、GKE Identity Service で Azure AD からユーザーとグループの情報を取得できます。また、グループに基づいて Kubernetes のロールベースアクセス制御（RBAC）を設定できます。ただし、この構成を使用すると、ユーザーごとに取得できるグループに約 200 個の上限が設定されます。

ユーザーあたり 200 個を超えるグループを取得する必要がある場合は、Azure AD（上級）の手順をご覧ください。

...
spec:
  authentication:
  - name: oidc-azuread
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      extraParams: prompt=consent, access_type=offline
      issuerURI: https://login.microsoftonline.com/TENANT_ID/v2.0
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: openid,email,offline_access
      userClaim: email

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Azure AD（上級）

Azure AD のこのオプション構成では、ユーザーあたりのグループ数に制限はありません。GKE Identity Service で Microsoft Graph API を使用して、ユーザーとグループの情報を取得できます。この構成をサポートするプラットフォームについては、Azure AD の高度な設定に関するページをご覧ください。

ユーザーあたり 200 個未満のグループを取得する必要がある場合は、ClientConfig の oidc アンカーを使用してデフォルト構成を使用することをおすすめします。詳細については、Azure AD の手順をご覧ください。

構成例のすべてのフィールドは必須です。

...
spec:
  authentication:
  - name: azure
    azureAD:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      tenant: TENANT_UUID
      kubectlRedirectURI: http://localhost:PORT/callback
      groupFormat: GROUP_FORMAT
      userClaim: USER_CLAIM

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

GROUP_FORMAT は、グループ情報を取得する形式に置き換えます。このフィールドには、ユーザーグループの ID または NAME に対応する値を指定できます。この設定は、Google Distributed Cloud（オンプレミス）デプロイのクラスタでのみ使用できます。

Okta

以下では、Okta を ID プロバイダとし、ユーザーとグループの両方を使用して認証を設定する手順について説明します。この構成により、GKE Identity Service は、アクセストークンと Okta の userinfo エンドポイントを使用して、ユーザーとグループのクレームを取得します。

...
spec:
  authentication:
  - name: okta
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      enableAccessToken: true
      extraParams: prompt=consent
      groupsClaim: groups
      issuerURI: https://OKTA_ISSUER_URI/
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: offline_access,email,profile,groups
      userClaim: email

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

フリートレベルのデフォルトを構成する

フリートレベルのデフォルト構成で GKE Identity Service を有効にできます。この設定を使用すると、クラスタ作成時に登録された Google Cloud クラスタの新しい GKE または GKE クラスタで、指定した構成のクラスタで GKE Identity Service が自動的に有効になります。この機能を有効にしても、既存のフリートメンバークラスタがフリートのデフォルトで自動的に更新されることはありませんが、デフォルトの構成を適用することは可能です。フリートレベルの構成の管理の詳細については、フリートレベルで機能を管理するをご覧ください。

フリートレベルのデフォルト構成で GKE Identity Service を構成するには、次の操作を行います。

fleet-default.yaml という名前のファイルを作成し、構成ファイルの作成の説明に従って入力します。
フリートレベルのデフォルト構成で GKE Identity Service を有効にします。

注: GKE Identity Service がフリートですでに有効になっていて、フリートレベルのデフォルト構成がない場合は、apply コマンドを使用します。
```
gcloud container fleet identity-service enable --fleet-default-member-config=fleet-default.yaml
```
既存のフリートレベルのデフォルト構成を変更するか、GKE Identity Service がすでにフリートで有効になっている場合に追加するには、次のコマンドを実行します。
```
gcloud container fleet identity-service apply --fleet-default-member-config=default-config.yaml
```
フリートレベルのデフォルト構成を設定前に登録した既存のフリートメンバークラスタは、デフォルトの構成を自動的に継承しません。既存のフリートメンバークラスタにデフォルトの構成を適用するには、次のコマンドを実行します。
```
gcloud container fleet identity-service apply --origin=fleet --membership=CLUSTER_NAME
```
GKE Identity Service のフリートレベルのデフォルトを無効にするには、次のコマンドを実行して、デフォルトの構成を削除します。
```
gcloud container fleet identity-service delete --fleet-default-member-config
```

ID サービスの構成を確認する

フリートレベルの設定が完了したら、指定した ID サービス構成でフリート内のクラスタが正常に構成されているかどうかを確認できます。

コンソール

Google Cloud コンソールで、[機能マネージャー] ページに移動します。

機能マネージャーに移動
有効な機能は、パネルで [有効] と表示されます。
[Identity Service] パネルで [詳細] をクリックします。詳細パネルに、登録済みクラスタのステータスが表示されます。

gcloud

次のコマンドを実行します。

gcloud container fleet identity-service describe

次のステップ

クラスタを構成したら、ユーザーアクセスを設定するに進みます。