保护 Cloud Functions 函数

本页面简要介绍使用 Cloud Functions 函数资源控制互动的方式。

访问权限控制

您可以通过两种方法控制 Cloud Functions 函数的访问权限：

使用身份保护访问权限

如需控制对函数的访问，一种方法是要求发出请求的实体使用凭据进行自我标识。凭据是某种“名称”，由实体知道或有权访问的密文（如密码或硬件加密狗）保护。默认情况下，函数部署为 private，并且需要这样的凭据，尽管可以将函数部署为 public（即不需要凭据）。

此流程的第一步是对凭据进行验证，以确保请求者确实是其所说的人，并提供正确的名称和密钥组合。此步骤称为 (Authentication)。

请求者的身份通过身份验证后，可以评估其访问权限级别（即身份已被授予的权限）。此步骤称为 (Authorization)。

Authentication

Cloud Functions 函数支持两种不同的身份，这些身份也称为“主账号”：

  • 服务账号：此类特殊账号充当非个人（例如函数、应用或虚拟机）的身份。它们为您提供了一种对非人员的身份进行身份验证的方法。
  • 用户账号：这些账号代表个人 Google 账号持有人，或 Google 控制的实体（例如 Google 群组）的成员。

对于服务账号和用户账号，凭据的名称部分通常是与账号关联的电子邮件地址。用户账号的密文通常是密码，对于服务账号，通常是与账号一起创建的密钥对的私钥。

但用户密码和服务账号密钥本身非常强大：它们可以提供对数据和功能的广泛访问，并且在被主动撤消或更改之前一直有效。因此，为了限制凭据泄露时可能造成的潜在损害，在 Google Cloud 中，此核心凭据会被替换为基于该凭据的短期凭据（即令牌），令牌具有有限的生命周期，并且在请求序列中即时创建。令牌随请求一起传递，用于安全验证账号。

Cloud Functions 函数中使用两种令牌：访问令牌和 ID 令牌。访问令牌通常用于对 API 调用进行身份验证，ID 令牌用于对开发者创建的代码调用进行身份验证，比方说，如果函数调用另一个函数。令牌本身是使用 OAuth 2 框架及其扩展程序 Open Identity Connect 创建的，但顺序复杂且容易出错，强烈建议使用 Cloud 客户端库管理该流程。

授权

发出请求的实体的身份得到确认后，必须评估系统允许请求者执行的操作。此评估基于已经过身份验证的账号在设置时所获得的权限。Cloud Functions 函数使用 Identity and Access Management (IAM) 来执行此操作。角色（为方便起见而组合在一起的各个权限集）会直接或通过名为政策的配置分配给账号。角色集中的每项权限通常对应于所请求服务公开的单个 REST API 调用。如需详细了解此过程，请参阅通过 IAM 授予访问权限。

基于网络的访问权限控制

您还可以通过指定各个函数的网络设置来限制访问权限。这样，您就可以精确地控制函数的网络入站流量和出站流量。

隔离和沙盒化

函数实例在内部使用 gVisor 沙盒化平台彼此隔离。根据设计，某个函数无法访问其他函数的操作环境。

执行环境更新

Google 会在经过一段时间的稳定性测试后提供安全补丁和维护更新。Cloud Functions 可能会将更新应用于执行环境的其他方面，例如操作系统或包含的软件包。这些更新有助于确保函数的执行环境安全。

Cloud Functions 安全更新

Cloud Functions 提供两种安全更新政策：

  • 自动更新：运行时环境的更新和安全补丁会在新版本的运行时映像中发布。在经过一段时间的稳定性和可靠性测试后，更新后的运行时会部署到所有函数，从而使更新停机时间为零。自动安全更新仅适用于 Cloud Functions (第 1 代)。

  • 在部署更新时：除非另有说明，否则更新或安全补丁仅在部署或重新部署函数时应用于运行时。部署时更新同时适用于 Cloud Functions (第 1 代) 和 Cloud Functions (第 2 代)。

如需详细了解执行环境安全更新，请参阅安全更新政策。