保護 Cloud Run 函式

本頁面提供概要總覽，說明如何控管與 Cloud Run 函式資源的互動。

存取控管

控管 Cloud Run 函式存取權的方法有兩種：

透過身分識別確保存取安全

如要控管函式存取權，其中一種方法是請提出要求的實體使用憑證識別其身分。憑證是某種「名稱」，由實體知道或可存取的密碼 (例如密碼或硬體安全金鑰) 保護。根據預設，函式會以「私人」形式部署，且需要這類憑證，但也可以部署為「公開」函式，也就是不需要憑證。

程序的第一步是驗證憑證，確保要求者身分無誤，並提供正確的名稱和密碼組合。此步驟稱為 (Authentication)。

要求者的身分經驗證後，即可評估其存取層級和獲准的權限。此步驟稱為 (Authorization)。

驗證

Cloud Run 函式支援兩種不同的身分，也稱為主體：

  • 服務帳戶：這類特殊帳戶代表非人員身分，例如函式、應用程式或 VM，可讓您驗證這些非人員身分。
  • 使用者帳戶：這些帳戶代表使用者，可以是個別 Google 帳戶持有人，也可以是 Google 控制的實體 (例如 Google 群組) 的成員。

無論是服務帳戶或使用者帳戶，憑證的名稱部分通常是與帳戶相關聯的電子郵件地址。使用者帳戶的密鑰通常是密碼，服務帳戶的密鑰則通常是與帳戶一併建立的金鑰組私密金鑰。

但使用者密碼和服務帳戶金鑰本身非常強大，可提供廣泛的資料和功能存取權，而且在主動撤銷或變更之前，都會保持有效。因此，為限制憑證外洩可能造成的損害，系統會根據此核心憑證，以短期憑證 (即「權杖」) 取代，這類憑證的效期有限，且會在要求序列中即時建立。 Google Cloud 此權杖會隨要求一併傳送，用於安全地驗證帳戶。

Cloud Run 函式會使用兩種權杖：存取權杖和 ID 權杖。存取權杖通常用於驗證 API 呼叫，而 ID 權杖則用於驗證對開發人員建立的程式碼發出的呼叫 (例如函式呼叫另一個函式)。權杖本身是使用 OAuth 2 架構及其擴充功能 Open Identity Connect 所建立，但此序列複雜且容易出錯，因此強烈建議使用 Cloud Client Libraries 來管理程序。

授權

確認要求實體的 ID 後，必須評估要求者可執行的操作。這項評估的依據是經過驗證的帳戶在設定時獲得的「權限」。Cloud Run 函式會使用 Identity and Access Management (IAM) 執行這項操作。「角色」：為方便起見，系統會將個別權限分組，並直接或透過稱為「政策」的設定，將角色指派給帳戶。角色集中的每一項個別權限，通常都對應於該服務所提供的一個單一 REST API 呼叫。如要進一步瞭解這個程序，請參閱「透過 IAM 授權存取權」。

網路型存取控管

您也可以為個別功能指定網路設定以限制存取權。這樣一來，您就能精細控管函式的網路輸入和輸出。

隔離和沙箱機制

在內部，函式執行個體會使用 gVisor 沙箱平台彼此隔離。根據設計，函式無法存取其他函式的作業環境。

執行作業環境更新

經過一段時間的穩定性測試之後，Google 會提供安全性修補程式和維護更新內容。Cloud Run 函式可能會將更新內容套用至執行環境的其他方面，例如作業系統或內含套件。這些更新內容可以確保函式的執行環境安全無虞。

Cloud Run 函式安全性更新

您可以選擇下列其中一種安全性更新政策：

  • 自動更新 (預設)：執行階段環境的更新和安全性修補程式，會在執行階段映像檔的新版本中發布。經過一段時間的穩定性和可靠性測試後，更新後的執行階段會部署至所有函式，因此更新期間不會發生停機情形。Cloud Run 函式 (第 1 代) 和 Cloud Run 函式提供自動安全更新。如要進行語言層級的安全性修正，您可能需要重建使用 Go 或 Java 等編譯語言的函式。

  • 部署更新：除非另有說明，否則只有在部署或重新部署函式時，才會將更新和安全性修補程式套用至執行階段。Cloud Run 函式 (第 1 代) 和 Cloud Run 函式都會顯示部署時套用的更新。

您可以在 gcloud functions deploy 指令中使用 --runtime-update-policy 旗標，變更執行階段更新政策。

如要進一步瞭解執行環境安全性更新，請參閱安全性更新政策。