Secure your Cloud Run function
This page provides a high-level overview of the ways you can control interactions with your Cloud Run functions resources.
Access control
There are two approaches to controlling access to Cloud Run functions:
Securing access with identity
One way to control access to a function is to require that the requesting entity identify itself by using a credential. A credential is a "name" of some sort, secured by a secret that the entity knows or has access to, like a password or a hardware dongle. By default, functions are deployed as private, and require such a credential, although it is possible to deploy a function as public, that is, not requiring one.
The first step in the process is validating the credential to make sure that
the requestor is who it says it is, that it presents the right name and secret
combination. This step is called (Authentication).
Once the requestor's identity has been authenticated, its level of access, the
permissions that the identity has been granted, can be evaluated. This step
is called (Authorization).
Authentication
Cloud Run functions supports two different kinds of identities, which are also called principals:
- 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.
- User accounts: These accounts represent people - either as individual Google account holders or as part of a Google-controlled entity like a Google Group.
For both service accounts and user accounts, the name portion of the credential is usually an email address associated with the account. The secret for a user account is usually a password, and for a service account, it is usually the private key of the key pair that is created along with the account.
But user passwords and service account keys themselves are very powerful: they can provide wide-ranging access to data and functionality and they remain effective until they are actively revoked or changed. So to limit the potential damage that might occur if the credential leaked, in Google Cloud this core credential is replaced by a short-term credential based on it, a token, one that has a limited lifetime and is created on the fly as part of the request sequence. The token is passed with the request and serves to safely authenticate the account.
There are two kinds of tokens used in Cloud Run functions: access tokens and id tokens. Access tokens are usually used to authenticate API calls and id tokens are used to authenticate calls to developer-created code, for example, if a function calls another function. The tokens themselves are created using the OAuth 2 framework, and its extension, Open Identity Connect, but the sequence is complex and error-prone, and the use of Cloud Client Libraries to manage the process is highly recommended.
Authorization
Once the identity of the requesting entity has been confirmed, what it is that the requestor is allowed to do must be evaluated. This evaluation is based on what permissions the authenticated account was granted when it was set up. Cloud Run functions uses Identity and Access Management (IAM) to do this. Roles, which are sets of individual permissions grouped together for convenience, are assigned to the account, either directly or via a configuration called a policy. Each individual permission in the role set usually corresponds to a single REST API call exposed by the requested service. For more information on this process, see Authorizing Access via IAM.
Network-based access control
You can also limit access by specifying network settings for individual functions. This allows for fine-tuned control over the network ingress and egress to and from your functions.
Isolation and sandboxing
Internally, function instances are isolated from each other using the gVisor sandboxing platform. By design, a function cannot access other functions' operating environments.
Execution environment updates
Google makes security patches and maintenance updates available after a period of stability testing. Cloud Run functions might apply updates to other aspects of the execution environment, such as the operating system or included packages. These updates help keep your function's execution environment secure.
Cloud Run functions security updates
You can choose one of the following security update policies:
Automatic updates (default): Updates and security patches to the runtime environment are published in new versions of the runtime image. After a period of testing for stability and reliability, the updated runtime is rolled out to all functions resulting in a zero downtime update. Automatic security updates are 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.
On deployment updates: Updates and security patches are applied to runtimes only when functions are deployed or redeployed, unless otherwise noted. Updates on deployment are available on both Cloud Run functions (1st gen) and Cloud Run functions.
The runtime update policy can be changed using the --runtime-update-policy
flag in your gcloud deploy command.
To learn more about execution environment security updates, see security update policies.