排解使用者存取權問題
本文提供疑難排解指南，協助解決 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
解決方案
如要解決這個問題，請按照下列步驟操作：
- 請確認您擁有叢集的正確 kubeconfig 檔案。
如要確認 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://，且 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 伺服器收到使用者身分權杖時，會將權杖轉送至 GKE Identity Service，後者會將擷取的group-claim和username-claim傳回 API 伺服器。API 伺服器會使用回應驗證對應群組或使用者是否具備正確權限。確認叢集設定檔
authentication.oidc區段中為group和user設定的要求，是否出現在 ID 權杖中。確認已套用 RBAC 政策。
如要瞭解如何為 GKE Identity Service 設定正確的 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。
排解識別資訊提供者問題
如果無法在 GKE 叢集使用 OIDC 或 LDAP，請按照本節中的步驟排解 GKE Identity Service 問題，並判斷識別資訊提供者設定是否有問題。
啟用 GKE Identity Service 偵錯記錄
如要協助排解叢集中的身分識別相關問題，請啟用 GKE Identity Service 偵錯記錄。
使用
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 檔案的路徑。
檢查 GKE Identity Service 容器記錄
查看 GKE Identity Service 容器記錄的內容，瞭解是否有任何錯誤或警告。
如要查看記錄，請使用
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。
如要重新啟動 GKE Identity Service Pod，請刪除現有 Pod。系統會自動建立新的 Pod 做為替代項目。
kubectl delete pod -l k8s-app=ais \ -n anthos-identity-service \ --kubeconfig KUBECONFIG請將
KUBECONFIG改成使用者叢集 kubeconfig 檔案的路徑。
排解與識別資訊提供者的連線問題
如果 GKE Identity Service Pod 似乎正常運作，請測試與遠端身分識別提供者的連線。
在與 GKE Identity Service 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 結果，其中包含詳細的 IDP 端點。
如果上一個指令未傳回預期結果，請聯絡身分識別供應商管理員，尋求進一步協助。
LDAP 登入無法用於 Google Distributed Cloud 管理員叢集
目前僅 Google Distributed Cloud 使用者叢集支援 LDAP。