使用 Envoy 和負載平衡 API (舊版) 設定服務安全性

按照本指南中的操作說明，使用負載平衡 API，為透過 Cloud Service Mesh 和 Envoy Proxy 部署的服務設定驗證和授權。如果您使用服務路徑 API，請參閱「使用 Envoy 設定服務安全性」。

如需完整資訊，請參閱「使用 Load Balancing API 的 Cloud Service Mesh 服務安全性」。

注意： 本指南僅支援使用 API 的 Cloud Service Mesh，不支援 Istio API。 Google Cloud 詳情請參閱「Cloud Service Mesh 總覽」一文。

本文適用於使用負載平衡 API 的設定。這是舊版文件。

需求條件

使用 Envoy 設定 Cloud Service Mesh 的服務安全防護前，請確認設定符合下列必要條件：

• 使用 Envoy 1.20.0 以上版本，即可使用 xDS v3 API。

• 您可以滿足部署 Cloud Service Mesh 的所有需求。如要進一步瞭解這些需求，請參閱「準備使用 Envoy 設定 Cloud Service Mesh」。

• 您具備足夠的權限，可以建立或更新 Cloud Service Mesh 和Google Cloud 服務網格資源，以使用服務安全功能，詳情請參閱「準備透過 Envoy 設定 Cloud Service Mesh」。

準備設定

以下各節說明設定 Cloud Service Mesh 安全性服務前，您需要完成的工作。這些工作包括：

• 更新 Google Cloud CLI
• 設定變數
• 啟用 Cloud Service Mesh 與憑證授權單位服務搭配運作所需的 API

更新 gcloud 指令列工具

如要更新 Google Cloud CLI，請在本機電腦上執行下列指令：

gcloud components update

設定變數

請設定下列變數，以便在逐步完成本文範例時，複製及貼上具有一致值的程式碼。請使用下列值。

• PROJECT_ID：請將此處替換為專案 ID。
• CLUSTER_NAME：將叢集名稱替換為您要使用的名稱，例如 secure-td-cluster。
• ZONE：取代叢集所在的區域。
• GKE_CLUSTER_URL：替代 https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME
• WORKLOAD_POOL：替代 PROJECT_ID.svc.id.goog
• K8S_NAMESPACE：替代 default。
• DEMO_CLIENT_KSA：取代用戶端 Kubernetes 服務帳戶的名稱。
• DEMO_SERVER_KSA：取代伺服器 Kubernetes 服務帳戶的名稱。

• PROJNUM：將專案編號替換成您的專案編號，您可以從 Google Cloud 控制台或使用下列指令判斷：

  gcloud projects describe PROJECT_ID --format="value(projectNumber)"
  

• SA_GKE：替代 [e-mail]

• CLUSTER_VERSION：替換為最新版本。詳情請參閱搶鮮版版本資訊。 最低版本需求為 1.21.4-gke.1801。這是本範例中使用的 GKE 叢集版本。

請在此處設定值：

# Substitute your project ID
PROJECT_ID=PROJECT_ID

# GKE cluster name and zone for this example.
CLUSTER_NAME=CLUSTER_NAME
ZONE=ZONE

# GKE cluster URL derived from the above
GKE_CLUSTER_URL="https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME"

# Workload pool to be used with the GKE cluster
WORKLOAD_POOL="PROJECT_ID.svc.id.goog"

# Kubernetes namespace to run client and server demo.
K8S_NAMESPACE=K8S_NAMESPACE
DEMO_CLIENT_KSA=DEMO_CLIENT_KSA
DEMO_SERVER_KSA=DEMO_SERVER_KSA

# Compute other values
# Project number for your project
PROJNUM=PROJNUM

CLUSTER_VERSION=CLUSTER_VERSION
SA_GKE=[e-mail]

啟用 API

使用 gcloud services enable 指令啟用所有 API，以便透過憑證授權單位服務設定 Cloud Service Mesh 安全性。

gcloud services enable \
   container.googleapis.com \
   cloudresourcemanager.googleapis.com \
   compute.googleapis.com \
   trafficdirector.googleapis.com \
   networkservices.googleapis.com \
   networksecurity.googleapis.com \
   privateca.googleapis.com \
   gkehub.googleapis.com

建立或更新 GKE 叢集

Cloud Service Mesh 服務安全防護取決於憑證授權單位服務與 GKE 的整合。除了設定需求條件外，GKE 叢集也必須符合下列條件：

• 使用最低叢集版本 1.21.4-gke.1801。如需後續版本的功能，可以透過快速發布管道取得該版本。
• GKE 叢集必須啟用並設定網格憑證，如「建立憑證授權單位來核發憑證」一文所述。

1. 建立使用 Workload Identity Federation for GKE 的新叢集。如要更新現有叢集，請跳至下一個步驟。您為 --tags 提供的值必須與使用 Cloud Load Balancing 元件設定 Cloud Service Mesh一節中，傳遞至 firewall-rules create 指令 --target-tags 標記的名稱相符。

   # Create a GKE cluster with GKE managed mesh certificates.
   gcloud container clusters create CLUSTER_NAME \
     --release-channel=rapid \
     --scopes=cloud-platform \
     --image-type=cos_containerd \
     --machine-type=e2-standard-2 \
     --zone=ZONE \
     --workload-pool=PROJECT_ID.svc.id.goog \
     --enable-mesh-certificates \
     --cluster-version=CLUSTER_VERSION \
     --enable-ip-alias \
     --tags=allow-health-checks \
     --workload-metadata=GKE_METADATA
   

   叢集建立作業可能需要幾分鐘才能完成。

2. 如果您使用現有叢集，請開啟 GKE 適用的工作負載身分聯盟和 GKE 網格憑證。確認叢集是使用 --enable-ip-alias 旗標建立，這個旗標無法與 update 指令搭配使用。

   gcloud container clusters update CLUSTER_NAME \
     --enable-mesh-certificates
   

3. 執行下列指令，將新叢集切換為 kubectl 指令的預設叢集：

   gcloud container clusters get-credentials CLUSTER_NAME \
     --zone ZONE
   

在多叢集環境中部署

如果您是在多叢集環境中部署，請按照本節所述的一般程序操作。這些操作說明假設用戶端 Pod 在一個叢集中執行，伺服器 Pod 則在另一個叢集中執行。

1. 按照上一節的指示建立或更新叢集。

2. 使用下列指令擷取每個叢集的 Pod IP 位址範圍：

   gcloud compute firewall-rules list \
     --filter="name~gke-{CLUSTER_NAME}-[0-9a-z]*-all" \
     --format="value(sourceRanges)"
   

   舉例來說，如果叢集名稱為 cluster-a 和 cluster-b，指令會傳回下列結果：

   cluster-a, pod CIDR: 10.4.0.0/14, node network tag: gke-cluster-a-9cd18751-node
   cluster-b, pod CIDR: 10.8.0.0/14, node network tag: gke-cluster-b-acd14479-node
   

3. 建立虛擬私有雲防火牆規則，允許叢集彼此通訊。舉例來說，下列指令會建立防火牆規則，允許 cluster-a Pod IP 位址與 cluster-b 節點通訊：

   gcloud compute firewall-rules create per-cluster-a-pods \
     --allow="tcp,udp,icmp,esp,ah,sctp" \
     --target-tags="gke-cluster-b-acd14479-node"
   

   下列指令會建立防火牆規則，允許 cluster-b Pod IP 位址與 cluster-a 節點通訊：

   gcloud compute firewall-rules create per-cluster-b-pods \
     --allow="tcp,udp,icmp,esp,ah,sctp" \
     --target-tags="gke-cluster-a-9cd18751-node"
   

向機群註冊叢集

在「建立 GKE 叢集」中建立或更新叢集後，請將該叢集註冊至機群。註冊叢集後，您就能更輕鬆地跨多個專案設定叢集。

請注意，每個步驟最多可能需要十分鐘才能完成。

1. 將叢集註冊至機群：

   gcloud container fleet memberships register CLUSTER_NAME \
     --gke-cluster=ZONE/CLUSTER_NAME \
     --enable-workload-identity --install-connect-agent \
     --manifest-output-file=MANIFEST-FILE_NAME
   

   請依下列方式替換變數：

   • CLUSTER_NAME：叢集名稱。
   • ZONE：叢集所在的區域。
   • MANIFEST-FILE_NAME：這些指令產生註冊資訊清單的路徑。

   註冊程序完成後，您會看到類似以下的訊息：

   Finished registering the cluster CLUSTER_NAME with the fleet.

2. 將產生的資訊清單檔案套用至叢集：

   kubectl apply -f MANIFEST-FILE_NAME
   

   申請程序成功後，您會看到類似以下的訊息：

   namespace/gke-connect created
   serviceaccount/connect-agent-sa created
   podsecuritypolicy.policy/gkeconnect-psp created
   role.rbac.authorization.k8s.io/gkeconnect-psp:role created
   rolebinding.rbac.authorization.k8s.io/gkeconnect-psp:rolebinding created
   role.rbac.authorization.k8s.io/agent-updater created
   rolebinding.rbac.authorization.k8s.io/agent-updater created
   role.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created
   clusterrole.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created
   clusterrolebinding.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created
   clusterrolebinding.rbac.authorization.k8s.io/gke-connect-feature-authorizer-20210416-01-00 created
   rolebinding.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created
   role.rbac.authorization.k8s.io/gke-connect-namespace-getter created
   rolebinding.rbac.authorization.k8s.io/gke-connect-namespace-getter created
   secret/http-proxy created
   deployment.apps/gke-connect-agent-20210416-01-00 created
   service/gke-connect-monitoring created
   secret/creds-gcp create
   

3. 從叢集取得成員資格資源：

   kubectl get memberships membership -o yaml
   

   輸出內容應包含車隊指派的 Workload Identity Pool，其中 PROJECT_ID 是您的專案 ID：

   workload_identity_pool: PROJECT_ID.svc.id.goog
   

   這表示叢集已成功註冊。

建立憑證授權單位來核發憑證

如要將憑證核發給 Pod，請建立 CA 服務集區和下列憑證授權單位 (CA)：

• 根 CA。這是所有核發網格憑證的信任根。如有現有的根層級 CA，可直接使用。在 enterprise 層級中建立根 CA，這個層級適用於長期、低用量的憑證核發作業。
• 從屬 CA。這個 CA 會核發工作負載憑證。在叢集部署的區域中建立從屬 CA。在 devops 層級中建立從屬 CA，這適用於短期大量核發憑證。

建立從屬 CA 是選用步驟，但我們強烈建議您建立從屬 CA，而非使用根 CA 核發 GKE Mesh 憑證。如果您決定使用根 CA 核發網格憑證，請確保預設的以設定為準的核發模式仍可使用。

下層 CA 可以與叢集位於不同區域，但強烈建議您在與叢集相同的區域中建立下層 CA，以提升效能。不過，您可以在不同區域建立根 CA 和從屬 CA，不會影響效能或可用性。

CA 服務支援下列區域：

地區名稱	地區說明
asia-east1	台灣
asia-east2	香港
asia-northeast1	東京
asia-northeast2	大阪
asia-northeast3	首爾
asia-south1	孟買
asia-south2	德里
asia-southeast1	新加坡
asia-southeast2	雅加達
australia-southeast1	雪梨
australia-southeast2	墨爾本
europe-central2	華沙
europe-north1	芬蘭
europe-southwest1	馬德里
europe-west1	比利時
europe-west2	倫敦
europe-west3	法蘭克福
europe-west4	荷蘭
europe-west6	蘇黎世
europe-west8	米蘭
europe-west9	巴黎
europe-west10	柏林
europe-west12	杜林
me-central1	杜哈
me-central2	達曼
me-west1	特拉維夫市
northamerica-northeast1	蒙特婁
northamerica-northeast2	多倫多
southamerica-east1	聖保羅
southamerica-west1	聖地亞哥
us-central1	愛荷華州
us-east1	南卡羅來納州
us-east4	北維吉尼亞州
us-east5	哥倫布
us-south1	達拉斯
us-west1	奧勒岡州
us-west2	洛杉磯
us-west3	鹽湖城
us-west4	拉斯維加斯

您也可以執行下列指令，查看支援的地點清單：

gcloud privateca locations list

1. 將 IAM roles/privateca.caManager 授予建立 CA 集區和 CA 的個人。請注意，MEMBER 的正確格式為 user:[e-mail]。如果該使用者是目前的使用者，您可以使用 $(gcloud auth list --filter=status:ACTIVE --format="value(account)") 殼層指令取得目前的使用者 ID。

   gcloud projects add-iam-policy-binding PROJECT_ID \
     --member=MEMBER \
     --role=roles/privateca.caManager
   

2. 將 CA 服務的 role/privateca.admin 角色授予需要修改 IAM 政策的個人，其中 MEMBER 是需要這項存取權的個人，具體來說，就是執行下列步驟以授予 privateca.auditor 和 privateca.certificateManager 角色的任何個人：

   gcloud projects add-iam-policy-binding PROJECT_ID \
     --member=MEMBER \
     --role=roles/privateca.admin
   

3. 建立根 CA 服務集區。

   gcloud privateca pools create ROOT_CA_POOL_NAME \
     --location ROOT_CA_POOL_LOCATION \
     --tier enterprise
   

4. 建立根 CA。

   gcloud privateca roots create ROOT_CA_NAME --pool ROOT_CA_POOL_NAME \
     --subject "CN=ROOT_CA_NAME, O=ROOT_CA_ORGANIZATION" \
     --key-algorithm="ec-p256-sha256" \
     --max-chain-length=1 \
     --location ROOT_CA_POOL_LOCATION
   

   在本示範設定中，請為變數使用下列值：

   • ROOT_CA_POOL_NAME=td_sec_pool
   • ROOT_CA_NAME=pkcs2-ca
   • ROOT_CA_POOL_LOCATION=us-east1
   • ROOT_CA_ORGANIZATION="TestCorpLLC"

5. 建立從屬集區和從屬 CA。確認系統仍允許預設的以設定為準的核發模式。

   gcloud privateca pools create SUBORDINATE_CA_POOL_NAME \
     --location SUBORDINATE_CA_POOL_LOCATION \
     --tier devops
   

   gcloud privateca subordinates create SUBORDINATE_CA_NAME \
     --pool SUBORDINATE_CA_POOL_NAME \
     --location SUBORDINATE_CA_POOL_LOCATION \
     --issuer-pool ROOT_CA_POOL_NAME \
     --issuer-location ROOT_CA_POOL_LOCATION \
     --subject "CN=SUBORDINATE_CA_NAME, O=SUBORDINATE_CA_ORGANIZATION" \
     --key-algorithm "ec-p256-sha256" \
     --use-preset-profile subordinate_mtls_pathlen_0
   

   在本示範設定中，請為變數使用下列值：

   • SUBORDINATE_CA_POOL_NAME="td-ca-pool"
   • SUBORDINATE_CA_POOL_LOCATION=us-east1
   • SUBORDINATE_CA_NAME="td-ca"
   • SUBORDINATE_CA_ORGANIZATION="TestCorpLLC"
   • ROOT_CA_POOL_NAME=td_sec_pool
   • ROOT_CA_POOL_LOCATION=us-east1

6. 授予根 CA 集區的 IAM privateca.auditor 角色，允許 GKE 服務帳戶存取：

   gcloud privateca pools add-iam-policy-binding ROOT_CA_POOL_NAME \
    --location ROOT_CA_POOL_LOCATION \
    --role roles/privateca.auditor \
    --member="serviceAccount:[e-mail]"
   

7. 授予從屬 CA 集區的 IAM privateca.certificateManager 角色，允許 GKE 服務帳戶存取：

   gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_NAME \
     --location SUBORDINATE_CA_POOL_LOCATION \
     --role roles/privateca.certificateManager \
     --member="serviceAccount:[e-mail]"
   

8. 儲存下列 WorkloadCertificateConfig YAML 設定，告知叢集如何核發網格憑證：

   apiVersion: security.cloud.google.com/v1
   kind: WorkloadCertificateConfig
   metadata:
     name: default
   spec:
     # Required. The CA service that issues your certificates.
     certificateAuthorityConfig:
       certificateAuthorityServiceConfig:
         endpointURI: ISSUING_CA_POOL_URI
   
     # Required. The key algorithm to use. Choice of RSA or ECDSA.
     #
     # To maximize compatibility with various TLS stacks, your workloads
     # should use keys of the same family as your root and subordinate CAs.
     #
     # To use RSA, specify configuration such as:
     #   keyAlgorithm:
     #     rsa:
     #       modulusSize: 4096
     #
     # Currently, the only supported ECDSA curves are "P256" and "P384", and the only
     # supported RSA modulus sizes are 2048, 3072 and 4096.
     keyAlgorithm:
       rsa:
         modulusSize: 4096
   
     # Optional. Validity duration of issued certificates, in seconds.
     #
     # Defaults to 86400 (1 day) if not specified.
     validityDurationSeconds: 86400
   
     # Optional. Try to start rotating the certificate once this
     # percentage of validityDurationSeconds is remaining.
     #
     # Defaults to 50 if not specified.
     rotationWindowPercentage: 50
   
   

   更改下列內容：

   • 叢集執行的專案 ID：

     PROJECT_ID

   • 核發網格憑證的 CA 的完整 URI (ISSUING_CA_POOL_URI)。這可以是從屬 CA (建議) 或根 CA。格式如下：

     //privateca.googleapis.com/projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_LOCATION/caPools/SUBORDINATE_CA_POOL_NAME

9. 儲存下列 TrustConfig YAML 設定，告知叢集如何信任核發的憑證：

   apiVersion: security.cloud.google.com/v1
   kind: TrustConfig
   metadata:
     name: default
   spec:
     # You must include a trustStores entry for the trust domain that
     # your cluster is enrolled in.
     trustStores:
     - trustDomain: PROJECT_ID.svc.id.goog
       # Trust identities in this trustDomain if they appear in a certificate
       # that chains up to this root CA.
       trustAnchors:
       - certificateAuthorityServiceURI: ROOT_CA_POOL_URI
   

   更改下列內容：

   • 叢集執行的專案 ID：

     PROJECT_ID

   • 根 CA 集區的完整 URI (ROOT_CA_POOL_URI)。 格式如下：

     //privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME

10. 將設定套用至叢集：

    kubectl apply -f WorkloadCertificateConfig.yaml
    kubectl apply -f TrustConfig.yaml
    

設定身分與存取權管理

如要建立設定所需的資源，您必須具備 compute.NetworkAdmin 角色。這個角色具備所有必要權限，可建立、更新、刪除、列出及使用 (也就是在其他資源中參照) 必要資源。如果您是專案的擁有者兼編輯者，系統會自動指派這個角色。

請注意，在後端服務中參照這些資源，並以 HTTPS Proxy 資源為目標時，系統不會強制執行 networksecurity.googleapis.com.clientTlsPolicies.use 和 networksecurity.googleapis.com.serverTlsPolicies.use。

如果日後強制執行這些權限，且您使用 compute.NetworkAdmin 角色，則在強制執行這項檢查時，您不會發現任何問題。

如果您使用自訂角色，且日後強制執行這項檢查，請務必加入相應的 .use 權限。否則，您可能會發現自訂角色沒有必要的權限，無法分別從後端服務或目標 HTTPS Proxy 參照 clientTlsPolicy 或 serverTlsPolicy。

按照下列操作說明，讓預設服務帳戶存取 Cloud Service Mesh Security API，並建立 Kubernetes 服務帳戶。

1. 設定 IAM，允許預設服務帳戶存取 Cloud Service Mesh 安全性 API。

   GSA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \
      --filter='displayName:Compute Engine default service account')
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
     --member serviceAccount:${GSA_EMAIL} \
     --role roles/trafficdirector.client
   

2. 設定 Kubernetes 服務帳戶。下列各節中的用戶端和伺服器部署作業，會使用 Kubernetes 伺服器和用戶端服務帳戶的 Kname。

   kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_SERVER_KSA
   kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_CLIENT_KSA
   

3. 在 Kubernetes 服務帳戶與預設 Compute Engine 服務帳戶之間建立 IAM 政策繫結，允許 Kubernetes 服務帳戶模擬預設 Compute Engine 服務帳戶。這個繫結可讓 Kubernetes 服務帳戶做為預設的 Compute Engine 服務帳戶。

   gcloud iam service-accounts add-iam-policy-binding  \
     --role roles/iam.workloadIdentityUser \
     --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/DEMO_SERVER_KSA]" ${GSA_EMAIL}
   
   gcloud iam service-accounts add-iam-policy-binding  \
     --role roles/iam.workloadIdentityUser  \
     --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/DEMO_CLIENT_KSA]" ${GSA_EMAIL}
   

4. 為 Kubernetes 服務帳戶加上註解，將其與預設的 Compute Engine 服務帳戶建立關聯。

   kubectl annotate --namespace K8S_NAMESPACE \
     serviceaccount DEMO_SERVER_KSA \
     iam.gke.io/gcp-service-account=${GSA_EMAIL}
   
   kubectl annotate --namespace K8S_NAMESPACE \
     serviceaccount DEMO_CLIENT_KSA \
     iam.gke.io/gcp-service-account=${GSA_EMAIL}
   

設定 Cloud Service Mesh

請按照下列操作說明安裝 Sidecar 注入器、設定測試服務，以及完成其他部署工作。

在叢集中安裝 Envoy 補充注入器

請按照「Cloud Service Mesh setup for GKE Pods with automatic Envoy injection」一文中的指示，在叢集中部署及啟用 Envoy Sidecar 插入功能：

• 安裝 Envoy 補充注入器
• 啟用補充植入功能

請務必先完成兩組操作說明，再設定測試服務。

設定測試服務

安裝 Envoy Sidecar 注入器後，請按照下列操作說明為部署作業設定測試服務。

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/service_sample.yaml | sed -e s/DEMO_SERVER_KSA_PLACEHOLDER/DEMO_SERVER_KSA/g > service_sample.yaml

kubectl apply -f service_sample.yaml

檔案 service_sample.yaml 包含示範伺服器應用程式的 podspec。部分註解專用於 Cloud Service Mesh 安全性。

Cloud Service Mesh 代理程式中繼資料

podspec 會指定 proxyMetadata 註解：

spec:
...
      annotations:
        cloud.google.com/proxyMetadata: '{"app": "payments"}'
...

Pod 初始化時，Sidecar 代理程式會擷取這項註解，並傳輸至 Cloud Service Mesh。Cloud Service Mesh 隨後會使用這項資訊傳回經過篩選的設定：

• 本指南稍後會說明端點政策指定端點比對器。
• 端點比對器會指定只有顯示名稱為 app 且值為 payments 的標籤的用戶端，才會收到經過篩選的設定。

使用由 CA 服務簽署的網格憑證和金鑰

podspec 會指定 enableManagedCerts 註解：

spec:
...
      annotations:
        ...
        cloud.google.com/enableManagedCerts: "true"
...

Pod 初始化時，CA 服務簽署的憑證和金鑰會自動掛接至本機 Sidecar Proxy 檔案系統。

設定內送流量攔截通訊埠

podspec 會指定 includeInboundPorts 註解：

spec:
...
      annotations:
        ...
        cloud.google.com/includeInboundPorts: "8000"
...

這是伺服器應用程式監聽連線的通訊埠。Pod 初始化時，Sidecar Proxy 會擷取這項註解，並傳輸至 Cloud Service Mesh。Cloud Service Mesh 隨後會使用這項資訊傳回經過篩選的設定，攔截傳入這個連接埠的所有流量，並套用安全性政策。

健康狀態檢查通訊埠不得與應用程式通訊埠相同。否則，連入健康狀態檢查通訊埠的連線會套用相同的安全性政策，可能導致連線遭拒，伺服器因此遭到錯誤標示為健康狀態不良。

設定 NEG 適用的 GKE 服務

GKE 服務必須透過網路端點群組 (NEG) 公開，才能將其設定為 Cloud Service Mesh 後端服務的後端。本設定指南提供的 service_sample.yaml 套件會在下列註解中使用 NEG 名稱 service-test-neg：

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

您不需要變更 service_sample.yaml 檔案。

儲存 NEG 名稱

在 NEG_NAME 變數中儲存 NEG 名稱：

NEG_NAME="service-test-neg"

將用戶端應用程式部署至 GKE

執行下列指令，啟動含有 Envoy Proxy 的示範用戶端 (以 Sidecar 形式)，您需要這個用戶端來展示安全性功能。

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/client_sample.yaml | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > client_sample.yaml

kubectl apply -f client_sample.yaml

用戶端 podspec 只包含 enableManagedCerts 註解。您必須這麼做，才能掛接 GKE 管理的網格憑證和金鑰所需的磁碟區，這些憑證和金鑰是由 CA 服務執行個體簽署。

設定 Cloud Service Mesh 資源 Google Cloud

按照「設定採用 Cloud Load Balancing 元件的 Cloud Service Mesh」一文中的步驟操作。請務必確認範例用戶端的流量會轉送至範例服務。

Cloud Service Mesh 設定完成，您現在可以設定驗證和授權政策。

設定服務對服務安全機制

請按照下列各節的操作說明，設定服務對服務安全機制。

在網格中啟用 mTLS

如要在網格中設定 mTLS，您必須確保後端服務的外寄流量安全，以及端點的內送流量安全。

政策相關資訊格式

請注意，提及伺服器 TLS、用戶端 TLS 和授權政策時，必須採用下列格式：

projects/PROJECT_ID/locations/global/[serverTlsPolicies|clientTlsPolicies|authorizationPolicies]/[server-tls-policy|client-mtls-policy|authz-policy]

例如：

projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy

projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy

projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy

保護傳送至後端服務的傳出流量

如要保護外送流量，請先建立用戶端 TLS 政策，並執行下列操作：

• 使用 google_cloud_private_spiffe 做為 clientCertificate 的外掛程式，可讓 Envoy 程式使用 GKE 管理的網格憑證做為用戶端身分。
• 使用 google_cloud_private_spiffe 做為 serverValidationCa 的外掛程式，程式會指示 Envoy 使用 GKE 管理的網格憑證進行伺服器驗證。

接著，將用戶端 TLS 政策附加至後端服務。這會執行以下操作：

• 將用戶端 TLS 政策中的驗證政策套用至後端服務端點的出站連線。
• 主體別名 (SAN) 會指示用戶端判斷所連線伺服器的確切身分。

1. 在檔案中建立用戶端 TLS 政策 client-mtls-policy.yaml：

   name: "client-mtls-policy"
   clientCertificate:
     certificateProviderInstance:
       pluginInstance: google_cloud_private_spiffe
   serverValidationCa:
   - certificateProviderInstance:
       pluginInstance: google_cloud_private_spiffe
   

2. 匯入用戶端 TLS 政策：

   gcloud network-security client-tls-policies import client-mtls-policy \
       --source=client-mtls-policy.yaml --location=global
   

3. 將用戶端 TLS 政策附加至後端服務。這會對從用戶端到這個後端服務的所有連出要求，強制執行 mTLS 驗證。

   gcloud compute backend-services export td-gke-service \
       --global --destination=demo-backend-service.yaml
   

   在 demo-backend-service.yaml 中附加下列程式碼：

   securitySettings:
     clientTlsPolicy: projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy
     subjectAltNames:
       - "spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA"
   

4. 匯入值：

   gcloud compute backend-services import td-gke-service \
       --global --source=demo-backend-service.yaml
   

5. (選用) 執行下列指令，檢查要求是否失敗。 這是預期會發生的錯誤，因為用戶端預期端點會提供憑證，但端點並未設定安全性政策。

   # Get the name of the Podrunning Busybox.
   BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')
   
   # Command to execute that tests connectivity to the service service-test.
   TEST_CMD="wget -q -O - service-test; echo"
   
   # Execute the test command on the pod.
   kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
   

   您會看到類似以下的輸出內容：

   wget: server returned error: HTTP/1.1 503 Service Unavailable
   

保護傳入端點的流量

如要保護傳入流量，請先建立伺服器 TLS 政策，執行下列操作：

• 使用 google_cloud_private_spiffe 做為 serverCertificate 的外掛程式，可讓 Envoy 程式使用 GKE 管理的網格憑證做為伺服器身分。
• 使用 google_cloud_private_spiffe 做為 clientValidationCa 的外掛程式，可讓 Envoy 程式使用 GKE 管理的網格憑證進行用戶端驗證。

1. 將伺服器 TLS 政策值儲存至名為 server-mtls-policy.yaml 的檔案。

   name: "server-mtls-policy"
   serverCertificate:
     certificateProviderInstance:
       pluginInstance: google_cloud_private_spiffe
   mtlsPolicy:
     clientValidationCa:
     - certificateProviderInstance:
         pluginInstance: google_cloud_private_spiffe
   

2. 建立伺服器 TLS 政策：

   gcloud network-security server-tls-policies import server-mtls-policy \
       --source=server-mtls-policy.yaml --location=global
   

3. 建立名為 ep_mtls.yaml 的檔案，其中包含端點比對器，並附加伺服器 TLS 政策。

   endpointMatcher:
     metadataLabelMatcher:
       metadataLabelMatchCriteria: MATCH_ALL
       metadataLabels:
       - labelName: app
         labelValue: payments
   name: "ep"
   serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy
   type: SIDECAR_PROXY
   

4. 匯入端點比對器。

   gcloud network-services endpoint-policies import ep \
       --source=ep_mtls.yaml --location=global
   

驗證設定

執行下列 curl 指令。如果要求順利完成，輸出內容會顯示 x-forwarded-client-cert。只有在連線為 mTLS 連線時，才會列印標頭。

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

您會看到類似以下的輸出內容：

GET /get HTTP/1.1
Host: service-test
content-length: 0
x-envoy-internal: true
accept: */*
x-forwarded-for: 10.48.0.6
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.35.0
x-forwarded-proto: http
x-request-id: redacted
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA

請注意，x-forwarded-client-cert 標頭是由伺服器端 Envoy 插入，其中包含伺服器本身的 ID 和來源用戶端的 ID。由於我們同時看到用戶端和伺服器身分，這就是 mTLS 連線的信號。

透過授權政策設定服務層級存取權

這些操作說明會建立授權政策，允許由主機名稱為 service-test、連接埠為 8000 且 HTTP 方法為 GET 的 DEMO_CLIENT_KSA 帳戶傳送要求。建立授權政策前，請先詳閱「使用授權限制存取權」一文中的注意事項。

1. 建立名為 authz-policy.yaml 的檔案，藉此建立授權政策。

   action: ALLOW
   name: authz-policy
   rules:
   - sources:
     - principals:
       - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
     destinations:
     - hosts:
       - service-test
       ports:
       - 8000
       methods:
       - GET
   

2. 匯入政策：

   gcloud network-security authorization-policies import authz-policy \
     --source=authz-policy.yaml \
     --location=global
   

3. 更新端點政策，方法是在 ep_mtls.yaml 檔案中附加下列內容，以參照新的授權政策：

   authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy
   

   端點政策現在會指定，對於 Envoy Sidecar Proxy 顯示 app:payments 標籤的 Pod，傳入要求必須強制執行 mTLS 和授權政策。

4. 匯入政策：

   gcloud network-services endpoint-policies import ep \
       --source=ep_mtls.yaml --location=global
   

驗證設定

執行下列指令來驗證設定。

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
# This is a valid request and will be allowed.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

預期的輸出內容如下：

GET /get HTTP/1.1
Host: service-test
content-length: 0
x-envoy-internal: true
accept: */*
x-forwarded-for: redacted
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.35.0
x-forwarded-proto: http
x-request-id: redacted
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA

執行下列指令，測試授權政策是否正確拒絕無效要求：

# Failure case
# Command to execute that tests connectivity to the service service-test.
# This is an invalid request and server will reject because the server
# authorization policy only allows GET requests.
TEST_CMD="wget -q -O - service-test --post-data='' ; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

預期的輸出內容如下：

<RBAC: access denied HTTP/1.1 403 Forbidden>

設定輸入閘道安全性

本節假設您已完成服務與服務之間的安全性一節，包括設定含有 Sidecar 自動注入器的 GKE 叢集、建立憑證授權單位，以及建立端點政策。

在本節中，您將部署 Envoy Proxy 做為 Ingress 閘道，終止 TLS 連線並授權叢集內部用戶端的要求。

在 Ingress 閘道終止 TLS (按一下即可放大)

如要設定 Ingress 閘道來終止 TLS，請執行下列操作：

1. 部署可透過叢集內部 IP 位址存取的 Kubernetes 服務。
   1. 部署作業包含獨立的 Envoy Proxy，該 Proxy 會以 Kubernetes 服務的形式公開，並連線至 Cloud Service Mesh。
2. 建立伺服器 TLS 政策，終止 TLS。
3. 建立授權政策，授權連入要求。

將 Ingress 閘道服務部署至 GKE

執行下列指令，在 GKE 上部署 Ingress 閘道服務：

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/gateway_sample_xdsv3.yaml | sed -e s/PROJECT_NUMBER_PLACEHOLDER/PROJNUM/g | sed -e s/NETWORK_PLACEHOLDER/default/g | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > gateway_sample.yaml

kubectl apply -f gateway_sample.yaml

檔案 gateway_sample.yaml 是輸入閘道的規格。以下各節說明規格新增的內容。

停用 Cloud Service Mesh 輔助資訊注入功能

gateway_sample.yaml 規格會將 Envoy Proxy 部署為唯一容器。在先前的步驟中，Envoy 已做為 Sidecar 插入應用程式容器。為避免多個 Envoy 處理要求，您可以使用下列陳述式，針對這個 Kubernetes 服務停用 Sidecar 插入作業：

sidecar.istio.io/inject: "false"

掛接正確的磁碟區

gateway_sample.yaml 規格會掛接磁碟區 gke-workload-certificates。 這個磁碟區也會用於 Sidecar 部署作業，但 Sidecar 注入器看到註解 cloud.google.com/enableManagedCerts: "true" 時，會自動新增這個磁碟區。gke-workload-certificates 磁碟區包含 GKE 管理的 SPIFFE 憑證和金鑰，這些憑證和金鑰是由您設定的 CA 服務執行個體簽署。

設定叢集的內部 IP 位址

使用 ClusterInternal 類型的服務設定 Ingress 閘道。這會為 mesh-gateway 建立可從內部解析的 DNS 主機名稱。當用戶端將要求傳送至 mesh-gateway:443 時，Kubernetes 會立即將要求轉送至輸入閘道 Envoy 部署作業的通訊埠 8080。

在 Ingress 閘道上啟用 TLS

請按照這些指示在輸入閘道上啟用 TLS。

1. 建立伺服器 TLS 政策資源來終止 TLS 連線，並使用名為 server-tls-policy.yaml 的檔案中的值：

   description: tls server policy
   name: server-tls-policy
   serverCertificate:
     certificateProviderInstance:
       pluginInstance: google_cloud_private_spiffe
   

2. 匯入伺服器 TLS 政策：

   gcloud network-security server-tls-policies import server-tls-policy \
       --source=server-tls-policy.yaml --location=global
   

3. 建立新的網址對應，將所有要求轉送至 td-gke-service 後端服務。Ingress 閘道會處理傳入的要求，並將其傳送至屬於 td-gke-service 後端服務的 Pod。

   gcloud compute url-maps create td-gke-ig-url-map \
      --default-service=td-gke-service
   

4. 在 td-gke-https-proxy.yaml 檔案中建立新的目標 HTTPS Proxy，並附加先前建立的網址對應和伺服器 TLS 政策。這會設定 Envoy Proxy 輸入閘道，終止傳入的 TLS 流量。

   kind: compute#targetHttpsProxy
   name: td-gke-https-proxy
   proxyBind: true
   urlMap: https://www.googleapis.com/compute/beta/projects/PROJECT_ID/global/urlMaps/td-gke-ig-url-map
   serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy
   

5. 匯入政策：

   gcloud compute target-https-proxies import td-gke-https-proxy \
      --global --source=td-gke-https-proxy.yaml
   

6. 建立新的轉送規則，並附加目標 HTTPS Proxy。這會設定 Envoy Proxy 監聽通訊埠 8080，並套用 td-gke-https-proxy 中定義的路由和安全性政策。

   gcloud compute forwarding-rules create td-gke-gateway-forwarding-rule --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED --address=0.0.0.0 \
     --target-https-proxy=td-gke-https-proxy --ports 8080 \
     --network default
   

7. 視需要更新後端的授權政策，在符合下列所有條件時允許要求：

   • DEMO_CLIENT_KSA 傳送的要求。(Ingress 閘道部署作業會使用 DEMO_CLIENT_KSA 服務帳戶)。
   • 主機為 mesh-gateway 或 service-test 的要求
   • 通訊埠：8000

   除非您已為後端設定授權政策，否則不需要執行這些指令。如果端點沒有授權政策，或授權政策中不含主機或來源主體相符項目，則系統會允許要求，不需執行這個步驟。將這些值新增至 authz-policy.yaml。

   action: ALLOW
   name: authz-policy
   rules:
   - sources:
     - principals:
       - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
     destinations:
     - hosts:
       - service-test
       - mesh-gateway
       ports:
       - 8000
       methods:
       - GET
   

