本頁說明兩種 Cloud Run 身分,以及 Cloud 用戶端程式庫如何使用服務身分呼叫 Google Cloud API。Cloud Storage、Firestore、Cloud SQL、Pub/Sub 和 Cloud Tasks 等產品都有 Cloud 用戶端程式庫。 Google Cloud 本文適用於管理機構政策和使用者存取權的管理員、營運人員或開發人員,以及想瞭解這類主題的所有使用者。
Cloud Run 身分
如要使用 Cloud Run,Cloud Run 使用者和 Cloud Run 執行個體都必須有身分。 Google Cloud
- Cloud Run 使用者的身分稱為「Cloud Run 部署者帳戶」。管理修訂版本或作業時,您會使用這個身分向 Cloud Run Admin API 提出要求。
- Cloud Run 執行個體的 ID 稱為 Cloud Run 服務 ID。當您編寫的 Cloud Run 程式碼與 Cloud 用戶端程式庫互動,或呼叫其他 Cloud Run 服務進行服務間通訊時,您會使用這個身分,從 Cloud Run 向Google Cloud API 或其他 Cloud Run 服務提出要求。
如要存取 Google Cloud API 或在服務之間進行通訊,每個身分都必須在身分與存取權管理 (IAM) 中獲得適當的權限。
使用部署者帳戶呼叫 Cloud Run Admin API
您可以使用 Cloud Run 部署者帳戶,從 Cloud Run 呼叫 Cloud Run Admin API。部署者帳戶可以是使用者帳戶或服務帳戶,代表已登入 Google Cloud 環境的帳戶。
當部署者帳戶使用 Cloud Run 時,IAM 會檢查部署者帳戶是否具備執行 Cloud Run 作業的必要權限。下圖顯示使用者帳戶如何呼叫 Cloud Run Admin API,從Google Cloud 控制台部署新修訂版本:
使用服務身分呼叫 Google Cloud API
當 Cloud Run 執行個體與其他經過 IAM 驗證的 Cloud Run 服務互動,或透過應用程式碼或內建功能 (例如 Cloud Run 整合或 Cloud Storage 磁碟區掛接) 呼叫 Cloud 用戶端程式庫時, Google Cloud 環境會使用應用程式預設憑證 (ADC) 自動偵測 Cloud Run 服務身分是否已通過驗證,可執行 API 作業。Cloud Run 服務身分是服務帳戶,在您部署修訂版本或執行工作時,系統會將其指派為 Cloud Run 執行個體的身分。
如果部署者帳戶使用的服務帳戶與 Cloud Run 設定中的服務帳戶相同,該服務帳戶才會做為服務身分使用。
本指南的其餘部分說明 Cloud Run 服務或工作如何使用服務身分呼叫及存取 Google 服務和 API。如要進一步瞭解服務身分設定,請參閱服務和工作的服務身分設定頁面。
服務身分適用的服務帳戶類型
當 Cloud Run 執行個體呼叫 API 來執行所需作業時,Cloud Run 會自動使用服務帳戶做為服務身分。 Google Cloud 可做為服務身分的服務帳戶類型如下:
- 使用者管理的服務帳戶 (建議):您手動建立這個服務帳戶,並決定服務帳戶存取特定 Google Cloud 資源所需的最低權限。使用者代管的服務帳戶採用
SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
格式。 - Compute Engine 預設服務帳戶:Cloud Run 會自動提供 Compute Engine 預設服務帳戶做為預設服務身分。Compute Engine 預設服務帳戶的格式為
PROJECT_NUMBER-compute@developer.gserviceaccount.com
。
設定服務身分時,請避免使用預設服務帳戶
根據預設,系統會自動建立 Compute Engine 預設服務帳戶。如果建立 Cloud Run 服務或作業時未指定服務帳戶,Cloud Run 會使用這個服務帳戶。
視機構政策設定而定,系統可能會自動將專案的編輯者角色授予預設服務帳戶。強烈建議您
強制執行 iam.automaticIamGrantsForDefaultServiceAccounts
機構政策限制,停用自動授予角色功能。如果您是在 2024 年 5 月 3 日後建立機構,系統預設會強制執行這項限制。
如果停用自動角色授予功能,您必須決定要授予預設服務帳戶哪些角色,然後自行授予這些角色。
如果預設服務帳戶已具備「編輯者」角色,建議您將「編輯者」角色替換為權限較少的角色。如要安全地修改服務帳戶的角色,請使用 政策模擬器查看變更的影響,然後授予及撤銷適當的角色。
服務身分的運作方式
當程式碼呼叫或要求 Cloud 用戶端程式庫時,會發生下列情況:
- 用戶端程式庫會偵測到對 Google CloudAPI 或 Cloud 用戶端程式庫提出的要求,並向執行個體中繼資料伺服器要求服務身分的 OAuth 2.0 存取權杖。
- 執行個體中繼資料伺服器會為設定為服務身分的服務帳戶提供 IAM 存取權杖。
- 要求會連同 OAuth 2.0 存取權杖傳送至 Google Cloud API。
- IAM 會驗證存取權杖中參照的服務身分是否具備必要權限,並檢查政策繫結,然後再將呼叫轉送至 API 端點。
- Google Cloud API 會執行這項作業。
產生 Cloud Run 要求的存取權杖,以便呼叫 Google Cloud API
如果 Cloud Run 程式碼使用 Cloud 用戶端程式庫,您可以在部署或執行時指派服務帳戶,藉此在 Cloud Run 中設定服務身分。這樣一來,程式庫就能自動取得存取權杖,驗證程式碼的要求。如果 Cloud Run 程式碼會與其他經過驗證的 Cloud Run 服務通訊,您必須在要求中加入存取權杖。
如要將服務帳戶指派為服務身分,請參閱下列指南:
不過,如果您使用自己的自訂程式碼,或需要以程式輔助方式發出要求,可以直接使用中繼資料伺服器,手動擷取下一節所述的身分符記和存取權杖。請注意,您無法直接從本機查詢這個伺服器,因為中繼資料伺服器僅適用於在Google Cloud上執行的工作負載。
使用中繼資料伺服器擷取 ID 和存取權杖
您可以透過中繼資料伺服器擷取以下兩種符記:
- OAuth 2.0 存取權杖,用於呼叫大多數的 Google API 用戶端程式庫。
- ID 權杖,用於呼叫其他 Cloud Run 服務,或叫用任何會驗證 ID 權杖的服務。
如要擷取權杖,請按照相關分頁的操作說明執行,取得您使用的權杖類型:
存取權杖
舉例來說,如要建立 Pub/Sub 主題,請使用 projects.topics.create
方法。
使用 Compute 中繼資料伺服器擷取存取憑證:
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \ --header "Metadata-Flavor: Google"
這個端點會傳回含有
access_token
屬性的 JSON 回應。在 HTTP 通訊協定要求中,要求必須使用
Authorization
標頭中的存取權杖進行驗證:PUT https://pubsub.googleapis.com/v1/projects/
PROJECT_ID
/topics/TOPIC_ID
Authorization: BearerACCESS_TOKEN
其中:
PROJECT_ID
是您的專案 ID。TOPIC_ID
是主題 ID。ACCESS_TOKEN
是您在上一個步驟中擷取的存取權杖。
回應:
{ "name": "projects/
PROJECT_ID
/topics/TOPIC_ID
" }
ID 權杖
使用 Compute 中繼資料伺服器擷取身分符記和特定目標對象:
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
--header "Metadata-Flavor: Google"
其中 AUDIENCE
是要求的 JWT 目標對象。
如果是 Cloud Run 服務,對象應為您叫用的服務網址,或是為該服務設定的自訂對象 (例如自訂網域)。
https://service.domain.com
如果是其他資源,則可能是受 IAP 保護資源的 OAuth 用戶端 ID:
1234567890.apps.googleusercontent.com
後續步驟
- 為服務或作業設定服務身分。
- 瞭解如何管理存取權或如何安全地向您的服務驗證開發人員、服務和使用者。
- 如要瞭解如何使用服務身分將安全性風險降至最低,請參閱保護 Cloud Run 服務教學課程,取得應用程式的完整逐步說明。