このページでは、ベアメタル版 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フィールド値を調べて、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 | × |
例: |
文字列 |
| clientID | ○ | OpenID プロバイダへの認証リクエストを行うクライアント アプリケーションの ID。 | 文字列 |
| clientSecret | × | OIDC クライアント アプリケーションと OIDC プロバイダ間の共有シークレット。 | 文字列 |
| extraParams | × |
OpenID プロバイダに送信する追加の Key-Value パラメータ。グループを承認する場合は、 Microsoft Azure と Okta の認証で認証サーバーが同意を求めるプロンプトを表示する場合は、 |
カンマ区切りのリスト |
| 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 |
文字列 |