Securing Cloud Functions
This page provides a high-level overview of the ways you can control interactions with your Cloud Functions resources.
Access control
There are two approaches to controlling access to Cloud 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 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 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 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.