Anthos clusters on VMware は、VMware 用 Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、プロダクトの概要をご覧ください。

Google Distributed Cloud の認証に関する問題のトラブルシューティング

このドキュメントは、Google Distributed Cloud の認証に関する問題のトラブルシューティングについて説明します。一般的なトラブルシューティング情報とガイダンス、および OpenID Connect（OIDC）と Lightweight Directory Access Protocol（LDAP）の具体的な情報を記載します。

OIDC と LDAP の認証では、GKE Identity Service を使用します。Google Distributed Cloud で GKE Identity Service を使用する前に、ID プロバイダを構成する必要があります。GKE Identity Service の ID プロバイダを構成していない場合は、次のいずれかの一般的なプロバイダの手順に沿って構成します。

ID ログを有効にして接続をテストする方法については、GKE Identity Service ID プロバイダのトラブルシューティングガイドをご覧ください。

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。

一般的なトラブルシューティング

Google Distributed Cloud の一般的な認証と認証に関する問題については、次のトラブルシューティングのヒントを参考にしてください。これらの問題が該当しない場合、または OIDC や LDAP に問題がある場合は、GKE Identity Service のトラブルシューティングのセクションに進んでください。

`gcloud anthos auth` を最新に保つ

一般的な問題の多くは、gcloud anthos auth のインストールコンポーネントが最新であることを確認することで回避できます。

確認が必要な部分は 2 つあります。gcloud anthos auth コマンドには Google Cloud CLI コアコンポーネントに対するロジックと、個別にパッケージ化された anthos-auth コンポーネントがあります。

Google Cloud CLI を更新するには:
```
gcloud components update
```
anthos-auth コンポーネントを更新するには:
```
gcloud components install anthos-auth
```

無効なプロバイダ構成

ID プロバイダの構成が無効な場合は、[ログイン] をクリックした後に、ID プロバイダからのエラー画面が表示されます。プロバイダ固有の手順に従って、プロバイダまたはクラスタを正しく構成します。

無効な構成

Google Cloud コンソールでクラスタから OIDC 構成を読み取れない場合、[ログイン] ボタンは無効になります。クラスタ OIDC 構成のトラブルシューティングについては、このドキュメントの次の OIDC のトラブルシューティングのセクションをご覧ください。

無効な権限

認証フローを完了してもクラスタの詳細が表示されない場合は、OIDC で使用したアカウントに適切な RBAC 権限が付与されていることを確認してください。これは、Google Cloud コンソールへのアクセスに使用するアカウントとは異なる場合があります。

更新トークンが見つからない

認可サーバーが同意を求めるプロンプトを表示しても、必要な認証パラメータが指定されなかった場合は、次の問題が発生します。

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

この問題を解決するには、ClientConfig リソースで authentication.oidc.extraParams フィールドに prompt=consent を追加します。次に、クライアント認証ファイルを再生成します。

更新トークンが期限切れ

kubeconfig ファイルの更新トークンが期限切れになると、次の問題が発生します。

Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
    certificate signed by unknown authority

この問題を解決するには、もう一度 gcloud anthos auth login コマンドを実行します。

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 サーバーでユーザーを認可できない場合に発生します。適切な RBAC が指定されていないか、RBAC が正しくない、あるいはクラスタの OIDC 構成にエラーがある場合に、この状況が発生する可能性があります。次のようなエラーが表示されることがあります。

Unauthorized

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

gcloud anthos auth login によって生成された kubeconfig ファイルで、id-token の値をコピーします。
```
kind: Config
...
users:
- name: ...
  user:
    auth-provider:
      config:
        id-token: xxxxyyyy
```
jwt-cli をインストールし、次のコマンドを実行します。
```
jwt ID_TOKEN
```
OIDC 構成を検証します。

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

ClientConfig リソースで group と user に設定されたクレームが ID トークンに存在することを確認します。
適用されている RBAC を確認します。

username-claim で指定したユーザー、または前のステップで取得した group-claim に示されたいずれかのグループに対する適切な権限を持つ RBAC があることを確認します。RBAC 内のユーザー名やグループ名には、ClientConfig リソースで指定された usernameprefix または groupprefix という接頭辞を付ける必要があります。

usernameprefix が空白で、username が email 以外の値の場合、接頭辞はデフォルトの issuerurl# になります。ユーザー名の接頭辞を無効にするには、usernameprefix を - に設定します。

ユーザーおよびグループの接頭辞の詳細については、OIDC による認証をご覧ください。

