本文提供疑難排解指南，說明如何解決使用第三方身分識別提供者向 Fleet 成員叢集進行驗證時，使用者存取權發生問題的情況。
gcloud anthos create-login-config 無法取得 clientconfig
發生這個問題的原因如下：
- 傳遞至
gcloud anthos create-login-config的 kubeconfig 檔案不正確。 - 叢集中沒有 ClientConfig 自訂資源 (叢集未設定第三方驗證)。
錯誤訊息
failed to get clientconfig default in namespace kube-public
解決方案
如要解決這個問題，請按照下列步驟操作：
- 請確認您擁有叢集的正確 kubeconfig 檔案。
如要確認 ClientConfig 自訂資源是否位於叢集中，請執行下列指令：
kubectl --kubeconfig KUBECONFIG get clientconfig default -n kube-public
如果叢集中沒有 ClientConfig，請在叢集上安裝並設定 ClientConfig。如要進一步瞭解叢集設定選項，請參閱「叢集設定選項」。
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://，且 Proxy 設定為使用其他通訊協定 (例如 SOCK5) 處理 HTTPS 連線，GoLang HTTP 用戶端程式庫可能會失敗。
錯誤訊息
proxyconnect tcp: tls: first record does not look like a TLS handshake
解決方案
如要解決這個問題，請修改 https_proxy 和 HTTPS_PROXY 環境變數，省略 https:// prefix。在 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
解決方案
如要解決這個問題，請按照下列步驟操作：
確認登入時使用的設定。
OIDC 設定
使用者叢集設定檔中的
authentication.oidc區段包含group和username欄位，可用於設定 Kubernetes API 伺服器中的--oidc-group-claim和--oidc-username-claim標記。當 API 伺服器收到使用者身分識別權杖時，會將權杖轉送至叢集，叢集會將擷取的group-claim和username-claim傳回 API 伺服器。API 伺服器會使用回應驗證對應群組或使用者是否具備正確權限。確認叢集設定檔
authentication.oidc區段中為group和user設定的要求，是否出現在 ID 權杖中。確認已套用 RBAC 政策。
如要瞭解如何設定正確的 RBAC 政策，請參閱「設定角色型存取權控管 (RBAC)」。
群組的 RBAC 無法用於 OIDC 供應商
確認 ID 權杖是否包含群組資訊
執行
gcloud anthos auth login指令啟動 OIDC 驗證流程後，ID 權杖會儲存在kubeconfig檔案的id-token欄位中。使用 jwt.io 解碼 ID 權杖，並確認權杖是否包含預期的使用者群組資訊。如果 ID 權杖沒有使用者的群組資訊，請根據 OIDC 供應商的文件，正確設定 OIDC 供應商，傳回群組資訊。舉例來說，如果您使用 Okta 識別資訊提供者的 OIDC 設定，請按照 Okta 識別資訊提供者的文件，在 ID 權杖中設定群組。
如果 ID 權杖含有群組資訊，請確認 ID 權杖中的群組資訊金鑰，是否與「
oidc」部分下方的「groupsClaim」欄位設定相符。舉例來說，如果 ID 權杖在
groups鍵中包含群組資訊："groups" : ["group1", "group2" ...]則
oidc區段中的groupsClaim欄位值應為groups。
排解識別資訊提供者問題
如果叢集使用 OIDC 或 LDAP 時發生問題，請按照本節中的步驟排解問題，並判斷身分識別提供者設定是否發生問題。
啟用偵錯記錄
如要協助排解叢集中與身分識別相關的問題，請在 ais Deployment 中啟用 Pod 的偵錯記錄。
使用
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。KUBECONFIG：使用者叢集 kubeconfig 檔案的路徑。
檢查容器記錄
檢查容器記錄的內容，確認是否有任何錯誤或警告。
如要查看記錄，請使用
kubectl logs：kubectl logs -f -l k8s-app=ais \ -n anthos-identity-service \ --kubeconfig KUBECONFIG將
KUBECONFIG替換為使用者叢集 kubeconfig 檔案的路徑。
重新啟動 Pod
如果容器記錄檔顯示問題，請重新啟動 Pod。
如要重新啟動 Pod，請刪除現有 Pod。系統會自動建立新的 Pod 做為替代項目。
kubectl delete pod -l k8s-app=ais \ -n anthos-identity-service \ --kubeconfig KUBECONFIG將
KUBECONFIG替換為使用者叢集 kubeconfig 檔案的路徑。
排解與識別資訊提供者的連線問題
如果 Pod 似乎正常運作，請測試與遠端身分識別提供者的連線。
在同一個命名空間中啟動 busybox Pod：
kubectl run curl --image=radial/busyboxplus:curl \ -n anthos-identity-service -- sleep 3000 \ --kubeconfig KUBECONFIG將
KUBECONFIG替換為使用者叢集 kubeconfig 檔案的路徑。如要檢查是否可以擷取探索網址，請執行 busybox Pod，然後執行
curl指令：kubectl exec pod/curl -n anthos-identity-service -- \ curl ISSUER_URL \ --kubeconfig KUBECONFIG更改下列內容：
ISSUER_URL：身分識別提供者的核發者網址。KUBECONFIG：使用者叢集 kubeconfig 檔案的路徑。
成功的回應會是 JSON 結果，其中包含詳細的識別資訊提供者端點。
如果上一個指令未傳回預期結果，請聯絡身分識別供應商管理員，尋求進一步協助。
LDAP 登入無法用於 Google Distributed Cloud 管理員叢集
目前僅 Google Distributed Cloud 使用者叢集支援 LDAP。