8. 匯入政策：

   gcloud network-security authorization-policies import authz-policy \
     --source=authz-policy.yaml \
     --location=global
   

驗證 Ingress 閘道部署作業

您可以使用名為 debug 的新容器，將要求傳送至 Ingress 閘道，驗證部署作業。

在下列規格中，註解 "sidecar.istio.io/inject":"false" 可防止 Cloud Service Mesh Sidecar 注入器自動注入 Sidecar Proxy。沒有 Sidecar 可協助 debug 容器進行要求路徑設定。 容器必須連線至 Ingress 閘道才能進行路由。

規格包含 --no-check-certificate 標記，可忽略伺服器憑證驗證。debug 容器沒有憑證授權單位驗證憑證，因此無法驗證由 CA 服務簽署的憑證，而這些憑證會由 Ingress 閘道用於終止 TLS。

在實際工作環境中，建議您下載 CA 服務驗證憑證，並掛接或安裝在用戶端。安裝驗證憑證後，請移除 wget 指令的 --no-check-certificate 選項。

執行下列指令：

kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway; echo"

您會看到與以下類似的輸出內容：

GET / HTTP/1.1
Host: 10.68.7.132
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
x-envoy-expected-rq-timeout-ms: 15000
x-envoy-internal: true
x-request-id: 5ae429e7-0e18-4bd9-bb79-4e4149cf8fef
x-forwarded-for: 10.64.0.53
x-forwarded-proto: https
content-length: 0
user-agent: Wget

執行下列負面測試指令：

# Negative test
# Expect this to fail because gateway expects TLS.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - http://mesh-gateway:443/headers; echo"

畫面會顯示類似以下內容的輸出：

wget: error getting response: Connection reset by peer

執行下列負面測試指令：

# Negative test.
# AuthorizationPolicy applied on the endpoints expect a GET request. Otherwise
# the request is denied authorization.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway --post-data=''; echo"

畫面會顯示類似以下內容的輸出：

HTTP/1.1 403 Forbidden
wget: server returned error: HTTP/1.1 403 Forbidden

設定輸入閘道的授權政策

您在此設定的授權政策，可讓輸入閘道在符合下列所有條件時，允許要求進入網格：

• 主機：mesh-gateway
• 通訊埠：8080
• 路徑：*
• HTTP 方法 GET

1. 在 authz-gateway-policy.yaml 檔案中建立授權政策：

   action: ALLOW
   name: authz-gateway-policy
   rules:
   - destinations:
     - hosts:
       - mesh-gateway
       ports:
       - 8080
       methods:
       - GET
   

2. 匯入檔案中的值：

   gcloud network-security authorization-policies import authz-gateway-policy \
      --source=authz-gateway-policy.yaml  --location=global
   

3. 編輯 td-gke-https-proxy.yaml 檔案，並新增下列內容：

   authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-gateway-policy
   

4. 再次匯入 td-gke-https-proxy.yaml 檔案：

   gcloud compute target-https-proxies import td-gke-https-proxy \
      --global --source=td-gke-https-proxy.yaml
   

驗證部署作業

執行下列指令來驗證部署作業。

# On your localhost.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway; echo"

畫面會顯示類似以下內容的輸出：

