本文有助於排解 Google Distributed Cloud 中的驗證問題。本文提供一般疑難排解資訊和指引,以及 OpenID Connect (OIDC) 和輕量型目錄存取通訊協定 (LDAP) 的特定資訊。
OIDC 和 LDAP 驗證會使用 GKE Identity Service。如要在 Google Distributed Cloud 中使用 GKE Identity Service,請先設定識別資訊提供者。如果您尚未為 GKE Identity Service 設定識別資訊提供者,請按照下列常見提供者的操作說明操作:
請參閱 GKE Identity Service 身份識別提供者疑難排解指南,瞭解如何啟用及查看身分識別記錄,並測試連線。
一般疑難排解
下列疑難排解提示可協助解決 Google Distributed Cloud 的一般驗證和授權問題。如果這些問題不適用,或您有 OIDC 或 LDAP 相關問題,請繼續參閱排解 GKE Identity Service 問題一節。
確保 gcloud anthos auth
為最新版本
請確認 gcloud anthos auth
安裝的元件是否為最新版本,避免發生許多常見問題。
您必須驗證兩項資訊。gcloud anthos auth
指令在 Google Cloud CLI 核心元件中具有邏輯,且為個別封裝的 anthos-auth
元件。
如要更新 Google Cloud CLI,請按照下列步驟操作:
gcloud components update
如要更新
anthos-auth
元件,請按照下列步驟操作:gcloud components install anthos-auth
提供者設定無效
如果識別資訊提供者設定無效,點選「登入」後,您會看到識別資訊提供者的錯誤畫面。 按照供應商專屬的操作說明,正確設定供應商或叢集。
設定無效
如果 Google Cloud 控制台無法從叢集讀取 OIDC 設定,「登入」按鈕就會停用。如要排解叢集 OIDC 設定問題,請參閱本文的「排解 OIDC 問題」一節。
權限無效
如果完成驗證流程,但仍未看到叢集的詳細資料,請確認您已將正確的 RBAC 權限授予搭配 OIDC 使用的帳戶。這個帳戶可能與您用來存取 Google Cloud 控制台的帳戶不同。
缺少更新權杖
授權伺服器提示同意聲明,但未提供必要的驗證參數,就會發生下列問題。
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
如要解決這個問題,請在 ClientConfig
資源中,將 prompt=consent
加入 authentication.oidc.extraParams
欄位。然後重新產生用戶端驗證檔案。
更新權杖已過期
如果 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://
,且 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 伺服器無法授權使用者,就會發生這個問題。如果缺少或不正確的 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 Service,後者會將擷取的group-claim
和username-claim
傳回 API 伺服器。API 伺服器會使用回應,確認對應的群組或使用者是否具備正確權限。確認 ID 權杖中是否包含為
group
和user
設定的憑證,這些憑證位於ClientConfig
資源中。檢查已套用的 RBAC。
確認使用者 (由
username-claim
指定) 或上一個步驟列出的其中一個群組,具有正確權限的 RBAC。group-claim
RBAC 中的使用者或群組名稱應以ClientConfig
資源中指定的usernameprefix
或groupprefix
為前置字元。如果
usernameprefix
為空白,且username
的值不是email
,則前置字元預設為issuerurl#
。如要停用使用者名稱前置字串,請將usernameprefix
設為-
。如要進一步瞭解使用者和群組前置字元,請參閱「使用 OIDC 進行驗證」。
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 伺服器記錄。
如果 Kubernetes API 伺服器中設定的 OIDC 外掛程式無法正確啟動,API 伺服器會在收到 ID 權杖時傳回
Unauthorized
錯誤。如要查看 API 伺服器中的 OIDC 外掛程式是否有任何問題,請執行下列指令:kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
更改下列內容:
USER_CLUSTER_NAME
:要查看記錄的使用者叢集名稱。ADMIN_CLUSTER_KUBECONFIG
:管理員叢集 kubeconfig 檔案。
驗證叢集設定時發生錯誤
嘗試執行 bmctl
指令時,可能會遇到下列錯誤:
Error validating cluster config: 3 errors occurred:
* GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
* ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
* GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
發生這個錯誤可能是因為您使用的服務帳戶金鑰已過期。如要產生新的服務帳戶金鑰,請按照「建立及刪除服務帳戶金鑰」一文中的操作說明進行。
OIDC 疑難排解
如果 Google Distributed Cloud 的 OIDC 驗證無法運作,通常是因為 ClientConfig
資源中的 OIDC 規格設定有誤。ClientConfig
資源提供查看記錄和 OIDC 規格的操作說明,有助於找出 OIDC 問題的原因。
請參閱 GKE Identity Service 身份識別提供者疑難排解指南,瞭解如何啟用及查看身分識別記錄,並測試連線。確認 GKE Identity Service 運作正常或發現問題後,請參閱下列 OIDC 疑難排解資訊。
檢查叢集中的 OIDC 規格
叢集的 OIDC 資訊會指定在 kube-public
命名空間的 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 支援團隊需要 GKE Identity Service 記錄和 OIDC 規格,才能診斷及解決 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 支援團隊需要 GKE Identity Service 記錄和 OIDC 規格,才能診斷及解決 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 檔案的路徑。以下範例輸出內容會在提取映像檔時回報權限錯誤:
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 外掛程式具有精靈程序,可每 5 秒定期同步 OIDC 探索網址。如果網路連線不穩定,這項輸出要求可能會失敗。偶爾發生失敗情形不會影響 OIDC 驗證。現有的快取資料可以重複使用。
如果記錄檔中出現備用錯誤,請繼續執行其他疑難排解步驟。
持續顯示在記錄中,或 GKE Identity Service 從未成功連上已知端點:這些持續發生的問題表示 GKE Identity Service 與 OIDC 身分識別提供者之間有連線問題。
請按照下列疑難排解步驟,診斷連線問題:
- 請確認防火牆未封鎖 GKE Identity Service 的傳出要求。
- 確認身分識別提供者伺服器正常運作。
- 確認
ClientConfig
資源中的 OIDC 簽發者網址設定正確無誤。 - 如果您在
ClientConfig
資源中啟用 Proxy 欄位,請查看輸出 Proxy 伺服器的狀態或記錄。 - 測試連線:在 GKE Identity Service Pod 和 OIDC 識別資訊提供者伺服器之間。
你必須登入伺服器 (未經授權)
嘗試使用 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 。
找不到登入網址
如果 Google Cloud 控制台無法連線至身分識別提供者,就會發生下列問題。嘗試登入時,系統會將您重新導向至顯示 URL not found
錯誤的頁面。
如要解決這個問題,請參閱下列疑難排解步驟。完成每個步驟後,請再次嘗試登入:
如果無法透過公開網際網路連線至身分識別提供者,請啟用 OIDC HTTP Proxy,透過 Google Cloud 控制台登入。編輯
ClientConfig
自訂資源,並將useHTTPProxy
設為true
:kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
請將
USER_CLUSTER_KUBECONFIG
替換為使用者叢集 kubeconfig 檔案的路徑。如果已啟用 HTTP Proxy,但仍發生這項錯誤,可能是 Proxy 啟動時發生問題。查看 Proxy 的記錄:
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
請將
USER_CLUSTER_KUBECONFIG
替換為使用者叢集 kubeconfig 檔案的路徑。即使您的身分識別提供者有知名 CA,您也必須在
ClientConfig
自訂資源中為oidc.caPath
提供值,HTTP Proxy 才能順利啟動。如果授權伺服器提示要求同意聲明,但您尚未加入
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 服務帳戶密鑰,並設定 ClientConfig
資源以啟用 LDAP 驗證。
請參閱 GKE Identity Service 身份識別提供者疑難排解指南,瞭解如何啟用及查看身分識別記錄,並測試連線。確認 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 含有半形逗號 (例如 CN="a,b"
),可能會發生使用者無法驗證的問題。如果您為 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 以上版本。
- 請選擇其他
identifierAttribute
,例如sAMAccountName
,而非使用 CN。 - 從 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 以上版本。
後續步驟
如需其他協助,請與 Cloud Customer Care 團隊聯絡。如要進一步瞭解支援資源,包括下列項目,請參閱「取得支援」: