但用户密码和服务账号密钥本身非常强大：它们可以提供对数据和功能的广泛访问，并且在被主动撤消或更改之前一直有效。因此，为了限制凭据泄露时可能造成的潜在损害，在 Google Cloud 中，此核心凭据会被替换为基于该凭据的短期凭据（即令牌），令牌具有有限的生命周期，并且在请求序列中即时创建。令牌随请求一起传递，用于安全验证账号。
Cloud Run functions 函数中使用两种令牌：访问令牌和 ID 令牌。访问令牌通常用于对 API 调用进行身份验证，ID 令牌用于对开发者创建的代码调用进行身份验证，比方说，如果函数调用另一个函数。令牌本身是使用 OAuth 2 框架及其扩展程序 Open Identity Connect 创建的，但顺序复杂且容易出错，强烈建议使用 Cloud 客户端库管理该流程。
授权
发出请求的实体的身份得到确认后，必须评估系统允许请求者执行的操作。此评估基于已经过身份验证的账号在设置时所获得的权限。Cloud Run functions 函数使用 Identity and Access Management (IAM) 来执行此操作。角色（为方便起见而组合在一起的各个权限集）会直接或通过名为政策的配置分配给账号。角色集中的每项权限通常对应于所请求服务公开的单个 REST API 调用。如需详细了解此过程，请参阅通过 IAM 授予访问权限。
Google 会在经过一段时间的稳定性测试后提供安全补丁和维护更新。Cloud Run functions 函数可能会将更新应用于执行环境的其他方面，例如操作系统或包含的软件包。这些更新将帮助确保您函数的执行环境安全无虞。
Cloud Run functions 安全更新
您可以选择以下安全更新政策之一：
自动更新（默认）：运行时环境的更新和安全补丁会在新版本的运行时映像中发布。在经过一段时间的稳定性和可靠性测试后，更新后的运行时会部署到所有函数，从而使更新停机时间为零。Cloud Run functions（第 1 代）和 Cloud Run functions 提供自动安全更新。如需进行语言级安全修复，您可能需要重新构建使用编译语言（如 Go 或 Java）的函数。
在部署更新时：除非另有说明，否则更新或安全补丁仅在部署或重新部署函数时应用于运行时。部署时更新同时适用于 Cloud Run functions（第 1 代）和 Cloud Run functions。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-05。"],[[["\u003cp\u003eCloud Run functions can be secured through identity-based and network-based access control methods.\u003c/p\u003e\n"],["\u003cp\u003eIdentity-based access control involves authenticating the requesting entity using credentials and then authorizing their access based on assigned permissions via Identity and Access Management (IAM).\u003c/p\u003e\n"],["\u003cp\u003eAuthentication for Cloud Run functions supports service accounts for non-persons and user accounts for individuals, using tokens for secure and temporary access.\u003c/p\u003e\n"],["\u003cp\u003eNetwork-based access control allows fine-tuning of network ingress and egress for individual functions, while functions are internally isolated via gVisor sandboxing.\u003c/p\u003e\n"],["\u003cp\u003eCloud Run functions offers two security update policies that ensure secure execution environments: automatic updates with zero downtime, and on-deployment updates which are applied when the functions are redeployed.\u003c/p\u003e\n"]]],[],null,["# Secure your Cloud Run function\n==============================\n\nThis page provides a high-level overview of the ways you can control interactions\nwith your Cloud Run functions resources.\n\nAccess control\n--------------\n\nThere are two approaches to controlling access to Cloud Run functions:\n\n- [Identity-based](#identity)\n- [Network-based](#network)\n\n### Securing access with identity\n\nOne way to control access to a function is to require that the requesting entity\nidentify itself by using a credential. A credential is a \"name\"\nof some sort, secured by a secret that the entity knows or has access to, like\na password or a hardware dongle. By default, functions are deployed\nas *private* , and require such a credential, although it is possible to deploy\na function as *public*, that is, not requiring one.\n\nThe first step in the process is validating the credential to make sure that\nthe requestor is who it says it is, that it presents the right name and secret\ncombination. This step is called ([`Authentication`](/docs/authentication)).\n\nOnce the requestor's identity has been authenticated, its level of access, the\npermissions that the identity has been granted, can be evaluated. This step\nis called ([`Authorization`](https://en.wikipedia.org/wiki/Authorization)).\n\n#### Authentication\n\nCloud Run functions supports two different kinds of identities, which are also\ncalled *principals*:\n\n- [Service accounts](/iam/docs/service-accounts): These are special accounts that serve as the identity of a non-person, like a function or an application or a VM. They give you a way to authenticate these non-persons.\n- User accounts: These accounts represent people - either as individual Google account holders or as part of a Google-controlled entity like a Google Group.\n\nFor both service accounts and user accounts, the name portion of the credential\nis usually an email address associated with the account. The secret\nfor a user account is usually a password, and for a service account, it is\nusually the private key of the key pair that is created along with the account.\n\nBut user passwords and service account keys themselves are very powerful: they\ncan provide wide-ranging access to data and functionality and they remain\neffective until they are actively revoked or changed. So to limit the potential\ndamage that might occur if the credential leaked, in Google Cloud this core\ncredential is replaced by a short-term credential based on it, a *token*, one that has\na limited lifetime and is created on the fly as part of the request sequence.\nThe token is passed with the request and serves to safely authenticate the account.\n\nThere are two kinds of tokens used in Cloud Run functions: access tokens and id\ntokens. Access tokens are usually used to authenticate API calls and id tokens\nare used to authenticate calls to developer-created code, for example, if a\nfunction calls another function. The tokens themselves are created using\nthe OAuth 2 framework, and its extension, Open Identity Connect, but the sequence\nis complex and error-prone, and the use of [Cloud Client Libraries](/apis/docs/cloud-client-libraries)\nto manage the process is highly recommended.\n\n#### Authorization\n\nOnce the identity of the requesting entity has been confirmed, what it is that\nthe requestor is allowed to do must be evaluated. This evaluation is based\non what *permissions* the authenticated account was granted when it was set up.\nCloud Run functions uses [Identity and Access Management](/iam/docs) (IAM) to do this.\n[*Roles*](/iam/docs/understanding-roles), which are sets of individual permissions\ngrouped together for convenience, are assigned to the account, either directly\nor via a configuration called a [*policy*](/iam/docs/reference/rest/v1/Policy).\nEach individual permission in the role set usually corresponds to a single REST\nAPI call exposed by the requested service. For more information on this process,\nsee [Authorizing Access via IAM](/functions/1stgendocs/securing/managing-access-iam).\n\n### Network-based access control\n\nYou can also limit access by specifying [network settings](/functions/1stgendocs/networking/network-settings)\nfor individual functions. This allows for fine-tuned control over the network\ningress and egress to and from your functions.\n\nIsolation and sandboxing\n------------------------\n\nInternally, function instances are isolated from each other using the\n[gVisor](https://gvisor.dev/) sandboxing platform. By design, a function cannot\naccess other functions' operating environments.\n\nExecution environment updates\n-----------------------------\n\nGoogle makes security patches and maintenance updates available after a period of\nstability testing. Cloud Run functions might apply updates to other aspects of\nthe execution environment, such as the operating system or included packages.\nThese updates help keep your function's [execution environment secure](/functions/1stgendocs/securing/execution-environment-security).\n\n### Cloud Run functions security updates\n\nYou can choose one of the following security update policies:\n\n- **Automatic updates** (default): Updates and security patches to the runtime environment\n are published in new versions of the runtime image. After a period of testing for\n stability and reliability, the updated runtime is rolled out to all functions\n resulting in a zero downtime update. Automatic security updates are\n available with Cloud Run functions (1st gen) and Cloud Run functions. To take on language-level security fixes, you may need to rebuild functions that use compiled languages such as Go or Java.\n\n- **On deployment updates**: Updates and security patches are applied\n to runtimes only when functions are deployed or redeployed, unless\n otherwise noted. Updates on deployment are available on both\n Cloud Run functions (1st gen) and Cloud Run functions.\n\nThe runtime update policy can be changed using the `--runtime-update-policy`\n[flag](/sdk/gcloud/reference/functions/deploy#--runtime-update-policy) in your `gcloud functions deploy` command.\n\nTo learn more about execution environment security updates, see\n[security update policies](/functions/1stgendocs/securing/execution-environment-security#security_update_policy)."]]
