函式身分 (第 1 代)

為確保安全， Google Cloud 中每個實體之間的大多數互動都要求可驗證的身分，並以某種 Secret (例如密碼或金鑰) 進行保護。如同其他實體需要身分才能存取 Cloud Run functions，函式本身通常也需要存取其他資源才能運作。 Google Cloud 每個函式都關聯至一個服務帳戶，作為函式存取其他資源時的身分標識。函式用來標識身分的服務帳戶也稱為「執行階段服務帳戶」。

對於正式環境用途，Google 建議為每項函式指派由使用者自行管理的服務帳戶，為其提供專屬身分。透過使用者自行管理的服務帳戶，您可以運用 Identity and Access Management 授予最低限度權限，藉此控管存取權限。

執行階段服務帳戶

除非在部署函式時指定其他執行階段服務帳戶，否則 Cloud Run functions 會使用預設服務帳戶作為函式的執行身分：

  • Cloud Run functions 會使用 App Engine 預設服務帳戶 (PROJECT_ID@appspot.gserviceaccount.com)。

    請注意，專案編號、專案 ID 與專案名稱各自不同。您可以在 Google Cloud 控制台資訊主頁找到專案編號。

這些預設服務帳戶具有「Editor」(編輯者) 角色，可大範圍存取多種 Google Cloud 服務。雖然這是開發函式的最快方式，但 Google 建議僅將預設服務帳戶用於測試和開發。在正式環境中，應只為執行階段服務帳戶授予達成作業目標所需的最低權限。

在正式環境中保護函式安全的措施如下：

變更預設執行階段服務帳戶的權限

控制台

  1. 前往 Google Cloud 控制台的「IAM」(身分與存取權管理) 頁面：

    前往 Google Cloud 控制台

  2. 從表格中選取「App Engine default service account」(App Engine 預設服務帳戶) 或「Default compute service account」(預設 Compute 服務帳戶)。

  3. 按一下列右側的鉛筆圖示，顯示「Edit permissions」(編輯權限) 分頁。

  4. 在「role」(角色) 下拉式選單中新增或移除角色，提供最低的權限存取權。

  5. 按一下「儲存」(Save)。

gcloud

移除「Editor」(編輯者) 角色，然後使用 gcloud projects add-iam-policy-binding 指令新增角色：

# Remove the Editor role
gcloud projects remove-iam-policy-binding PROJECT_ID \
--member="SERVICE_ACCOUNT_EMAIL" \
--role="roles/editor"

# Add the desired role
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="SERVICE_ACCOUNT_EMAIL" \
--role="ROLE"

其中 PROJECT_ID 是您使用的專案 ID，SERVICE_ACCOUNT_EMAIL 是預設執行階段服務帳戶的電子郵件地址 (如上述「執行階段服務帳戶」一節所示)，ROLE 則是要指派給預設執行階段服務帳戶的新角色。

為函式使用個別服務帳戶

為了更靈活控管函式存取權限，您可以為每個函式指派專屬的使用者自行管理服務帳戶。

  1. 建立服務帳戶。並記下名稱。
  2. 依據函式需要存取的資源，為其授予適當角色。

  3. 如果服務帳戶和函式位於不同專案，請在服務帳戶所在專案進行下列設定：

    1. 設定服務帳戶以支援專案運作。

    2. 將服務帳戶權杖建立者角色 (roles/iam.serviceAccountTokenCreator) 授予 Cloud Run functions 服務代理程式 (service-PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com)，其中 PROJECT 是指函式所在的專案。Cloud Run functions 服務代理程式會管理服務帳戶的跨專案存取權限。

    3. 將 iam.serviceaccounts.actAs 權限授予不同專案服務帳戶上的 Cloud Run functions 服務代理程式。

  4. 授予服務帳戶資源存取權限。具體方法因資源類型而異。

  5. 將服務帳戶關聯至函數，此步驟可於部署時進行，或在更新已部署函數時設定。