注: Kubernetes API サーバーはエスケープ文字としてバックスラッシュを使用します。ユーザーまたはグループの名前に \\ が含まれている場合、API サーバーは ID トークンを解析するときに、1 つの \ としてそれを読み取ります。このユーザーまたはグループに適用される RBAC ロールバインディングには、バックスラッシュを 1 つだけ含める必要があります。そうしないと、Unauthorized エラーが発生することがあります。
ClientConfig リソース:
```
oidc:
  ...
  username: "unique_name"
  usernameprefix: "-"
  group: "group"
  groupprefix: "oidc:"
```
ID トークン:
```
{
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\developers"
  ],
...
}
```
次の RBAC バインディングによって、このグループとユーザーに pod-reader クラスタのロールが付与されます。名前フィールドには、ダブルスラッシュではなく、単一スラッシュが使用されています。

グループ ClusterRoleBinding:
```
apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: Group
  name: "oidc:EXAMPLE\developers"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
ユーザー ClusterRoleBinding:
```
apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: User
  name: "EXAMPLE\cluster-developer"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
Kubernetes API サーバーログを確認します。

ID トークンを渡した際に、Kubernetes API サーバーで構成された OIDC プラグインが正しく起動していないと、API サーバーから Unauthorized エラーが返されます。API サーバーで OIDC プラグインに問題があったかどうかを確認するには、次のコマンドを実行します。
```
kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
次のように置き換えます。
- USER_CLUSTER_NAME: ログを表示するユーザークラスタの名前。
- ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイル。

この問題は、gkectl create-login-config に渡された kubeconfig ファイルがユーザークラスタ用ではない場合や、ClientConfig リソースがクラスタの作成時に出てこなかった場合に発生します。

Error getting clientconfig using KUBECONFIG

この問題を解決するには、ユーザークラスタ用に正しい kubeconfig ファイルがあることを確認してください。次に、ClientConfig リソースがクラスタにあるかどうかを確認します。

kubectl get clientconfig default -n kube-public \
  --kubeconfig USER_CLUSTER_KUBECONFIG

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

この問題は、宛先ファイルにすでに存在するクラスタ名を含むログイン構成データの書き込みを試行した場合に発生します。各ログイン構成ファイルには一意のクラスタ名を指定する必要があります。

error merging with file MERGE_FILE because MERGE_FILE contains a cluster with
  the same name as the one read from KUBECONFIG. Please write to a new
  output file

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

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

OIDC のトラブルシューティング

Google Distributed Cloud で OIDC 認証が機能しない場合は、多くの場合、ClientConfig リソース内の OIDC 仕様が正しく構成されていません。ClientConfig リソースは、ログと OIDC 仕様を確認して、OIDC の問題の原因を特定できるようにする手順を提供します。

ID ログを有効にして接続をテストする方法については、GKE Identity Service ID プロバイダのトラブルシューティングガイドをご覧ください。GKE Identity Service が想定どおりに動作していることを確認するか、問題を特定したら、次の OIDC のトラブルシューティング情報を確認します。

クラスタの OIDC 仕様を確認する

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

kubectl get を使用して、クラスタの OIDC リソースを出力します。
```
kubectl --kubeconfig KUBECONFIG -n kube-public get \
  clientconfig.authentication.gke.io default -o yaml
