ユーザー アクセスの問題のトラブルシューティング

このドキュメントでは、GKE Identity Service のユーザー アクセスに関する問題のトラブルシューティングについて説明します。

gcloud anthos create-login-config が clientconfig を取得できない

この問題は、次のいずれかのケースで発生します。

• gcloud anthos create-login-config に渡された kubeconfig ファイルが正しくない。
• ClientConfig カスタム リソースがクラスタに存在しない（GKE Identity Service がクラスタにインストールされていない）。

エラー メッセージ

  failed to get clientconfig default in namespace kube-public
  

解決策

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

1. クラスタに適切な kubeconfig ファイルがあることを確認してください。

2. ClientConfig カスタム リソースがクラスタ内にあるかどうかを確認するには、次のコマンドを実行します。

   kubectl --kubeconfig KUBECONFIG  get clientconfig default -n kube-public
   

   ClientConfig がクラスタに存在しない場合は、クラスタに GKE Identity Service をインストールして構成します。クラスタの設定オプションの詳細については、クラスタの設定オプションをご覧ください。

クラスタ名が重複しているため gcloud anthos create-login-config が失敗する

この問題は、このクラスタのログイン構成がすでに含まれているファイルに、クラスタのログイン構成を作成しようとした場合に発生します。

エラー メッセージ

  error merging with file FILENAME because FILENAME contains a
    cluster with the same name as the one read from KUBECONFIG.
  

解決策

この問題を解決するには、--output フラグを使用して新しい宛先ファイルを指定します。

--output を指定しない場合、このログイン構成データは、現在のディレクトリの kubectl-anthos-config.yaml という名前のファイルに書き込まれます。

gcloud anthos auth login が proxyconnect tcp で失敗する

この問題は、https_proxy または HTTPS_PROXY の環境変数の構成にエラーがある場合に発生します。環境変数に https:// が指定されている場合、SOCK5 などの他のプロトコルを使用して HTTPS 接続を処理するようにプロキシが構成されると、GoLang HTTP クライアント ライブラリが失敗する可能性があります。

エラー メッセージ

  proxyconnect tcp: tls: first record does not look like a TLS handshake
  

解決策

この問題を解決するには、https:// prefix を省略するように、https_proxy 環境変数と HTTPS_PROXY 環境変数を変更します。Windows で、システム環境変数を変更します。たとえば、https_proxy 環境変数の値を https://webproxy.example.com:8000 から webproxy.example.com:8000 に変更します。

gcloud anthos auth login によって生成された kubeconfig を使用すると、クラスタへのアクセスに失敗する

この問題は、次のいずれかの理由で Kubernetes API サーバーがユーザーを認可できない場合に発生します。

• gcloud anthos auth login コマンドを使用してログインする際に使用される構成にエラーがあります。
• ユーザーに必要な RBAC ポリシーが正しくないか、存在しません。

エラー メッセージ

  Unauthorized
  

解決策

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

1. ログインに使用される構成を確認します。

   OIDC 構成

   ユーザー クラスタ構成ファイルの authentication.oidc セクションには、Kubernetes API サーバーの --oidc-group-claim フラグと --oidc-username-claim フラグの設定に使用される group フィールドと username フィールドがあります。API サーバーにユーザーの ID トークンが渡されると、トークンは GKE Identity サービスに転送されます。これにより、抽出された group-claim と username-claim が API サーバーに返されます。API サーバーはレスポンスを使用して、対応するグループまたはユーザーに正しい権限が付与されていることを確認します。

   クラスタ構成ファイルの authentication.oidc セクションで group と user に設定されたクレームが ID トークンに存在することを確認します。

2. 適用された RBAC ポリシーを確認します。

   GKE Identity Service に適切な RBAC ポリシーを設定する方法については、ロールベース アクセス制御（RBAC）を設定するをご覧ください。

OIDC プロバイダでグループの RBAC が機能しない

注: 以下のトラブルシューティング手順は、プロバイダが ClientConfig カスタム リソースの oidc セクションで構成され、enableAccessToken フィールドが false に設定されている場合にのみ適用されます。

1. ID トークンにグループ情報があるかどうかを確認する

   gcloud anthos auth login コマンドを実行して OIDC 認証フローを開始すると、ID トークンが kubeconfig ファイルの id-token フィールドに保存されます。jwt.io を使用して ID トークンをデコードし、想定どおりにユーザーのグループ情報が含まれていることを確認します。

