設定 Cloud Service Mesh 使用者驗證

如果您有 TRAFFIC_DIRECTOR 控制層實作，則這項功能僅支援許可清單。請與支援團隊聯絡，要求將這項功能列入貴機構的許可清單

Cloud Service Mesh 使用者驗證是一項整合式解決方案，可針對以瀏覽器為基礎的使用者驗證，以及已部署工作負載的存取權控管進行驗證。您可以整合現有的身分識別提供者 (IDP) 進行使用者驗證，並使用 Istio API 和授權政策進行存取權管理。這是 Istio JSON Web Token (JWT) 驗證的友善替代方案。

典型用途是指機構使用 Cloud Service Mesh 代管網路應用程式，讓員工透過網路瀏覽器存取。此外，機構必須使用現有的身分提供者來管理使用者身分。Cloud Service Mesh 使用者驗證功能可讓使用者輕鬆透過標準的網路版 OpenID Connect (OIDC) 登入和同意流程進行驗證。使用者驗證時，Cloud Service Mesh 會強制執行 Istio 授權政策，並在授權成功後，以安全憑證格式將身分識別資訊傳送至工作負載。

運作方式

Cloud Service Mesh 使用者驗證功能推出了新的元件 authservice。這個元件會與以 Envoy 為基礎的入口整合，做為外部授權服務，攔截所有傳入的驗證要求。authservice 會實作 OIDC 通訊協定的用戶端，並讓使用者透過瀏覽器存取應用程式，在使用者完成互動式驗證和同意流程，以建立短期工作階段。authservice 實作業界標準通訊協定，可與任何可擔任 OIDC 授權伺服器的 ID 提供者整合。使用者完成驗證後，實體資訊會以 JWT 格式封裝在 RCToken 中，並由 authservice 簽署，然後轉送至入口中的 Istio 授權層。這個模型可為進入網格的流量提供外圍存取權控管機制。如果使用者有權存取資源，這個 RCToken 也會轉送至微服務，以便取得主體資訊並強制執行精細的存取權控管。

下圖顯示 authservice 在網格中的位置，以及與網格中其他部分 (例如入口、工作負載、使用者的瀏覽器和任何現有的 IDP) 的關聯方式。

管理員可以將 authservice 安裝為 Cloud Service Mesh 安裝作業的外掛程式。安裝後，authservice 會讀取 OIDC 端點設定和 UserAuth 自訂資源中定義的其他相關設定。系統管理員可以使用 Cloud Service Mesh ExternalAuthorization API 將 auth_server 設為入站的篩選器。

安裝使用者驗證服務

下列步驟說明如何設定 authservice。

必要條件

• 安裝必要工具
• 下載 asmcli
• 授予叢集管理員權限
• 驗證專案和叢集

• 如果您在私人叢集中使用受管理的 Cloud Service Mesh，請確認叢集能夠將傳出流量傳送至 IDP。

此外，請按照下列步驟確認您符合必要條件。

自訂安裝使用者驗證重疊畫面

如要安裝使用者驗證服務，您必須自訂 Cloud Service Mesh 安裝作業，以便新增網格層級外部授權提供者。所需步驟取決於您是使用代管或叢集內的 Cloud Service Mesh。

準備 OIDC 用戶端設定

請按照下列步驟設定 OIDC 用戶端設定。本指南使用 Google 做為 IDP，但您可以使用任何支援 OIDC 驗證的 IDP。

1. 在 Google Cloud 控制台中，依序前往「API 和服務」>「憑證」。

   前往「憑證」

2. 前往「Create Credentials」(建立憑證)，然後選擇「OAuth client ID」(OAuth 用戶端 ID)。視需要設定 OAuth 同意畫面選項，然後設定下列選項：

   • 將「應用程式類型」設為「網頁應用程式」。
   • 將「已授權的重新導向 URI」設為 https://REDIRECT_HOST/REDIRECT_PATH。舉例來說，您可以將本機設定為 https://localhost:8443/_gcp_asm_authenticate。

   點選「儲存」。

3. 此外，請儲存 OIDC 用戶端設定，以供日後使用。

   export OIDC_CLIENT_ID=CLIENT_ID
   export OIDC_CLIENT_SECRET=CLIENT_SECRET
   export OIDC_ISSUER_URI=ISSUER_URI
   export OIDC_REDIRECT_HOST=REDIRECT_HOST
   export OIDC_REDIRECT_PATH=REDIRECT_PATH
   