```
KUBECONFIG は、ユーザークラスタ kubeconfig ファイルへのパスに置き換えます。
フィールド値を調べて、OIDC プロバイダに対して仕様が正しく構成されていることを確認します。
仕様で構成の問題を特定した場合は、OIDC を再構成します。
問題をご自身で診断、解決できない場合は、Google Cloud サポートにお問い合わせください。

Google Cloud サポートでは、OIDC の問題を診断して解決するために、GKE Identity Service のログと OIDC 仕様が必要です。

OIDC 認証が有効になっていることを確認する

OIDC 認証をテストする前に、OIDC 認証がクラスタで有効になっていることを確認します。

GKE Identity Service のログを確認します。
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
次の出力例は、OIDC 認証が正しく有効にされていることを示しています。
```
...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...
```
OIDC 認証が正しく有効にされていない場合は、次の例のようなエラーが表示されます。
```
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
```
報告された具体的なエラーを確認し、修正を試みてください。

OIDC 認証をテストする

OIDC 機能を使用するには、UI とブラウザを有効にしたワークステーションを使用します。以下の操作を、テキストベースの SSH セッションから行うことはできません。OIDC がクラスタで正しく機能することをテストするには、次の操作を行います。

Google Cloud CLI をダウンロードします。
ログイン構成ファイルを生成するには、次の gcloud anthos create-login-config コマンドを実行します。
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
KUBECONFIG は、ユーザークラスタ kubeconfig ファイルへのパスに置き換えます。
ユーザーを認証するには、次のコマンドを実行します。
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
次のように置き換えます。
- CLUSTER_NAME は、接続するユーザークラスタの名前に置き換えます。
- AUTH_KUBECONFIG は、クラスタにアクセスするための認証情報を含む、作成する新しい kubeconfig ファイルに置き換えます。詳細については、クラスタに対して認証するをご覧ください。
ローカルワークステーションのデフォルトウェブブラウザに、ログインの同意ページが開きます。このログインプロンプトで、ユーザーの有効な認証情報を指定します。

前のログイン手順を完了すると、kubeconfig ファイルが現在のディレクトリに生成されます。
認証情報を含む新しい kubeconfig ファイルをテストするには、ユーザークラスタ内の Pod を一覧表示します。
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
AUTH_KUBECONFIG は、前の手順で生成した新しい kubeconfig ファイルへのパスに置き換えます。

正常に認証されても、アカウントにロールベースアクセス制御（RBAC）が割り当てられていないことを示す次のようなメッセージが返される場合があります。
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

OIDC 認証ログを確認する

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

kubectl logs を使用して GKE Identity Service のログを出力します。
```
kubectl --kubeconfig KUBECONFIG \
  -n anthos-identity-service logs \
  deployment/ais --all-containers=true
