ベアメタル版 Anthos クラスタの OIDC のトラブルシューティング

このページでは、ベアメタル版 Anthos クラスタで OpenID Connect（OIDC）の問題を特定して解決する方法について説明します。

OIDC の問題の特定

ベアメタル版 Anthos クラスタで OIDC が動作しない場合、通常はクラスタ構成ファイル内の OIDC 仕様が正しく構成されていません。このセクションでは、ログと OIDC 仕様を確認して、OIDC の問題の原因を特定できるようにする手順について説明します。

Anthos Identity Service のログの確認

Anthos Identity Service は、ベアメタル版 Anthos クラスタで OIDC をサポートします。

kubectl logs を使用して Anthos Identity Service のログを出力します。

kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \
deployment/ais --all-containers=true

ログを調べて、OIDC の問題の診断につながるエラーがないかを確認します。

OIDC で認証できない場合については、Anthos Identity Service のログから、問題のデバッグに最も関連性が高く有用な情報を取得できます。

たとえば、（クラスタ構成ファイル内の）OIDC 仕様で、htps://accounts.google.com（https の「t」が欠落）など、issuerURL に入力ミスがある場合は、Anthos Identity Service ログに次のようなエントリが含まれます。
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
ログで構成の問題を特定できた場合は、OIDC の再構成に進みます。
問題をご自身で診断して解決できない場合は、Cloud カスタマーケアにお問い合わせください。

Cloud カスタマーケアで OIDC の問題を診断して解決するには、Anthos Identity Service のログと OIDC 仕様が必要です。

クラスタの OIDC 仕様の確認

クラスタの OIDC 情報は、kube-public 名前空間の clientconfig オブジェクトで指定されています。

kubectl get を使用して、クラスタの OIDC リソースを出力します。
```
kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public get \
clientconfig.authentication.gke.io default -o yaml
```
注: clientconfig 仕様は、クラスタ構成ファイルの OIDC 仕様と若干異なる場合があります。たとえば、OIDC プロバイダの URL はクラスタ構成ファイルの issuerURL フィールドで指定されていますが、clientconfig オブジェクトは issuerURI フィールド内でこの情報を返します。
フィールド値を調べて、OIDC プロバイダに対して仕様が正しく構成されていることを確認します。
仕様で構成の問題を特定できた場合は、OIDC の再構成に進みます。
問題をご自身で診断して解決できない場合は、Cloud カスタマーケアにお問い合わせください。

Cloud カスタマーケアで OIDC の問題を診断して解決するには、Anthos Identity Service ログと OIDC 仕様が必要です。

OIDC の再構成

Anthos Identity Service ログまたは clientconfig オブジェクトのいずれかで問題を特定した場合は、クラスタ内で OIDC を再構成して（クラスタを再作成せずに）対処できます。OIDC を再構成するには、kube-public 名前空間内のタイプ clientconfig の KRM デフォルトオブジェクトを編集します。

kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

ClientConfig CRD の詳細は、Google Cloud コンソールと Anthos 用の Authentication プラグインの両方に OIDC を構成するために使用されます。ClientConfig CRD に含まれる OIDC 情報の詳細については、次の YAML とフィールドの説明の関連表をご覧ください。

authentication:
  - name: oidc
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc"
      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
    proxy: PROXY_URL

次の表に、ClientConfig CRD oidc オブジェクトのフィールドを示します。

フィールド	必須	説明	形式
名前	○	作成する OIDC 構成の名前。	文字列
certificateAuthorityData	×	`base64` でエンコードされた OIDC プロバイダの PEM エンコード証明書。文字列を作成するには、ヘッダーを含めた証明書を `base64` でエンコードします。結果の文字列は `certificateAuthorityData` に 1 行で含めます。例: `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	文字列
clientID	○	OpenID プロバイダへの認証リクエストを行うクライアントアプリケーションの ID。	文字列
clientSecret	×	OIDC クライアントアプリケーションと OIDC プロバイダ間の共有シークレット。	文字列
extraParams	×	OpenID プロバイダに送信する追加の Key-Value パラメータ。グループを承認する場合は、`resource=token-groups-claim` を渡します。 Microsoft Azure と Okta の認証で認証サーバーが同意を求めるプロンプトを表示する場合は、`extraParams` を `prompt=consent` に設定します。Cloud Identity の場合は、`extraParams` を `prompt=consent,access_type=offline` に設定します。	カンマ区切りのリスト
groupsClaim	×	プロバイダがセキュリティグループを返すために使用する JWT クレーム。	文字列
groupPrefix	×	既存の名前と競合しないように、グループクレームの先頭に付加される接頭辞。たとえば、`foobar` という名前の 2 つのグループがある場合、接頭辞 `gid-` を追加します。結果のグループは `gid-foobar` です。	文字列
issuerURI	○	認可リクエストが OpenID に送信される URL（`https://example.com/adfs` など）。Kubernetes API サーバーは、この URL を使用してトークン検証用の公開鍵を検出します。URI には HTTPS を使用する必要があります。	URL 文字列
kubectlRedirectURI	○	`kubectl` が認証に使用するリダイレクト URL。	URL 文字列
scopes	○	OpenID プロバイダに送信する追加のスコープ。Microsoft Azure と Okta には `offline_access` スコープが必要です。	カンマ区切りのリスト
userClaim	×	ユーザー名として使用する JWT クレーム。OpenID プロバイダによっては、email や name などの他のクレームを選択できます。ただし、名前が競合しないように、email 以外のクレームには発行者の URL が先頭に付加されます。	文字列
userPrefix	×	既存の名前と競合しないように、ユーザー名のクレームの先頭に付加される接頭辞。	文字列
proxy	×	`auth` メソッドに使用するプロキシサーバー（該当する場合）。例: `http://user:password@10.10.10.10:8888.`	文字列