Securing Cloud Run functions

Exam guide§2.1

You secure access to Cloud Run functions with two independent layers: identity-based access controls (who is calling, and what are they allowed to do) and network-based access controls (where the traffic may enter from and exit to). This page covers authenticating and authorizing callers, the runtime identity a function uses to reach other resources, function-to-function calls, ingress/egress network settings, and wrapping functions in a VPC Service Controls perimeter.

Identity-based access control

Securing a caller by identity is always two steps, in order:

#NumbersTwo steps of identity-based access

1. Authentication - validate the identity credential and confirm the requestor is who it says it is.
2. Authorization - once authenticated, evaluate the identity's level of access (its permissions).

⚠GotchaFunctions are private by default

By default, functions are deployed as private and require authentication. You can also deploy a function as public, which does not require authentication - only do this deliberately.

Identities and tokens

Cloud Run functions supports two kinds of identity, and callers authenticate by creating a short-lived token from the account's credential (never by sending the credential itself). The token is passed with the request and has a limited lifetime, which limits the damage if it leaks.

Identity	Represents
Service account	The identity of a non-person - a function, application, or VM.
User account	A person - an individual Google Account holder or a member of a Google Group.

Tokens are created using the OAuth 2.0 framework and OpenID Connect (OIDC). Two token types are used:

Token	Authenticates
OAuth 2.0 access token	API calls.
ID token (OIDC)	Calls to developer-created code - for example, one function calling another.

Authorization with IAM

Cloud Run functions uses Identity and Access Management (IAM) to evaluate permissions through roles. A role is a set of individual permissions grouped together and assigned to an account, either directly or through a policy. Each permission usually maps to a single REST API call exposed by the service.

Authorizing administrative access

To let a principal create, update, or delete functions, add the principal (a user or service account email) to the function and assign it an IAM role. The predefined roles supported by Cloud Run functions are:

Role	Grants
Cloud Functions Admin	Full control of functions, including IAM policy.
Cloud Functions Developer	Create, update, and delete functions.
Cloud Functions Invoker	Invoke (call) a function only.
Cloud Functions Viewer	Read-only view of functions.

CommandsAuthorize a principal on a function

gcloud functions add-iam-policy-binding FUNCTION_NAME \

--member=account_email \

--role=ROLE

Authorizing invocation

How a function is invoked depends on its type:

Function type	Who can invoke it
Event-driven	Only the event source it is subscribed to.
HTTP	Any identity - a developer testing it, or another service - that presents an ID token with the right permissions.

#NumbersTesting an HTTP function as a developer

1. Have a user account with a role granting cloudfunctions.functions.invoke on the function.
2. Generate an ID token for that account with the gcloud CLI.
3. Pass the token in the Authorization header of the request.

CommandsInvoke a function with an ID token

curl -H "Authorization: bearer $(gcloud auth print-identity-token)" \

https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION_NAME

Function identity

Every function has a runtime service account - the identity it uses when it accesses other Google Cloud resources to do its work.

The default runtime service account is the Compute Engine default service account (or the App Engine default service account for 1st generation).

⚠GotchaDo not run production functions as the default service account

The default runtime service account is for development and testing only - it is broadly privileged. For production, deploy the function with a dedicated runtime service account and grant it only the minimum permissions it needs (least privilege).

Function-to-function calls

When one function calls another, restrict each function so it can only reach a specific subset of your functions.

#NumbersLet a calling function invoke a receiving function

1. Grant the Cloud Run Invoker role (roles/run.invoker) to the calling function's service account, on the receiving function. (For 1st generation, grant Cloud Run functions Invoker, roles/cloudfunctions.invoker.)
2. The calling function sends a Google-signed ID token with the audience (aud) field set to the URL of the receiving function, in the Authorization header.

CommandsGrant the calling function's service account invoke access

gcloud functions add-iam-policy-binding RECEIVING_FUNCTION \

--member='serviceAccount:CALLING_FUNCTION_IDENTITY' \

--role='roles/cloudfunctions.invoker'

Network-based access control

Network settings control ingress and egress to and from an individual function. The two are independent.

Two independent network controls on a function: ingress settings gate who can invoke it, egress settings route its outbound requests through a Serverless VPC Access connector.

• Ingress restricts whether resources outside your project or VPC Service Controls perimeter can invoke the function. Internal traffic means traffic from Workflows and VPC networks in the same project or perimeter.
• Egress controls the routing of a function's outbound HTTP requests, and requires a Serverless VPC Access connector. Set it to route all outbound traffic through the connector, or only requests to private IPs.

The connector fundamentals (the /28 subnet, region matching, firewall rules on the connector) live on the Serverless VPC Access page.

Using VPC Service Controls

Wrap functions in a VPC Service Controls service perimeter for defense in depth.

#NumbersSecuring functions with VPC Service Controls

1. Create a service perimeter and add one or more projects to it. For a Shared VPC, add both the host and service projects.
2. Restrict the Cloud Functions API by setting organization policies that control the network settings for functions in the perimeter.

With those organization policies in place:

≡FactsEffect of the organization policies

• HTTP functions accept traffic only from a VPC network within the perimeter.
• All functions must use a Serverless VPC Access connector.
• Functions must route all egress through your VPC network.