本文概述如何使用受管理的工作負載身分,在應用程式負載平衡器與後端之間建立雙向 TLS (mTLS)。代管 Workload Identity 會自動佈建及管理憑證授權單位服務的 X.509 憑證。
您也可以在不使用受管理工作負載身分的情況下,達成後端 mTLS。如要進一步瞭解不使用代管 Workload Identity 的後端 mTLS,請參閱「後端驗證的 TLS 和後端 mTLS 總覽」。
本文內容是以下列文件介紹的概念為基礎:
負載平衡器的代管型 Workload Identity 簡介
如果沒有受管理的工作負載身分識別,設定後端 mTLS 時,需要設定多個資源。將受管理的身分指派給負載平衡器的後端服務時,受管理的工作負載身分會自動建立 mTLS 所需的資源,例如用戶端憑證、信任設定和後端驗證設定。
如果是後端 mTLS,負載平衡器的後端服務資源會做為來源工作負載,向後端 (即目的地工作負載) 驗證自身。
您可以將受管理的身分 (以 SPIFFE ID 表示) 指派給負載平衡器的後端服務。Google Cloud 憑證授權單位服務會自動為 SPIFFE ID 佈建 X.509 憑證。這個 SPIFFE ID 的 X.509 憑證也稱為 SPIFFE 可驗證身分文件 (SVID)。負載平衡器的後端服務及其後端會使用 SVID,透過 mTLS 驗證相互驗證。
下圖顯示負載平衡器 (來源工作負載) 和後端 (目的地工作負載) 如何使用代管 Workload Identity 相互驗證。
以下是 X.509-SVID 的範例,可做為 SPIFFE ID 的包裝函式。SPIFFE ID (以 URI 表示) 會編碼在 X.509 憑證的主體別名 (SAN) 中。
Issuer:
C=US
O=Example Inc.
CN=Example CA
Validity:
Not Before: Jun 14 00:00:00 2025 GMT
Not After : Jun 16 00:00:00 2025 GMT
Subject (Distinguished Name):
C=US
O=Example Inc.
OU=Production
CN=api.example.com
Subject Public Key Info:
Public Key Algorithm: RSA Encryption
RSA Public-Key: (2048 bit)
X.509v3 Extensions:
Subject Alternative Name (SAN):
DNS: api.example.com
URI: spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID
這項輸出內容包含下列值:
WORKLOAD_IDENTITY_POOL_ID:Workload Identity Pool IDPROJECT_NUMBER:您Google Cloud 專案的專案編號NAMESPACE_ID:命名空間 IDMANAGED_IDENTITY_ID:代管身分 ID
使用受管理的工作負載身分的好處
使用受管理的工作負載身分進行後端 mTLS 的優點包括:
提升安全性:加入 workload identity pool 後,負載平衡器及其後端會成為信任網域的一部分。 Google Cloud 與後端 mTLS 搭配使用時,負載平衡器和後端工作負載會相互驗證。這項雙向驗證機制可防止未經授權的工作負載存取您的服務,並加密傳輸中的資料。
自動管理憑證:工作負載驗證成功後,Google Cloud 系統會自動為參與工作負載身分集區信任網域的工作負載佈建及輪替 X.509 憑證。自動管理 X.509 憑證可省去複雜且容易出錯的手動憑證管理程序。
可互通的身分:工作負載身分集區使用 SPIFFE 框架,這是管理分散式系統身分的標準,可在現代微服務架構中啟用驗證和授權。
集中式控管:Workload Identity 集區提供集中控管點。管理員可以定義信任網域,並建立認證政策,控管哪些工作負載可取得代管身分的 X.509 憑證。
憑證規定
設定憑證時,請確認憑證符合下列規定:
mTLS 驗證是以現代密碼編譯工具為基礎。憑證必須使用 RSA 或 ECDSA 演算法進行金鑰交換。 雜湊演算法必須使用 SHA-256 或更強的加密雜湊函式。系統不支援 MD4、MD5 和 SHA-1 等雜湊演算法。
後端提供的分葉伺服器憑證必須符合下列規定:
後端 mTLS 中使用的葉狀用戶端 (負載平衡器) 憑證,是自動建立的 Certificate Manager 管理的身分憑證,應會自動符合下列規定:
如要驗證後端向負載平衡器出示的伺服器憑證,信任設定中的根憑證和中繼憑證必須符合下列條件:
使用受管理的工作負載身分進行後端 mTLS 的架構
下列元件會共同運作,使用受管理的工作負載身分達成後端 mTLS:
- 負載平衡器的後端服務 (Compute Engine API)
- 身分與存取權管理信任網域 (Identity and Access Management API)
- 憑證授權單位集區 (憑證授權單位服務 API)
- 後端驗證設定 (Network Security API)
- Certificate Manager 信任設定 (Certificate Manager API)
- Certificate Manager 管理的身分識別憑證 (Certificate Manager API)
下圖顯示負載平衡器後端服務的受管理身分,可讓負載平衡器向後端驗證自身。在圖表中,步驟 1 到 3 代表明確建立的資源,步驟 4 到 5 則代表自動建立的資源。
- 設定憑證授權單位服務 CA 集區,向代管工作負載身分核發憑證。
- 建立 workload identity pool,設定信任網域。這個集區需要命名空間、受管理的身分、驗證政策、內嵌憑證核發設定資源,以及內嵌信任設定資源。
- 使用代管身分設定負載平衡器的後端服務。
代管 Workload Identity 會自動建立 Certificate Manager 代管身分憑證和 Certificate Manager 信任設定。
系統會根據 workload identity pool 中的憑證核發設定,建立 Certificate Manager 管理的身分憑證。Certificate Manager 信任設定會與 workload identity pool 的內嵌信任設定同步。
受管理的工作負載身分會自動建立後端驗證設定。
Certificate Manager 信任設定會附加至後端驗證設定。Certificate Manager 管理的 ID 憑證 (X.509-SVID) 也會附加至後端驗證設定,然後用於後端驗證。
如要進一步瞭解如何使用受管理的身分設定後端 mTLS,請參閱「使用受管理的工作負載身分設定後端 mTLS」。
使用受管理身分在後端 mTLS 期間建立的資源
如上圖所示,將受管理的身分指派給後端服務時,您不需要設定後端驗證設定、Certificate Manager 信任設定和 Certificate Manager 憑證。這些資源是由受管理的工作負載身分自動建立。
本節將深入探討受管理身分設定程序的各個部分,重點在於明確建立的資源,以及自動建立的資源。
明確建立的資源
使用受管理的工作負載身分設定後端 mTLS 時,需要明確建立下列資源。
憑證授權單位集區
如要為負載平衡器設定受管理的工作負載身分,請先設定憑證授權單位,並視需要設定一或多個從屬 CA。這種設定稱為「CA 階層」。
您可以使用 CA 服務集區設定這個階層。
更新內嵌憑證核發設定,即可將 workload identity pool 繫結至 CA pool。
Workload Identity 集區
受管理的工作負載身分是在 workload identity pool 中定義,該集區可做為信任網域。
信任網域代表邏輯安全界線,工作負載可使用 SPIFFE ID 相互驗證及授權。同一信任網域中的所有工作負載會共用信任根,因此工作負載可以互相驗證身分。
如要使用受管理的身分,您必須以 TRUST_DOMAIN 模式設定工作負載身分集區。集區中的所有身分都包含單一命名空間和個別工作負載 ID。
命名空間
在 workload identity pool 中,受管理的工作負載身分會整理成稱為「命名空間」的管理界線。命名空間可協助您整理及授予相關工作負載身分的存取權。
代管型 Workload Identity
受管理的工作負載身分是以 SPIFFE 標準為基礎,這個標準提供架構,可使用專屬 SPIFFE ID 識別、驗證工作負載,並確保工作負載之間的通訊安全。
代管型 Workload Identity 或代管型身分是 workload identity pool 中設定的工作負載 ID。附加至Google Cloud 資源。每個代管身分都會透過命名空間和個別工作負載 ID 進行不重複的識別。
為達成後端 mTLS,受管理的身分會附加至負載平衡器的後端服務資源。
受管理身分的值是完整指定的 SPIFFE ID,必須符合下列格式:
spiffe://TRUST_DOMAIN_NAME/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID
TRUST_DOMAIN_NAME 進一步擴展如下:
WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog
為整合所有項目,Compute Engine 工作負載 (例如負載平衡器的後端服務資源) 可以擁有受管理的身分,如下所示:
spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID
驗證政策
認證政策包含 IAM 規則,可驗證後端服務是否符合資格,能為受管理的身分接收 X.509 憑證。 Google Cloud
如果驗證通過,IAM 會向憑證授權單位服務要求受管理身分的 X.509 憑證。系統會在繫結至受管理身分的 CA 集區中建立 X.509 憑證。CA 服務會透過身分反映佈建憑證,其中設定的 SPIFFE ID 會反映到 X.509 憑證上。
內嵌憑證核發設定
設定 workload identity pool 時,您會設定內嵌憑證核發設定。這項設定會指定要使用 憑證授權單位服務 執行個體的哪個 CA 集區,為 workload identity pool 中的身分產生 X.509 憑證。設定檔也會指定憑證效期、輪替時間範圍百分比和金鑰演算法。
驗證政策強制執行成功後,CA 集區會向受管理的工作負載身分核發 X.509 憑證。
Workload Identity Pool 的內嵌信任設定
根據預設,同一信任網域內的工作負載可以使用受管理的工作負載身分,相互驗證。如要讓不同信任網域中的工作負載相互驗證,您必須在工作負載身分集區中明確宣告信任關係。如要這麼做,請建立內嵌信任設定,以辨識及接受來自其他信任網域的憑證。這些憑證用於建構信任鏈結,並驗證其他網域工作負載的身分。
內嵌信任設定包含一組信任錨點,受管理的工作負載身分會使用這些錨點驗證對等互連憑證。Certificate Manager 信任設定會封裝 SPIFFE 信任存放區,並與 workload identity pool 的內嵌信任設定保持同步。
由於 workload identity pool 會繫結至 CA 集區,因此 workload identity pool 會自動信任該 CA 集區的根憑證。您不需要將集區的 CA 根憑證新增至內嵌信任設定,因為該信任已內建。
在下圖中,負載平衡器和後端屬於同一個信任網域,共用相同的根憑證。根憑證用於建立信任鏈,並驗證信任網域內工作負載的身分。
後端服務 (Compute Engine API)
如要將受管理的身分指派給負載平衡器,您必須設定負載平衡器的後端服務,讓其 tlsSettings 屬性指向新的 identity 屬性 (backendService.tlsSettings.identity)。
請注意,在負載平衡器的後端服務上使用 identity 欄位時,須遵守下列限制:
如果您設定
identity屬性,就無法在tlsSettings屬性中手動設定下列欄位:tlsSettings.snitlsSettings.subjectAltNamestlsSettings.authenticationConfig
identity欄位只能在建立後端服務時指派。identity欄位無法變更。指派給負載平衡器的後端服務後,就無法更新或刪除。
自動建立的資源
在負載平衡器的後端服務上設定 identity 屬性 (backendService.tlsSettings.identity) 後,受管理的工作負載身分識別會自動建立 Certificate Manager API 和 Network Security API 中的下列資源。
自動建立的資源會與後端服務位於同一個專案,並使用該專案的標準配額。
Certificate Manager 信任設定 (Certificate Manager API)
Certificate Manager 信任設定為自動建立,無法直接編輯或刪除。
Certificate Manager 信任設定包含名為 spiffeTrustStores 的欄位。spiffeTrustStores 欄位包含與 workload identity pool 信任網域相關聯的信任套件,以及 workload identity pool 內嵌信任設定中 additionalTrustBundles 欄位指定的任何其他信任套件。詳情請參閱「確認 Certificate Manager 信任設定包含 spiffeTrustStores 欄位」。
如要進一步瞭解如何透過 Certificate Manager 信任設定中的 spiffeTrustStores 欄位驗證 SPIFFE 憑證,請參閱「伺服器憑證驗證步驟」。
Certificate Manager 管理的身分識別憑證 (Certificate Manager API)
Certificate Manager 管理的身分憑證是由代管型 Workload Identity 自動建立。Certificate Manager 管理的身分識別憑證為唯讀,無法使用 Certificate Manager API 直接編輯或刪除。Certificate Manager 管理的身分憑證是以內嵌憑證核發設定為依據,該設定是在 workload identity pool 中定義。
Certificate Manager 代管的身分識別憑證具有 managedIdentity 屬性,可將其識別為代管的身分識別憑證。Certificate Manager 管理的身分憑證資源會以 PEM 編碼格式儲存 X.509-SVID。這個 X.509-SVID 包含編碼為 URI 的 SPIFFE ID (位於 SAN 欄位中)。這個 SPIFFE ID 對應於 workload identity pool 中的受管理身分。
Certificate Manager 代管的身分識別憑證範圍為 CLIENT_AUTH,表示這項憑證在後端 mTLS 中做為用戶端憑證使用。
後端驗證設定 (Network Security API)
後端驗證設定是由受管理的工作負載身分自動建立。後端驗證設定為唯讀,無法使用 Network Security API 直接編輯或刪除。
Certificate Manager 信任設定會附加至後端驗證設定。
憑證管理服務管理的身分憑證也會附加至後端驗證設定,並在負載平衡器與目的地工作負載之間的後端 mTLS 要求中,做為 X.509-SVID 使用。
伺服器憑證驗證步驟
在後端 mTLS 期間驗證伺服器憑證時,負載平衡器會執行下列操作:確認伺服器擁有憑證的私密金鑰。
伺服器會使用與憑證相關聯的私密金鑰簽署一小段資訊,並將該資訊做為
CertificateVerify訊息的一部分傳送至負載平衡器,藉此向負載平衡器證明自己擁有該私密金鑰。負載平衡器接著會使用伺服器憑證的公開金鑰驗證這個簽章。如果簽章驗證失敗,表示後端伺服器沒有與憑證對應的私密金鑰。在這種情況下,負載平衡器會終止 TLS 交握,且不會記錄任何錯誤。驗證信任鏈。
Certificate Manager 信任設定中的「
spiffeTrustStores」欄位可驗證 SPIFFE 憑證。使用受管理的工作負載身分時,系統會自動啟用 Certificate Manager 信任設定中的spiffeTrustStores欄位。啟用spiffeTrustStores欄位後,trustStores欄位會保持空白。spiffeTrustStores欄位是對應資料結構,鍵/值組合如下:- 金鑰可以是與工作負載身分池相關的信任網域 (格式結尾為
.workload.id.goog),也可以是額外的信任網域。 - value 是
TrustStore物件。這個物件包含一組信任的根憑證 (稱為「信任組合」),用於驗證特定信任網域的 SPIFFE 憑證。
基本上,這張對應表可讓您使用多個不同安全網域的信任儲存區,設定負載平衡器。後端提供 SPIFFE 憑證時,負載平衡器會擷取 SPIFFE ID、識別信任網域,並使用
spiffeTrustStores對應組合查閱正確的信任存放區,驗證信任鏈結 和憑證。驗證檢查包括:
- 後端的伺服器憑證、中繼憑證 (如有提供) 和設定的根憑證符合憑證規定。
- 在信任鏈中的所有憑證中,父項憑證的主體欄位與子項憑證的簽發者欄位相符。這項驗證可確保父項憑證的身分 (主體) 與子項憑證中列為簽發者的身分相同。
- 在信任鏈結中,所有憑證的父項憑證主體金鑰 ID (SKID) 都與子項憑證中的授權單位金鑰 ID (AKID) 相符。這項比對作業可確認子憑證是由正確的根授權單位核發,且由於根憑證的公開金鑰會參照 AKID,因此可驗證憑證的有效性,確保憑證可信任。
- 金鑰可以是與工作負載身分池相關的信任網域 (格式結尾為
與後端建立連線。
如果憑證驗證成功,負載平衡器會繼續連線至後端。
不過,如果憑證驗證失敗,負載平衡器會終止與後端的連線,將 HTTP
502狀態碼傳送給用戶端,並將終止原因記錄到 Cloud Logging。如果發生憑證驗證錯誤,後續傳入的要求會觸發負載平衡器重新啟動後端連線。如果後端伺服器拒絕連線,後端連線也可能失敗。使用後端 mTLS 時,如果系統判定用戶端憑證無效,就會發生這種情況。如果連線至後端失敗,負載平衡器會以 HTTP
502狀態碼回應 Proxy 要求,並將一般錯誤原因記錄到 Cloud Logging。
錯誤處理和記錄
應用程式負載平衡器提供詳細的記錄功能,可讓您監控伺服器憑證驗證、找出潛在問題,以及排解連線問題。本節說明 mTLS 驗證期間可能發生的各種錯誤,以及記錄這些錯誤的方式。
如果伺服器憑證驗證失敗,連線就會終止,且錯誤會記錄到 Cloud Logging。下表說明這些錯誤。
| 伺服器憑證狀態 | 記錄錯誤 |
|---|---|
| 伺服器憑證鏈結過長 (伺服器憑證包含超過 10 個中繼憑證)。 |
server_cert_chain_exceeded_limit
|
伺服器或中繼憑證的 RSA 金鑰大小無效。 未執行驗證。 RSA 金鑰位元數可介於 2048 到 4096 之間。 |
server_cert_invalid_rsa_key_size
|
伺服器或中繼憑證使用不支援的橢圓曲線。 未執行驗證。 有效曲線為 P-256 和 P-384。 |
server_cert_unsupported_elliptic_curve_key
|
伺服器或中繼憑證使用 RSA 和 ECDSA 以外的演算法。 未執行驗證。 |
server_cert_unsupported_key_algorithm
|
用於驗證的 PKI 有超過十個中繼憑證,這些憑證共用相同的主體和主體公開金鑰資訊。 未執行驗證。 |
server_cert_pki_too_large
|
用於驗證的中繼憑證含有超過 10 個名稱限制條件。 |
|
伺服器憑證具有 |
|
| 嘗試驗證憑證鏈結時,超過時間限制。 |
server_cert_validation_timed_out
|
嘗試驗證憑證鏈結時,已達到深度或疊代限制。 憑證鏈結的深度上限為十層,包括根憑證和伺服器憑證。疊代次數上限為 100 次 (檢查憑證以驗證伺服器憑證鏈結)。 |
server_cert_validation_search_limit_exceeded
|
您已設定 mTLS,但未設定 |
server_cert_validation_not_performed
|
握手期間,伺服器未提供要求的憑證。 |
server_cert_not_provided
|
伺服器憑證無法通過 |
ssl_certificate_verification_failed
|
服務無法執行憑證鏈結驗證。 |
server_cert_validation_unavailable
|
| 驗證憑證鏈結時發生內部錯誤。 |
server_cert_validation_internal_error
|
找不到相符的 |
server_cert_trust_config_not_found
|
| 伺服器憑證酬載 (包括任何中繼憑證) 過大 (超過 16 KB)。 |
server_cert_exceeded_size_limit
|
限制
您只能為全域外部應用程式負載平衡器設定後端 mTLS 和代管工作負載身分。傳統版應用程式負載平衡器不支援後端 mTLS。
後端 mTLS 不適用於全域網際網路 NEG 後端。
如果將受管理的身分指派給後端服務 (
backendService.tlsSettings.identity),就無法手動設定後端服務tlsSettings屬性的下列欄位:backendService.tlsSettings.snibackendService.tlsSettings.subjectAltNamesbackendService.tlsSettings.authenticationConfig
受管理的身分只能在建立後端服務時指派。
代管身分無法變更。將受管理的身分指派給負載平衡器的後端服務後,就無法更新或刪除。