取得 kpt 套件

請按照下列步驟，從公開存放區安裝建議的 authservice 設定。這些指令會擷取最新的 authservice 容器，並在 asm-user-auth 命名空間中以 Pod 的形式啟動該容器。並設定 ingress 來攔截所有要求。

取得 kpt 套件：

kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.5 .
cd asm-user-auth/

設定輸入閘道的重新導向網址和密鑰

OAuth2 需要在 HTTPS 受保護的端點上代管的重新導向網址。這些指令僅供示範，可為 Istio 輸入閘道產生自行簽署的憑證，藉此簡化設定程序。

1. 產生自行簽署的憑證：

   openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \
    -days 365 -nodes -subj '/CN=localhost'
   

2. 為輸入閘道建立機密，以便代管 HTTPS 流量：

   kubectl create -n asm-user-auth secret tls userauth-tls-cert --key=key.pem \
   --cert=cert.pem
   

套用加密和簽署金鑰

authservice 需要兩組鍵才能順利運作。第一個是用於加密和解密的對稱金鑰。這個鍵用於在將工作階段狀態設為 Cookie 之前，先將其加密。

第二組金鑰則是公開/私密金鑰組。這個金鑰可用來以 JWT 格式簽署已驗證的使用者資訊，並做為 RCToken。這組金鑰的公開金鑰會在預先定義的端點發布，讓 sidecar 用於驗證 JWT。

使用者驗證 kpt 套件包含兩個範例金鑰，可快速設定。不過，您可以改用偏好的金鑰管理系統來產生這些金鑰。

1. 請使用下列格式準備工作階段加密金鑰，或使用 pkg 中的範例，您可以透過 cat ./samples/cookie_encryption_key.json 查看。

   {
     "keys":[
        {
           "kty":"oct",
           "kid":"key-0",
           "K":"YOUR_KEY",
           "useAfter": 1612813735
        }
     ]
   }
   

   您可以使用下列指令產生測試 AES 金鑰：

   openssl enc -aes-256-cbc -k mycustomkey -P -md sha1 | grep key
   

2. 請使用下列格式準備 RCToken 簽署金鑰，或是使用 pkg 中的範例，您可以透過 cat ./samples/rctoken_signing_key.json 查看。

   {
     "keys":[
        {
           "kty":"RSA",
           "kid":"rsa-signing-key",
           "K":"YOUR_KEY",  # k contains a Base64 encoded PEM format RSA signing key.
           "useAfter": 1612813735  # unix timestamp
        }
     ]
   }
   

   您可以使用下列指令產生測試用的 512 位元 RSA 私密金鑰：

   openssl genpkey -algorithm RSA -out rsa_private.pem -pkeyopt rsa_keygen_bits:512
   

3. 建立 kubernetes 密鑰，authservice 會將其掛接至自己的檔案系統。

   kubectl create secret generic secret-key  \
       --from-file="session_cookie.key"="./samples/cookie_encryption_key.json" \
       --from-file="rctoken.key"="./samples/rctoken_signing_key.json"  \
       --namespace=asm-user-auth
   

部署使用者驗證服務

下列指令會在 asm-user-auth 命名空間中建立使用者驗證服務和部署作業。

設定使用者驗證設定所需的值。用戶端 ID 和密碼會儲存為 Kubernetes 密碼，因此我們會使用 Base64 進行編碼。請前往公開存放區查看所有可用的 setter。

kpt fn eval pkg --image gcr.io/kpt-fn/apply-setters:v0.2 --truncate-output=false -- \
  client-id="$(echo -n ${OIDC_CLIENT_ID} | base64 -w0)" \
  client-secret="$(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0)" \
  issuer-uri="${OIDC_ISSUER_URI}" \
  redirect-host="${OIDC_REDIRECT_HOST}" \
  redirect-path="${OIDC_REDIRECT_PATH}"

套用 kpt 套件：

# Remove the potential alpha version CRD if exists.
kubectl delete crd userauthconfigs.security.anthos.io
kubectl apply -f ./pkg/asm_user_auth_config_v1beta1.yaml
kubectl apply -f ./pkg

authservice 會使用 UserAuthConfig CRD 提供使用者驗證。UserAuthConfig 可在執行階段進行設定，您可以更新 UserAuthConfig 來變更 authservice 行為，並為任何 OIDC 授權伺服器設定端點。

