OIDC プロバイダに関する問題のトラブルシューティング

このドキュメントでは、GKE Identity Service の OIDC と AzureAD ID プロバイダの問題に関するトラブルシューティングについて説明します。

証明書の形式が間違っている

この問題は、証明書の値に形式的なエラーがある場合に発生します。形式の問題は、base64 でエンコードされていない証明書の値や、base64 でエンコードされているが正しくない値に相当します。問題は、証明書がルート認証局によって署名されていない場合や、正しい形式の信頼チェーンが用意されていない場合にも発生する可能性があります。

エラー メッセージ

証明書の形式が正しくない場合に表示されるエラー メッセージの例を次に示します。

  • base64 でエンコードされていない証明書: Failed creating HTTP client to fetch the Discovery URI "<Discovery-document URI>" with error: Unable to decode data field, the value should be Base64 encoded

  • 形式が正しくないか、base64 でエンコードされているが正しくない証明書: Unable to connect to 'https://example.com', encountered the following error: Problem with the SSL CA cert (path? access rights?). Details: error setting certificate verify locations: CAfile: /tmp/example.pem CApath: none (The certificate could not be read, this is most likely because it's empty or contains a formatting error. Please check your configuration.)

  • 形式が正しくないか、base64 でエンコードされているが正しくない証明書: Failed fetching the Discovery URI "<Discovery-document URI>" with error: Unable to load TLS certificates.

解決策

問題は、次のいずれかの方法で解決できます。

  • ClientConfig で指定する証明書の値を、Base64 でエンコードされた文字列で PEM 形式の文字列にする。詳細については、CA 証明書をエンコードするをご覧ください。
  • プロバイダがルート認証局によって署名された証明書を使用しない場合は、証明書の信頼チェーンを使用して GKE Identity Service を構成する。詳細については、中間証明書をご覧ください。

証明書の値が間違っている

この問題は、証明書の値が一致していない場合に発生します。この場合、証明書の形式は正しいものの、サーバーと一致しません。また、構成に証明書がなかったことを示す場合もあります。

次のいずれかの状況に該当する場合、証明書の値は誤っていると見なされます。

  • ClientConfig で正しくない証明書の値が共有されている。サーバー証明書の issuer が構成済みの証明書の subject と一致しない場合、証明書の値は正しくありません。
  • ClientConfig の証明書が Base64 エンコードされた文字列ではない。
  • 中間証明書を使用してサーバー証明書を発行する場合に、証明書チェーンが用意されていない。

エラー メッセージ

証明書の値が一致しない場合に表示されるエラー メッセージの例を次に示します。

  • 証明書チェーンが完了していないか、サーバーと一致しない: SSL peer certificate was not OK. Details: SSL certificate problem: unable to get local issuer certificate

  • 証明書チェーンが完全でない（ルートから始まっていないか、連続していない無効な部分チェーンに相当する）: Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.

  • 証明書チェーンは有効だが、OIDC サーバーと一致しない: AIS was expecting the server to have a different certificate

  • 証明書チェーンは有効だが、OIDC サーバーと一致しない: Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.

解決策

ClientConfig で指定する証明書の値には、ID プロバイダと一致する正しい形式の証明書チェーンを含める必要があります。証明書の形式とエンコード方法の詳細については、CA 証明書をエンコードするをご覧ください。

gcloud anthos auth login コマンドで生成された kubeconfig ファイルを使用すると、kubectl コマンドが失敗する

Windows マシンで OIDC を使用し、gcloud anthos auth login コマンドでクラスタ アクセス用の kubeconfig ファイルを生成すると、kubectl コマンドが失敗し、「The command line is too long.」というエラー メッセージが表示されることがあります。この問題は Windows システムでのみ発生し、同じ kubeconfig ファイルを使用している Linux マシンには影響しません。根本的な原因は、ユーザーが多数のグループ（グループ名の長さに応じて約 70～200 グループ）に属している場合に、Azure Active Directory（Azure AD）によって生成される認証トークンのサイズに関連しています。

この大きなトークンは、Windows で許可されているコマンドラインの最大長長（8,191 文字）を超えているため、kubectl コマンドの実行が失敗します。

エラー メッセージ

$ kubectl --kubeconfig test-kubeconfig.yml get nodes

The command line is too long.
The command line is too long.
E0102 11:02:29.115256 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
The command line is too long.
E0102 11:02:29.350238 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
The command line is too long.
E0102 11:02:30.062811 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
Unable to connect to the server: getting credentials: exec: executable gcloud failed with exit code 1

解決策

この問題を解決するには、次の操作を行います。

  • GKE クラスタ バージョン 1.28 以降にアップグレードする

    1.28 より前のバージョンの GKE クラスタを実行している場合は、サポートされているバージョンにアップグレードすることをおすすめします。

  • 影響を受けるユーザーのグループ メンバーシップを減らす

    認証ユーザーが属するグループの数を問題となるしきい値（約 70 グループ）より少なくすることで問題を解決できます。

  • 影響を受けるユーザーのグループ メンバーシップを増やす

    Microsoft Entra ID 機能には、トークンで出力されるグループ数に上限があります。70～200 個のグループ メンバーシップがあると、認証の問題が発生する可能性があります。ただし、グループ メンバーシップの数をこの上限を超えて増やすことで、ID プロバイダの問題を解決できます。この上限のため、メンバーシップの数が過度に多くなると、Azure AD は id_token からグループを省略します。これにより、コマンドラインが長くなりすぎることがなくなり、ID プロバイダの問題が解決します。上限と詳細については、Microsoft Entra ID のドキュメントをご覧ください。