2. ID トークンにユーザーのグループ情報が含まれていない場合は、OIDC プロバイダのドキュメントに従って、グループ情報を返すように OIDC プロバイダを正しく構成します。たとえば、Okta Identity プロバイダの OIDC 構成を使用している場合は、Okta Identity プロバイダのドキュメントに従って ID トークンでグループを構成します。

3. ID トークンにグループ情報が含まれている場合は、ID トークンのグループ情報キーが、oidc セクションで構成されている groupsClaim フィールドと一致しているかどうかを確認します。

   たとえば、ID トークンに groups キーのグループ情報が含まれている場合:

   "groups" : ["group1", "group2" ...]
   

   この場合、groupsClaim フィールドの値は oidc セクションの groups にする必要があります。

   oidc セクションの構成を変更した後は、必ずユーザー アクセスの設定とクラスタへのアクセスに記載されている手順を再度実施してください。

ID プロバイダのトラブルシューティング

GKE クラスタで OIDC や LDAP を使用する際に問題が発生した場合は、このセクションの手順に沿って GKE Identity Service のトラブルシューティングを行い、ID プロバイダの構成に問題があるかどうかを判断してください。

GKE Identity Service デバッグログを有効にする

クラスタで ID 関連の問題をトラブルシューティングするには、GKE Identity Service のデバッグログを有効にします。

1. kubectl patch を使用して既存のクラスタにパッチを適用します。

   kubectl patch deployment ais \
     -n anthos-identity-service --type=json \
     -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value":"--vmodule=cloud/identity/hybrid/charon/*=LOG_LEVEL"}]' \
     --kubeconfig KUBECONFIG
   

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

   • LOG_LEVEL: 最も詳細なログの場合、トラブルシューティング時に、この値をレベル 3 に設定します。

     注: この値をより高い 9 に設定することもできますが、このレベルではコンソールに一部の認証情報が表示される場合があります。

   • KUBECONFIG: ユーザー クラスタの kubeconfig ファイルへのパス。

GKE Identity Service のコンテナログを確認する

GKE Identity Service コンテナログでエラーや警告がないか確認します。

1. ログを確認するには、kubectl logs を使用します。

   kubectl logs -f -l k8s-app=ais \
     -n anthos-identity-service \
     --kubeconfig KUBECONFIG
   

   KUBECONFIG は、ユーザー クラスタ kubeconfig ファイルへのパスに置き換えます。

GKE Identity Service Pod を再起動する

コンテナログに問題が表示された場合は、GKE Identity Service Pod を再起動します。

1. GKE Identity Service Pod を再起動するには、既存の Pod を削除します。置き換え用として新しい Pod が自動的に作成されます。

   kubectl delete pod -l k8s-app=ais \
     -n anthos-identity-service \
     --kubeconfig KUBECONFIG
   

   KUBECONFIG は、ユーザー クラスタ kubeconfig ファイルへのパスに置き換えます。

ID プロバイダへの接続をトラブルシューティングする

GKE Identity Service Pod が正しく実行されている場合は、リモート ID プロバイダへの接続をテストします。

1. GKE Identity Service Pod と同じ Namespace で busybox Pod を起動します。

   kubectl run curl --image=radial/busyboxplus:curl \
     -n anthos-identity-service -- sleep 3000 \
     --kubeconfig KUBECONFIG
   

   KUBECONFIG は、ユーザー クラスタ kubeconfig ファイルへのパスに置き換えます。

2. ディスカバリ URL を取得できるかどうかを確認するには、busybox Pod で実行し、curl コマンドを実行します。

   kubectl exec pod/curl -n anthos-identity-service -- \
     curl ISSUER_URL \
     --kubeconfig KUBECONFIG
   

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

   • ISSUER_URL: ID プロバイダの発行元 URL。
   • KUBECONFIG: ユーザー クラスタの kubeconfig ファイルへのパス。

   正常なレスポンスは、詳細な ID プロバイダ エンドポイントを含む JSON 結果です。

3. 上記のコマンドで想定どおりの結果が返されない場合は、ID プロバイダの管理者にお問い合わせください。

Google Distributed Cloud 管理クラスタで LDAP ログインが機能しない

現在、LDAP は Google Distributed Cloud ユーザー クラスタでのみサポートされています。