OIDC で GKE Identity Service のクラスタを設定する

kubectl

デフォルトの ClientConfig を編集する場合は、kubectl を介してクラスタに接続できることを確認し、次のコマンドを実行します。

kubectl --kubeconfig=KUBECONFIG_PATH edit ClientConfigs default -n kube-public

KUBECONFIG_PATH は、クラスタの kubeconfig ファイルへのパス（例:$HOME/.kube/config）に置き換えます。

テキスト エディタがクラスタの ClientConfig リソースを読み込みます。下に示すように、spec.authentication.oidc オブジェクトを追加します。すでに書き込まれているデフォルトのデータは変更しないでください。

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    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: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
      enableAccessToken: ENABLE_ACCESS_TOKEN
    proxy: PROXY_URL

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

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

ClientConfig が完成したら、ファイルを保存します。これにより、クラスタの ClientConfig が更新されます。構文エラーがある場合は、構成ファイルを再編集して修正するように求められます。

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.
...

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

• CLIENT_ID: プロバイダに GKE Identity サービスを登録するときに返されたクライアント ID。
• CLIENT_SECRET: OIDC クライアント アプリケーションと OIDC プロバイダ間の共有シークレット。
• TENANT: 認証する Azure AD アカウントの種類。サポートされている値は、テナント ID または特定のテナントに属するアカウントのテナント名です。テナント名はプライマリ ドメインとしても知られています。これらの値を確認する方法について詳しくは、Microsoft Azure AD テナント ID とプライマリ ドメイン名を確認するをご覧ください。
• PORT: 登録時にプラットフォーム管理者が指定した、gcloud CLI で使用されるリダイレクト URL 用に選択されたポート番号。

Azure AD（上級）

Azure AD のこのオプション構成では、ユーザーあたりのグループ数に制限はありません。GKE Identity Service で Microsoft Graph API を使用して、ユーザーとグループの情報を取得できます。

この構成をサポートするプラットフォームについては、Azure AD の高度な設定に関するページをご覧ください。

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

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

...
spec:
  authentication:
  - name: NAME
    proxy: PROXY_URL
    azureAD:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      tenant: TENANT_ID
      kubectlRedirectURI: http://localhost:PORT/callback
      groupFormat: GROUP_FORMAT
      userClaim: USER_CLAIM

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

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

• NAME: この構成を識別するために使用する名前で、通常は ID プロバイダ名です。構成名は、先頭が文字で、その後に最大 39 文字の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。
• PROXY_URL: ID プロバイダへの接続に使用するプロキシ サーバーのアドレス（該当する場合）。たとえば、クラスタがプライベート ネットワークにあり、パブリック ID プロバイダに接続する必要がある場合に、これを設定する必要があります。例: http://user:password@10.10.10.10:8888
• CLIENT_ID: プロバイダに GKE Identity サービスを登録するときに返されたクライアント ID。
• CLIENT_SECRET: OIDC クライアント アプリケーションと OIDC プロバイダ間の共有シークレット。
• TENANT: 認証する Azure AD アカウントの種類。サポートされている値は、テナント ID または特定のテナントに属するアカウントのテナント名です。テナント名はプライマリ ドメインとしても知られています。これらの値を確認する方法について詳しくは、Microsoft Azure AD テナント ID とプライマリ ドメイン名を確認するをご覧ください。
• PORT: 登録時にプラットフォーム管理者が指定した、gcloud CLI で使用されるリダイレクト URL 用に選択されたポート番号。
• GROUP_FORMAT: グループ情報を取得する形式。このフィールドには、ユーザー グループの ID または NAME に対応する値を指定できます。この設定は現在、ベアメタル Google Distributed Cloud デプロイのクラスタでのみ使用できます。
• USER_CLAIM（省略可）: プロバイダがアカウントの識別に使用する JWT クレーム（フィールド名）。ここで値を指定しない場合、GKE Identity Service は、「email」、「preferred_username」、「sub」の順番で値を使用してユーザーの詳細情報を取得します。この属性は、GKE Enterprise バージョン 1.28 以降で使用できます。

Okta

Okta を ID プロバイダとし、ユーザーとグループの両方を使用して認証を設定する手順は次のとおりです。この構成により、Anthos 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.
...

グループ アクセスの上限

Okta ユーザーの場合、Anthos Identity Service は、連結時のグループ名が 170,000 文字未満のユーザーのグループ情報を取得できます。これは、Okta の最大グループ長が与えられた約 650 グループのメンバーシップに相当します。ユーザーが所属するグループが多すぎる場合、認証の呼び出しは失敗します。