您可以透過 cat pkg/user_auth_config.yaml 查看檔案，檔案包含下列欄位：

apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
  name: user-auth-config
  namespace: asm-user-auth
spec:
  authentication:
    oidc:
      certificateAuthorityData: ""  # kpt-set: ${ca-cert}
      issuerURI: "<your issuer uri>"  # kpt-set: ${issuer-uri}
      proxy: ""  # kpt-set: ${proxy}
      oauthCredentialsSecret:
        name: "oauth-secret"  # kpt-set: ${secret-name}
        namespace: "asm-user-auth"  # kpt-set: ${secret-namespace}
      redirectURIHost: ""  # kpt-set: ${redirect-host}
      redirectURIPath: "/_gcp_asm_authenticate"  # kpt-set: ${redirect-path}
      scopes: ""  # kpt-set: ${scopes}
      groupsClaim: ""  # kpt-set: ${groups}
  outputJWTAudience: "test_audience"  # kpt-set: ${jwt-audience}

如要進一步瞭解 user_auth_config.yaml 欄位的詳細說明，請參閱使用者驗證設定詳細資料。

設定 API 要求 ID

API 要求 ID 是一組 一般運算語言 (CEL) 運算式，可供 Cloud Service Mesh 使用者驗證功能用於識別 API 要求。定義這些 ID 後，您就能啟用 Cloud Service Mesh 使用者驗證功能，以符合語意處理 API 要求驗證失敗情形。

具體來說，當您提供可識別 API 要求的 CEL 運算式時，Cloud Service Mesh 使用者驗證功能會在未經認證的 API 要求失敗時，傳回 401-Unauthorized 狀態碼。這對 CLI 和服務帳戶等用戶端而言至關重要，因為這些用戶端會預期未經驗證的 API 要求會傳回這個狀態碼。

如果沒有 API 要求 ID，Cloud Service Mesh 使用者驗證功能會將所有未經驗證的要求重新導向至已設定的 OpenID Connect (OIDC) 提供者，並傳回 302-Found 狀態碼。對於 API 要求而言，這種重新導向行為通常不受歡迎，因為這類要求會在失敗時傳回 401-Unauthorized。

如要定義 API 要求 ID，請在 UserAuthConfig CR 中新增 apiRequestIdentifier 部分。這樣一來，您就能新增多個 CEL 運算式。如果提供多個 CEL 運算式，系統會將至少符合其中一個運算式的請求視為 API 要求。

以下範例說明如何指定為 API 要求：任何包含標頭 example-api-header 的要求、任何導向主機 api.example.com 的要求，或任何指定 /v1/api/ 底下路徑的要求。

apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
  name: user-auth-config
  namespace: asm-user-auth
spec:
  authentication:
    oidc:
      certificateAuthorityData: ""  # kpt-set: ${ca-cert}
      issuerURI: "<your issuer uri>"  # kpt-set: ${issuer-uri}
      proxy: ""  # kpt-set: ${proxy}
      oauthCredentialsSecret:
        name: "oauth-secret"  # kpt-set: ${secret-name}
        namespace: "asm-user-auth"  # kpt-set: ${secret-namespace}
      redirectURIHost: ""  # kpt-set: ${redirect-host}
      redirectURIPath: "/_gcp_asm_authenticate"  # kpt-set: ${redirect-path}
      scopes: ""  # kpt-set: ${scopes}
      groupsClaim: ""  # kpt-set: ${groups}
  outputJWTAudience: "test_audience"  # kpt-set: ${jwt-audience}
  apiRequestIdentifier: 
    name: "api-request-identifiers"
    expressions: 
    - "'example-api-header' in http_request.headers"
    - "http_request.host == api.example.com"
    - "matches(http_request.path, '/v1/api/(.*)')"
    # other expressions go here

您可以使用下列欄位建立 Cloud Service Mesh 使用者驗證 CEL 運算式：

1. http_request.headers：HTTP 要求標頭的對應，其中鍵為小寫字母字串，值為字串的向量。

   在 CEL 運算式中使用這個欄位，將含有特定標頭的要求指定為 API 要求。

2. http_request.host：要求的 HTTP 網址主機 (例如 api.example.com)。

   在 CEL 運算式中使用這個欄位，將要求指定為 API 要求。