```
KUBECONFIG は、ユーザークラスタ kubeconfig ファイルへのパスに置き換えます。
ログを調べて、OIDC の問題の診断につながるエラーがないかを確認します。

たとえば、ClientConfig リソースの issuerURL に入力ミスがあります（htps://accounts.google.com。https に t がありません）。GKE Identity Service のログには、次の例のようなエントリが含まれます。
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
ログで構成の問題を特定した場合は、OIDC を再構成し、構成の問題を修正します。
問題をご自身で診断して解決できない場合は、Google Cloud サポートにお問い合わせください。Google Cloud サポートでは、OIDC の問題を診断して解決するために、GKE Identity Service のログと OIDC 仕様が必要です。

OIDC の一般的な問題

OIDC 認証に問題がある場合は、以下の一般的な問題を確認してください。問題を解決するためのガイダンスに沿って対応してください。

サービス「ais」に使用できるエンドポイントがない

ClientConfig リソースを保存すると、次のエラーメッセージが返されます。

  Error from server (InternalError): Internal error occurred: failed calling webhook "clientconfigs.validation.com":
  failed to call webhook: Post "https://ais.anthos-identity-service.svc:15000/admission?timeout=10s":
  no endpoints available for service "ais"

このエラーは、正常でない GKE Identity Service エンドポイントが原因で発生します。GKE Identity Service Pod が検証 Webhook を提供できません。

GKE Identity Service Pod が正常でないことを確認するには、次のコマンドを実行します。
```
kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG
```
KUBECONFIG は、ユーザークラスタ kubeconfig ファイルへのパスに置き換えます。

次の出力例は、GKE Identity Service Pod がクラッシュしていることを意味します。
```
NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s
```

Pod に問題がある理由を理解するには、Pod イベントを確認します。

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

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

次の出力例は、イメージを pull するときに権限エラーが発生したことを報告しています。

Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned anthos-identity-service/ais-5949d879cd-flv9w to pool-1-76bbbb8798-dknz5
  Normal   Pulling    8m23s (x4 over 10m)     kubelet            Pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Failed to pull image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": failed to resolve reference "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": pulling from host gcr.io failed with status code [manifests hybrid_identity_charon_20220808_2319_RC00]: 401 Unauthorized
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Error: ErrImagePull
  Warning  Failed     8m10s (x6 over 9m59s)   kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m49s (x21 over 9m59s)  kubelet            Back-off pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"

Pod イベントによって問題が報告された場合は、影響を受けた領域のトラブルシューティングを続けます。サポートが必要な場合は、Google Cloud サポートまでご連絡ください。

サーバーからのレスポンスバイトの読み取りに失敗した

GKE Identity Service のログに次のエラーが記録される場合があります。

  E0516 07:24:38.314681      65 oidc_client.cc:207] Failed fetching the Discovery URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/.well-known/openid-configuration" with error:
  Failed reading response bytes from server.

  E0516 08:24:38.446504      65 oidc_client.cc:223] Failed to fetch the JWKs URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/certs" with error:
  Failed reading response bytes from server.

これらのネットワークエラーは、次のいずれかの形でログに表示されます。

ログにまばらに表示される: 主要な問題ではなく、断続的なネットワークの問題である可能性があります。

GKE Identity Service OIDC プラグインには、OIDC 検出 URL を 5 秒ごとに定期的に同期するデーモンプロセスがあります。ネットワーク接続が不安定な場合、この下り（外向き）リクエストが失敗する場合があります。ときどき発生する障害は、OIDC 認証に影響しません。既存のキャッシュ保存されたデータは再利用できます。

ログにまばらなエラーが記録されている場合は、追加のトラブルシューティング手順に進みます。
ログに常に表示される、または GKE Identity Service が既知のエンドポイントに正常に到達しない: これらの定常的な問題は、GKE Identity Service と OIDC ID の間の接続の問題を示しています。

次のトラブルシューティング手順は、こうした接続の問題の診断に役立ちます。
1. ファイアウォールが GKE Identity Service からのアウトバウンドリクエストをブロックしていないことを確認します。
2. ID プロバイダサーバーが正常に動作していることを確認します。
3. ClientConfig リソースの OIDC 発行者 URL が正しく構成されていることを確認します。
4. ClientConfig リソースのプロキシフィールドを有効にした場合は、下り（外向き）プロキシサーバーのステータスまたはログを確認します。
5. GKE Identity Service Pod と OIDC ID プロバイダサーバーの間の接続をテストします。

サーバーにログインしている必要がある（未承認）

OIDC 認証を使用してログインしようとすると、次のエラーメッセージが表示されることがあります。

  You must be logged in to the server (Unauthorized)

このエラーは Kubernetes 認証の一般的な問題であり、それ以上の情報はありません。ただし、このエラーは構成の問題を示しています。

問題を特定するには、前のセクションのクラスタで OIDC 仕様を確認すると ClientConfig リソースを構成するをご覧ください。

Webhook 認証システムリクエストに失敗した

GKE Identity Service のログに、次のエラーが表示される場合があります。

  E0810 09:58:02.820573       1 webhook.go:127] Failed to make webhook authenticator request:
  error trying to reach service: net/http: TLS handshake timeout

このエラーは、API サーバーが GKE Identity Service Pod との接続を確立できないことを示しています。

GKE Identity Service エンドポイントに外部からアクセスできるかどうかを確認するには、次の curl コマンドを実行します。
```
curl -k  -s -o /dev/null -w "%{http_code}" -X POST \
  https://APISERVER_HOST/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