在部署時新增使用者自行管理的服務帳戶

控制台

  1. 前往 Google Cloud 控制台

    前往 Google Cloud 控制台

  2. 指定並設定您所需要的函式。

  3. 點按「Runtime, build…」(執行階段，版本…) 以顯示更多選項。

  4. 選取「Runtime」(執行階段) 分頁標籤。

  5. 點按「Service account」(服務帳戶) 下拉式選單，然後選取所需服務帳戶。

  6. 依序點選「Next」(下一步)和「Deploy」(部署)。

gcloud

使用 gcloud functions deploy 部署函式時，請新增 --service-account 旗標。例如：

gcloud functions deploy --no-gen2 FUNCTION_NAME --service-account SERVICE_ACCOUNT_EMAIL

其中 FUNCTION_NAME 是函式名稱，SERVICE_ACCOUNT_EMAIL 則是服務帳戶電子郵件地址。

更新現有函式的服務帳戶

您可以更新現有函式的執行階段服務帳戶。

控制台

  1. 前往 Google Cloud 控制台：

    前往 Google Cloud 控制台

  2. 點按所需函式的名稱，前往詳細資料頁面。

  3. 點按詳細資料頁面頂端的「Edit」(編輯) 鉛筆圖示，即可編輯函式。

  4. 點按「Runtime, build…」(執行階段，版本…) 以顯示更多選項。

  5. 選取「Runtime」(執行階段) 分頁標籤。

  6. 點按「Service account」(服務帳戶) 下拉式選單，然後選取所需服務帳戶。

  7. 依序點選「Next」(下一步)和「Deploy」(部署)。

gcloud

使用 gcloud functions deploy 部署函式時，請新增 --service-account 旗標：

gcloud functions deploy FUNCTION_NAME --service-account SERVICE_ACCOUNT_EMAIL

其中 FUNCTION_NAME 是函式名稱，SERVICE_ACCOUNT_EMAIL 則是服務帳戶

此時，重新部署的函式就會使用新的執行階段服務帳戶。

使用中繼資料伺服器取得權杖

雖然 IAM 定義的服務帳戶是管理 Google Cloud存取權限的首選方法，但部分服務可能需採用其他模式，例如 API 金鑰、OAuth 2.0 用戶端或服務帳戶金鑰。存取外部資源時，可能也需要使用其他方法。

如果目標服務要求提供 OpenID Connect ID 權杖或 OAuth 2.0 存取權杖，也許可以使用 Compute 中繼資料伺服器擷取這些權杖，而不必設定完整的 OAuth 用戶端。

身分識別權杖

您可以使用 Compute 中繼資料伺服器來擷取身分識別權杖和特定目標對象，如下所示：

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
  -H "Metadata-Flavor: Google"

其中 AUDIENCE 是要求的目標，例如所要叫用的服務網址 (如 https://service.domain.com)，或是受 IAP 保護的資源 OAuth 用戶端 ID (如 1234567890.apps.googleusercontent.com)。

存取權杖

OAuth 2.0 存取權杖採用「範圍」定義存取權限。根據預設， Google Cloud 存取權杖具有 cloud-platform 範圍。如要存取其他 Google 或 Google Cloud API，您必須擷取具有適當範圍的存取權杖。

您可以使用 Compute 中繼資料伺服器來擷取存取權杖。

如有需要，您可以產生具有特定範圍的存取憑證，如下所示：

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token?scopes=SCOPES" \
  -H "Metadata-Flavor: Google"

其中 SCOPES 是以半形逗號分隔的 OAuth 範圍清單，例如：https://www.googleapis.com/auth/drive,https://www.googleapis.com/auth/spreadsheets。

請參考 Google OAuth 範圍的完整清單，尋找您要的範圍。

後續步驟

瞭解如何授權他方存取您的函式，或驗證開發人員及其他函式的身分，以允許他們叫用您的函式。