3. http_request.path：要求的 HTTP 網址路徑 (例如 /example-api-path)。此路徑一律以「/」開頭，且不包含要求網址的查詢元件。

   在 CEL 運算式中使用這個欄位，將含有特定路徑的要求指定為 API 要求。

下一節將顯示 CEL 運算式的範例，這些運算式會檢查並比對這些欄位的部分內容，以便告知 Cloud Service Mesh 使用者驗證如何判斷哪些要求是 API 要求。

運算式範例

比對並找出包含標頭 X-API-Key 的所有要求：

"'x-api-key' in http_request.headers"

比對所有要求，並將標頭 X-API-Key 設為特定值：

"'x-api-key' in http_request.headers && http_request.headers['x-api-key'].values == ['example-value ']"

比對並找出傳送至主機 api.example.com 的所有要求：

"http_request.host == api.example.com"

比對所有路徑為 /api/query 的要求：

"http_request.path == /api/query"

比對 /api/ 下所有路徑的所有要求：

"matches(http_request.path, '/api/(.*)')"

執行安裝後工作

完成先前的安裝步驟後，請完成下列必要工作。

為應用程式啟用使用者驗證功能

本節將以 httpbin 為例，說明如何啟用使用者驗證。

Cloud Service Mesh 使用者驗證會使用 CUSTOM 類型的授權政策，觸發 OIDC 流程。

安裝 Istio 閘道後，請將其設定為使用您先前建立的 TLS 憑證 userauth-tls-cert 提供 HTTPS 流量。以下是您剛安裝的 pkg/gateway.yaml 設定。

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: userauth
  namespace: asm-user-auth
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: userauth-tls-cert
---
# This ensures the OIDC endpoint has at least some route defined.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: userauth-oidc
  namespace: asm-user-auth
spec:
  gateways:
  - userauth
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /status
    - uri:
        prefix: "your-oidc-redirect-path"
    name: user-auth-route
    route:
    - destination:
        host: authservice
        port:
          number: 10004

1. 標記 default 命名空間，為部署啟用 istio-proxy 自動注入功能。

   kubectl label namespace default istio.io/rev=REVISION --overwrite
   

2. 將 httpbin 部署至 default 命名空間。

   kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml -n default
   

3. 更新 httpbin，以便使用這個閘道提供 HTTPS 流量，並使用通訊埠轉送功能在本機存取應用程式：

   kubectl apply -f./samples/httpbin-route.yaml -n default
   kubectl port-forward service/istio-ingressgateway 8443:443 -n asm-user-auth
   

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: httpbin
     namespace: default
   spec:
     gateways:
     - asm-user-auth/userauth
     hosts:
     - '*'
     http:
     - match:
       - uri:
           prefix: /ip
       - uri:
           prefix: /headers
       name: httpbin-routes
       route:
       - destination:
           host: httpbin.default.svc.cluster.local
           port:
             number: 8000
   

   位於 8443 通訊埠的入口網關會轉送至 localhost，讓應用程式可在本機存取。

4. 部署 samples/rctoken-authz.yaml，啟用 RequestAuthentication 和 AuthorizationPolicy，以便驗證要求的 RCToken。

   kubectl apply -f ./samples/rctoken-authz.yaml -n asm-user-auth
   

   samples/rctoken-authz.yaml 範例：

   apiVersion: security.istio.io/v1beta1
   kind: RequestAuthentication
   metadata:
     name: require-rc-token
   spec:
     selector:
       matchLabels:
         istio: ingressgateway
     jwtRules:
     - issuer: "authservice.asm-user-auth.svc.cluster.local"
       audiences:
       - "test_audience"
       jwksUri: "http://authservice.asm-user-auth.svc.cluster.local:10004/_gcp_user_auth/jwks"
       fromHeaders:
       - name: X-ASM-RCTOKEN
       forwardOriginalToken: true
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: require-rc-token
   spec:
     selector:
       matchLabels:
         istio: ingressgateway
     action: ALLOW
     rules:
     - when:
       - key: request.auth.claims[iss]
         values:
         - authservice.asm-user-auth.svc.cluster.local
       - key: request.auth.claims[aud]
         values:
         - test_audience
   

驗證使用者驗證

httpbin 提供兩個路徑，/ip 可供大眾存取，/headers 則要求使用者透過已設定的 IDP 登入。

1. 請確認您可以直接造訪 https://localhost:8443/ip 來存取 /ip。