GET / HTTP/1.1
Host: 35.196.50.2
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.72.0
x-forwarded-proto: https
content-length: 0
x-envoy-internal: true
x-request-id: 98bec135-6df8-4082-8edc-b2c23609295a
accept: */*
x-forwarded-for: 10.142.0.7

執行下列負面測試指令：

# Negative test. Expect failure because only POST method is allowed by \
# authz-gateway-policy
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway/ --post-data=''; echo"

畫面會顯示類似以下內容的輸出：

wget: server returned error: HTTP/1.1 403 Forbidden

刪除部署作業

您可以選擇執行這些指令，刪除使用本指南建立的部署項目。

如要刪除叢集，請執行下列指令：

gcloud container clusters delete CLUSTER_NAME --zone ZONE --quiet

如要刪除您建立的資源，請執行下列指令：

gcloud compute forwarding-rules delete td-gke-forwarding-rule --global --quiet
gcloud compute forwarding-rules delete td-gke-gateway-forwarding-rule --global \
    --quiet
gcloud compute target-http-proxies delete td-gke-proxy  --quiet
gcloud compute target-https-proxies delete td-gke-https-proxy  --quiet
gcloud compute url-maps delete td-gke-url-map  --quiet
gcloud compute url-maps delete td-gke-ig-url-map  --quiet
gcloud compute backend-services delete td-gke-service --global --quiet
cloud compute network-endpoint-groups delete service-test-neg --zone ZONE --quiet
gcloud compute firewall-rules delete fw-allow-health-checks --quiet
gcloud compute health-checks delete td-gke-health-check --quiet
gcloud network-services endpoint-policies delete ep \
    --location=global --quiet
gcloud network-security authorization-policies delete authz-gateway-policy \
   --location=global --quiet
gcloud network-security authorization-policies delete authz-policy \
    --location=global --quiet
gcloud network-security client-tls-policies delete client-mtls-policy \
    --location=global --quiet
gcloud network-security server-tls-policies delete server-tls-policy \
    --location=global --quiet
gcloud network-security server-tls-policies delete server-mtls-policy \
    --location=global --quiet

限制

只有 GKE 支援 Cloud Service Mesh 服務安全。您無法使用 Compute Engine 部署服務安全性。

疑難排解

本節提供相關資訊，說明如何修正設定安全服務時遇到的問題。

連線失敗

如果連線失敗並顯示 upstream connect 錯誤或 disconnect/reset before headers 錯誤，請檢查 Envoy 記錄檔，您可能會看到下列其中一則記錄訊息：

gRPC config stream closed: 5, Requested entity was not found

gRPC config stream closed: 2, no credential token is found

如果在 Envoy 記錄中看到這些錯誤，可能是服務帳戶權杖的掛接方式有誤，或是使用不同的 audience，或兩者皆是。

詳情請參閱Envoy 記錄檔中的錯誤訊息表示設定有問題。

未建立 Pod

如要排解這個問題，請參閱「排解 GKE Pod 的自動部署問題」。

Envoy 未通過 Cloud Service Mesh 驗證

Envoy (envoy-proxy) 連線至 Cloud Service Mesh 以擷取 xDS 設定時，會使用 GKE 適用的工作負載身分聯盟和 Compute Engine VM 預設服務帳戶 (除非已變更啟動程序)。如果驗證失敗，Envoy 就不會進入就緒狀態。

無法使用 --workload-identity-certificate-authority flag 建立叢集

如果看到這則錯誤訊息，請確認您使用的是最新版 Google Cloud CLI：

gcloud components update

Pod 仍處於待處理狀態

如果在設定過程中，Pod 仍處於待處理狀態，請在部署規格中增加 Pod 的 CPU 和記憶體資源。

無法使用 --enable-mesh-certificates 標記建立叢集

確認您使用的是最新版 gcloud CLI：

gcloud components update

請注意，--enable-mesh-certificates 標記僅適用於 gcloud beta。

Pod 無法啟動

如果憑證佈建失敗，使用 GKE Mesh 憑證的 Pod 可能無法啟動。可能發生這種情況的情境如下：

• WorkloadCertificateConfig 或 TrustConfig 設定有誤或缺少。
• CSR 未獲核准。

您可以檢查 Pod 事件，確認憑證佈建是否失敗。

1. 檢查 Pod 的狀態：

   kubectl get pod -n POD_NAMESPACE POD_NAME
   

   更改下列內容：

   • POD_NAMESPACE：Pod 的命名空間。
   • POD_NAME：Pod 的名稱。

2. 查看 Pod 的近期事件：

   kubectl describe pod -n POD_NAMESPACE POD_NAME
   

3. 如果憑證佈建失敗，您會看到含有 Type=Warning、Reason=FailedMount、From=kubelet 和 Message 欄位的事件，且 Message 欄位開頭為 MountVolume.SetUp failed for volume "gke-workload-certificates"。Message 欄位包含疑難排解資訊。

   Events:
     Type     Reason       Age                From       Message
     ----     ------       ----               ----       -------
     Warning  FailedMount  13s (x7 over 46s)  kubelet    MountVolume.SetUp failed for volume "gke-workload-certificates" : rpc error: code = Internal desc = unable to mount volume: store.CreateVolume, err: unable to create volume "csi-4d540ed59ef937fbb41a9bf5380a5a534edb3eedf037fe64be36bab0abf45c9c": caPEM is nil (check active WorkloadCertificateConfig)
   

4. 如果 Pod 無法啟動的原因是物件設定有誤或 CSR 遭拒，請參閱下列疑難排解步驟。

WorkloadCertificateConfig 或 TrustConfig 設定有誤

請確認您已正確建立 WorkloadCertificateConfig 和 TrustConfig 物件。您可以使用 kubectl 診斷這兩個物件的設定錯誤。

1. 擷取目前狀態。

   針對 WorkloadCertificateConfig：

   kubectl get WorkloadCertificateConfig default -o yaml
   

   針對 TrustConfig：

   kubectl get TrustConfig default -o yaml
   

2. 檢查狀態輸出內容。有效物件的條件會包含 type: Ready 和 status: "True"。

   status:
     conditions:
     - lastTransitionTime: "2021-03-04T22:24:11Z"
       message: WorkloadCertificateConfig is ready
       observedGeneration: 1
       reason: ConfigReady
       status: "True"
       type: Ready
   

   如果是無效物件，則會改為顯示 status: "False"。reason和message欄位包含其他疑難排解詳細資料。

CSR 未獲核准

如果 CSR 核准程序發生錯誤，您可以查看 CSR 的 type: Approved 和 type: Issued 條件，瞭解錯誤詳細資料。

1. 使用 kubectl 列出相關 CSR：

   kubectl get csr \
     --field-selector='spec.signerName=spiffe.gke.io/spiffe-leaf-signer'
   

2. 選擇 Approved 且不是 Issued 的 CSR，或選擇不是 Approved 的 CSR。

3. 使用 kubectl 取得所選 CSR 的詳細資料：

   kubectl get csr CSR_NAME -o yaml
   

   將 CSR_NAME 替換為您選擇的 CSR 名稱。

有效的 CSR 具有 type: Approved 和 status: "True" 的條件，以及 status.certificate 欄位中的有效憑證：

status:
  certificate: <base64-encoded data>
  conditions:
  - lastTransitionTime: "2021-03-04T21:58:46Z"
    lastUpdateTime: "2021-03-04T21:58:46Z"
    message: Approved CSR because it is a valid SPIFFE SVID for the correct identity.
    reason: AutoApproved
    status: "True"
    type: Approved

無效 CSR 的疑難排解資訊會顯示在 message 和 reason 欄位中。

應用程式無法使用核發的 mTLS 憑證

1. 確認憑證未過期：

   cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
   

2. 確認應用程式支援您使用的金鑰類型。

   cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3
   

3. 確認核發 CA 使用的金鑰系列與憑證金鑰相同。

   1. 取得 CA 服務 (預覽版) 執行個體的狀態：

      gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
        --location ISSUING_CA_LOCATION
      

      更改下列內容：

      • ISSUING_CA_TYPE：核發 CA 類型，必須是 subordinates 或 roots。
      • ISSUING_CA_NAME：核發 CA 的名稱。
      • ISSUING_CA_LOCATION：核發 CA 的區域。

   2. 檢查輸出內容中的 keySpec.algorithm 是否與您在 WorkloadCertificateConfig YAML 資訊清單中定義的金鑰演算法相同。輸出如下所示：

      config:
        ...
        subjectConfig:
          commonName: td-sub-ca
          subject:
            organization: TestOrgLLC
          subjectAltName: {}
      createTime: '2021-05-04T05:37:58.329293525Z'
      issuingOptions:
        includeCaCertUrl: true
      keySpec:
        algorithm: RSA_PKCS1_2048_SHA256
       ...
      

認證遭拒

1. 確認對等應用程式使用相同的信任套件來驗證憑證。

2. 確認憑證未過期：

   cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
   

3. 如果未使用 gRPC Go 憑證重新載入 API，請確認用戶端程式碼會定期從檔案系統重新整理憑證。

4. 確認工作負載與 CA 位於相同的信任網域。GKE 網格憑證支援單一信任網域中的工作負載通訊。