```
APISERVER_HOST は、API サーバーのアドレスに置き換えます。

想定されるレスポンスは、ステータスコード HTTP 400 です。リクエストがタイムアウトした場合は、GKE Identity Service Pod を再起動します。エラーが続く場合は、GKE Identity Service の HTTP サーバーが起動できないことを意味します。さらにサポートが必要な場合は、Google Cloud サポートにお問い合わせください。

ログイン URL がない

Google Cloud コンソールが ID プロバイダに到達できない場合、ログインしようとすると、URL not found エラーのページにリダイレクトされる問題が発生します。

この問題を解決するには、次のトラブルシューティング手順を試してください。各手順の後、もう一度ログインを試してください。

公共のインターネット経由で ID プロバイダにアクセスできない場合は、OIDC HTTP プロキシを有効にして、Google Cloud コンソールでログインします。ClientConfig カスタムリソースを編集し、useHTTPProxy を true に設定します。
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
USER_CLUSTER_KUBECONFIG は、ユーザークラスタ kubeconfig ファイルのパスに置き換えます。
HTTP プロキシが有効になっていてもこのエラーが発生する場合は、プロキシの起動に問題がある可能性があります。プロキシのログを表示します。
```
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
```
USER_CLUSTER_KUBECONFIG は、ユーザークラスタ kubeconfig ファイルのパスに置き換えます。

ID プロバイダが既知の CA を保有する場合であっても、HTTP プロキシが正常に起動するには、ClientConfig カスタムリソースに oidc.caPath の値を指定する必要があります。
認可サーバーから同意を求めるプロンプトが表示され、extraparam prompt=consent パラメータを指定していない場合は、ClientConfig カスタムリソースを編集して prompt=consent パラメータを extraparams パラメータに追加します。
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
USER_CLUSTER_KUBECONFIG は、ユーザークラスタ kubeconfig ファイルのパスに置き換えます。
ストレージサービスで構成設定が変更された場合は、既存のセッションを明示的にログアウトする必要があります。Google Cloud コンソールで、クラスタの詳細ページに移動し、[ログアウト] を選択します。

LDAP のトラブルシューティング

LDAP 認証に問題がある場合は、次のいずれかの適切な構成ドキュメントに従って環境が設定されていることを確認してください。

また、LDAP サービスアカウントのシークレットを入力し、LDAP 認証を有効にするために ClientConfig リソースを構成していることを確認する必要もあります。

ID ログを有効にして接続をテストする方法については、GKE Identity Service ID プロバイダのトラブルシューティングガイドをご覧ください。GKE Identity Service が想定どおりに動作していることを確認するか、問題を特定したら、次の LDAP のトラブルシューティング情報を確認します。

LDAP 認証が有効になっていることを確認する

LDAP 認証をテストする前に、クラスタで LDAP 認証が有効になっていることを確認してください。

GKE Identity Service のログを確認します。
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
次の出力例は、LDAP 認証が正しく有効にされていることを示しています。
```
...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...
```
LDAP 認証が正しく有効にされていない場合は、次の例のようなエラーが表示されます。
```
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
```
報告された具体的なエラーを確認し、修正を試みてください。

LDAP 認証をテストする

LDAP 機能を使用するには、UI とブラウザを有効にしたワークステーションを使用します。以下の操作を、テキストベースの SSH セッションから行うことはできません。LDAP 認証がクラスタで正常に機能することをテストするには、次の操作を行います。

Google Cloud CLI をダウンロードします。
ログイン構成ファイルを生成するには、次の gcloud anthos create-login-config コマンドを実行します。
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
KUBECONFIG は、ユーザークラスタ kubeconfig ファイルへのパスに置き換えます。
ユーザーを認証するには、次のコマンドを実行します。
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
次のように置き換えます。
- CLUSTER_NAME は、接続するユーザークラスタの名前に置き換えます。
- AUTH_KUBECONFIG は、クラスタにアクセスするための認証情報を含む、作成する新しい kubeconfig ファイルに置き換えます。詳細については、クラスタに対して認証するをご覧ください。
ローカルワークステーションのデフォルトウェブブラウザに、ログインの同意ページが開きます。このログインプロンプトで、ユーザーの有効な認証情報を指定します。

前のログイン手順を完了すると、kubeconfig ファイルが現在のディレクトリに生成されます。
認証情報を含む新しい kubeconfig ファイルをテストするには、ユーザークラスタ内の Pod を一覧表示します。
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
AUTH_KUBECONFIG は、前の手順で生成したユーザークラスタ kubeconfig へのパスに置き換えます。
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

LDAP の一般的な問題

LDAP 認証に問題がある場合は、以下の一般的な問題を確認してください。問題を解決するためのガイダンスに沿って対応してください。

ユーザーが CN 内のカンマによって認証できない

LDAP を使用している場合、CN="a,b" のように、CN にカンマが含まれているとユーザーが認証できないという問題が発生する可能性があります。GKE Identity Service のデバッグログを有効にすると、次のエラーメッセージが報告されます。

  I0207 20:41:32.670377 30 authentication_plugin.cc:977] Unable to query groups from the LDAP server directory.example.com:636, using the LDAP service account
  'CN=svc.anthos_dev,OU=ServiceAccount,DC=directory,DC=example,DC=com'.
  Encountered the following error: Empty entries.

この問題は、GKE Identity Service の LDAP プラグインでカンマが二重にエスケープされるために発生します。この問題は、Google Distributed Cloud 1.13 以前のバージョンでのみ発生します。

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

クラスタを Google Distributed Cloud 1.13 以降にアップグレードします。
CN を使用する代わりに別の identifierAttribute（sAMAccountName など）を選択します。
LDAP ディレクトリの CN 内からカンマを削除します。

Google Cloud CLI 1.4.2 で認証が失敗する

Google Cloud CLI anthos-auth 1.4.2 では、gcloud anthos auth login コマンドを実行すると次のエラーメッセージが表示される場合があります。

  Error: LDAP login failed: could not obtain an STS token: Post "https://127.0.0.1:15001/sts/v1beta/token":
  failed to obtain an endpoint for deployment anthos-identity-service/ais: Unauthorized
  ERROR: Configuring Anthos authentication failed

GKE Identity Service のログに、次のエラーも表示されます。

  I0728 12:43:01.980012      26 authentication_plugin.cc:79] Stopping STS   authentication, unable to decrypt the STS token:
  Decryption failed, no keys in the current key set could decrypt the payload.

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

Google Cloud CLI anthos-auth バージョン 1.4.2 を使用しているかどうかを確認します。
```
gcloud anthos auth version
```
次の出力例は、バージョンが 1.4.2 であることを示しています。
```
Current Version: v1.4.2
```
Google Cloud CLI anthos-auth バージョン 1.4.2 を実行している場合は、バージョン 1.4.3 以降にアップグレードします。

一般的な問題

このセクションでは、認証に関する一般的な問題とその解決方法について説明します。

SSH 認証鍵 `permission denied` エラーにより、管理ワークステーションにアクセスできなくなった

管理ワークステーションに接続しようとすると、次のエラーが発生して、次の例のような "Permission denied" メッセージが受信されます。

Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).

このエラーは、SSH を使用して管理ワークステーションに接続する際に、間違った秘密鍵を使用しているか、鍵が使用されていない場合に発生します。

この問題を解決するには、正しい SSH 認証鍵を見つけて使用します。正しい SSH 認証鍵が見つからない場合は、次の手順で管理ワークステーション用の新しい SSH 認証鍵ペアを生成します。

一時的なレスキュー VM を作成します。このレスキュー VM は、現在の管理ワークステーション VM と同じネットワークと Datastore に接続する必要があります。
管理ワークステーション VM とレスキュー VM の電源をオフにします。
管理ワークステーション VM のデータディスクをレスキュー VM にアタッチします。管理ワークステーションの構成ファイルにブートディスクと異なる別のディスクサイズを指定しない限り、データディスクは通常 512 MB です。
レスキュー VM をパワーオンします。
SSH を使用してレスキュー VM に接続します。
ローカル PC で、新しい SSH 認証鍵ペアを生成します。
ローカル PC で、ssh-copy-id コマンドを使用して新しい SSH 公開鍵をレスキュー VM にコピーします。
```
ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM
```
次のように置き換えます。
- NEW_SSH_KEY は、前の手順で作成した新しい SSH 認証鍵の名前に置き換えます。
- RESCUE_VM は、レスキュー VM の IP アドレスまたは FQDN に置き換えます。
レスキュー VM で、データディスクをマウントします。
```
sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk
```
DEVICE は、独自のディスクの固有識別子（/dev/sdb1 など）に置き換えます。
レスキュー VM で、管理ワークステーション VM からマウントされたデータディスク上の authorized_keys ファイルに、新しい SSH 公開鍵をコピーします。

前の手順で ssh-copy-id コマンドを使用してコピーした新しい SSH 公開鍵を含むレスキュー VM 上の authorized_keys ファイルの内容を表示します。
```
ls ~/.ssh/authorized_keys
```
authorized_keys ファイルから最後の SSH 公開鍵エントリをコピーし、ファイルを閉じます。
管理ワークステーション VM からマウントされたデータディスク上の authorized_keys ファイルを編集します。
```
vi /mnt/ext-disk/.ssh/authorized_keys
```
レスキュー VM の authorized_keys ファイルから SSH 公開鍵の内容を貼り付けます。
管理ワークステーション VM からマウントされたデータディスク上の authorized_keys ファイルを保存して閉じます。
/mnt/ext-disk/.ssh/ 内のファイルに適切な権限が適用されていることを確認します。
```
chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*
```
レスキュー VM への SSH 接続を終了します。
レスキュー VM をシャットダウンします。
レスキュー VM からデータディスクを切断し、ディスクを管理ワークステーション VM に再接続します。
管理ワークステーションをパワーオンします。
VM が正常に実行されたら、SSH と新しい SSH 認証鍵ペアを使用して管理ワークステーションに接続します。
```
ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM
```
次のように置き換えます。
- NEW_SSH_KEY は、前の手順で作成し、管理ワークステーション VM にコピーした新しい SSH 認証鍵の名前に置き換えます。
- RESCUE_VM は、管理ワークステーション VM の IP アドレスまたは FQDN に置き換えます。
SSH を使用して正常に接続できることを確認します。
レスキュー VM を削除します。

次のステップ