2. 前往 https://localhost:8443/headers，確認您看到 OIDC 登入頁面。

3. 登入後，請按一下「Next」，確認系統會將您重新導向至 /headers 頁面。

設定授權政策

完成前述步驟中的設定後，每位使用者都會透過網路驗證流程重新導向。流程完成後，authservice 會以 JWT 格式產生 RCToken，用於傳送已驗證的使用者資訊。

1. 在入口處新增 Istio 授權政策，確保每位已驗證的使用者都會進行授權檢查：

   kubectl apply -f ./samples/httpbin-authz.yaml -n asm-user-auth
   

2. httpbin-authz.yaml 檔案會設定入口網關，以便驗證 authservice 核發的 RC 權杖，並只在 JWT 包含所需欄位 (例如目標對象和發出者) 時授權。

   請參閱以下授權政策範例：

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: require-rc-token
   spec:
     selector:
       matchLabels:
         istio: ingressgateway
     action: ALLOW
     rules:
     - to:
       - operation:
           paths: ["/ip"]
     - to:
       when:
       - key: request.auth.claims[iss]
         values:
         - authservice.asm-user-auth.svc.cluster.local
       - key: request.auth.claims[aud]
         values:
         - test_audience
       - key: request.auth.claims[sub]
         values:
         - allowed_user_sub_1  # Change this with the "sub" claim in the RC token. Wildcard '*' will match everything.
   

設定特定環境設定

先前的步驟會使用 localhost 和自行簽署的 HTTPS 憑證，以便快速設定。如要用於實際的正式版使用情境，請使用自己的網域，例如 example.com。

此外，請確認 certificateAuthorityData 含有預期的根憑證內容。舉例來說，如果 IDP 已透過系統的根憑證獲得信任，您可以將這項屬性留空。如果有 HTTPS Proxy 終止 HTTPS 連線，則應將其設為 Proxy 的根憑證。

管理及輪替金鑰

authservice 使用兩組鍵。您可以個別旋轉每個鍵。不過，在旋轉金鑰之前，請務必瞭解旋轉的運作方式。

這兩個鍵都是 JSON 格式。useAfter 欄位會指定自金鑰可供使用起算的時間戳記。在金鑰輪替期間，您應在 JSON 中同時納入舊金鑰和新金鑰。舉例來說，在以下範例中，new-key 只會在時間戳記 1712813735 之後使用。

{
   "keys":[
      {
         "kty":"RSA",
         "kid":"old-key",
         "K":"...", # k contains a Base64 encoded PEM format RSA signing key.
         "useAfter": 1612813735, # unix timestamp
      }
      {
      "kty":"RSA",
         "kid":"new-key",
         "K":"...", # k contains a Base64 encoded PEM format RSA signing key.
         "useAfter": 1712813735, # unix timestamp
      }
   ]
}

Cloud Service Mesh 會使用對稱金鑰，加密儲存在瀏覽器 Cookie 中的工作階段資料。為確保現有工作階段的有效性，authservice 會嘗試使用金鑰組合中的所有金鑰進行解密。輪替後，authservice 會使用新金鑰加密新工作階段，並繼續嘗試使用舊金鑰解密。

公開/私密金鑰組用於簽署 RCToken。istiod 會將公開金鑰傳送至側載，以便驗證 JWT。在 authservice 開始使用新的私密金鑰為 RCToken 簽署之前，側載程式必須先收到新的公開金鑰。為此，authservice 會在新增金鑰後立即開始發布公開金鑰，但會等待一段相當長的時間，才開始使用該金鑰簽署 RCToken。

總結來說，執行金鑰輪替時，建議您採取下列做法：

1. 定期輪替金鑰，或視需要進行金鑰輪替。
2. 在 JSON 格式中，同時加入目前和新的鍵。新的金鑰應與日後的時間戳記建立關聯。建議您指定的時間戳記至少要比目前時間早幾小時。
3. 監控並確認新金鑰使用後，服務是否仍處於正常狀態。使用新金鑰後，請等待至少一天再進行下一個步驟。
4. 從 JSON 項目中移除舊的索引鍵。因為不再需要使用。

多叢集部署

Cloud Service Mesh 使用者驗證功能支援多叢集部署。您需要按照上述方式在每個叢集中部署使用者驗證機制。使用者驗證設定 (例如 UserAuth 自訂資源、OIDC 用戶端密鑰、加密金鑰) 都必須在各個叢集中複製。

根據預設，輸入網關會將驗證要求平衡分配給任何一個 authservice 執行個體。您可以使用目的地規則設定入口網關，將要求傳送至同一叢集中的 authservice，並只將要求移轉至其他叢集的 authservice。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: authservice-fail-over
  namespace: asm-user-auth
spec:
  host: authservice.asm-user-auth.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
        - from:  us-east
          to: us-west
        - from: us-west
          to: us-east

這項設定與其他設定一樣，需要在每個叢集中進行設定。

自訂宣告對應

如要設定自訂宣稱對應，請設定 spec.authentication.oidc.attributeMapping，以便定義原始 ID 提供者的 ID 權杖的任何對應項目。鍵會是 RCToken 中的權杖名稱，而值則是如何剖析 IDToken 權杖的 CEL 運算式，並使用 assertion 參照 IDToken。

範例：

spec:
  authentication:
    oidc:
      attributeMapping:
        aud_copy: assertion.aud
        decision: 'assertion.sub.startsWith("123") ? "success" : "fail"'

在 RCToken 中，巢狀憑證 attributes 包含已設定的憑證：

"attributes": {
    "aud_copy": "foo.googleusercontent.com",
    "decision": "success"
}

如果 CEL 運算式無法剖析 ID 權杖中的值，則會忽略權杖，但不會導致驗證流程失敗。

使用者驗證升級

1. 請再次安裝 user-auth 套件，因為其中包含新版 user-auth 的更新二進位檔：

   kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.5 .
   cd asm-user-auth/
   

2. 儲存 OIDC 用戶端設定：

   export OIDC_CLIENT_ID=CLIENT_ID
   export OIDC_CLIENT_SECRET=CLIENT_SECRET
   export OIDC_ISSUER_URI=ISSUER_URI
   export OIDC_REDIRECT_HOST=REDIRECT_HOST
   export OIDC_REDIRECT_PATH=REDIRECT_PATH
   

3. 部署使用者驗證服務，以便升級至新版本。

使用者驗證設定詳細資料

下表說明 CRD 中的各個欄位：

疑難排解

1. 可透過網路存取 IDP。

   可能的記錄：error: TLS handshake failed.。

   如要驗證，請從附加至 istio-proxy 的暫時性容器執行 curl，以呼叫 ID 提供者發出者 URI。例如，請參閱「收集 Cloud Service Mesh 記錄」。

   如果無法連線，請檢查叢集的防火牆規則或其他網路設定。

2. 根 CA 憑證。

   可能的記錄：error: The server's TLS certificate did not match expectations. 或 error: TLS handshake failed.。

   請確認 certificateAuthorityData 持有正確的根 CA 憑證。如果沒有 HTTPS Proxy 終止 HTTPS 流量，則應保留 IDP 的根 CA 憑證。如果有，則應改為保留 Proxy。

3. 重新導向路徑設定。

   可能的觀察結果：在 OIDC 驗證流程中收到 404 錯誤頁面。

   使用者驗證會傳回「Set-Cookie」標頭，但不會使用路徑屬性，因為瀏覽器預設會使用要求網址的目錄做為 Cookie 路徑 (與路徑相關的 Cookie 範圍)。因此，除非有意這麼做，否則建議您不要在重新導向路徑中加入「/」。

4. 副車無法擷取 jwksUri。

   在某些情況下，側邊車限制可能會導致擷取 jwksUri 失敗。如果命名空間未使用萬用字元 (例如 ./* 或 istio-system/*) 表示，這項操作將無法執行。您必須在出口側邊車中手動新增這些命名空間。

常見問題

1. 如何升級啟用使用者驗證功能的 Cloud Service Mesh？

   請按照 Cloud Service Mesh 升級程序操作，並在指令列中將 --custom_overlay user-auth-overlay.yaml 新增至 asmcli install，藉此指定覆蓋檔案。

2. 我們應該為 authservice 佈建多少資源？每秒可處理多少個要求？

   根據預設，authservice 會以 2.0 vCPU 和 256 Mi 記憶體的配置運作。在這種設定下，authservice 每秒可處理 500 個要求。如要處理大量要求，您應配置更多 CPU，這大致與要求處理容量成正比。您也可以設定多個 authservice 備用資源，以提升水平可擴充性。