Accessing and authenticating to functions
1. Accessing and authenticating to functions
Welcome to this module on securing Cloud Run functions. In this module, we discuss how to secure Cloud Run functions with identity and network-based access controls. You learn how to authenticate and authorize access to cloud functions, and how to protect Cloud Run functions and related data with encryption keys. We’ll first discuss how you can secure access to your Cloud Run functions, and how to authenticate and authorize to Cloud Run functions during invocation. We’ll also discuss how you can protect Cloud Run functions and their associated data. Finally, we’ll review what was discussed in this module. Let’s get started with securing access to Cloud Run functions. You secure access to Cloud Run functions with identity-based access controls and network-based access controls. To secure access with identity-based access controls, the first step is to validate the identity credential, and make sure that the requestor is who it says it is. Once the requestor's identity has been authenticated, its level of access or permissions can be evaluated. This step is called authorization. By default, functions are deployed as private, and require authentication. You can also deploy a function as public and not require authentication. Cloud Run functions supports two different kinds of identities: Service accounts, which serve as the identity of a non-person, like a function, application, or a VM. And user accounts, which represent people - either as individual Google Account holders or as part of a Google Group. To authenticate to Cloud Run functions, clients create a token based on the service account or user account credential. The token has a limited lifetime, is passed with the request, and serves to safely authenticate the account. The token-based authentication is used to limit the potential damage that might occur if the service or user account credential is leaked. Cloud Run functions uses two types of tokens: OAuth 2.0 access tokens, used to authenticate API calls. And ID tokens, used to authenticate calls to developer-created code, for example, a function calling another function. The tokens are created using the OAuth 2.0 framework and Open Identity Connect (OIDC). Once the identity of the requesting entity has been confirmed, the permissions of the identity are evaluated. The permissions are granted when the authenticated account was set up. Cloud Run functions uses Identity and Access Management (IAM) to evaluate permissions using roles. A role is a set of individual permissions that are grouped together and assigned to the account, either directly or through a policy configuration. 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 the documentation on Authorizing Access with IAM. To authorize identities to perform administrative actions like creating, updating, and deleting functions, you add principals or identities (a user or service account email) to the function with the appropriate IAM roles. Roles include permissions that define a set of allowed actions that can be performed on the function. The predefined roles that are supported by Cloud Run functions are: Cloud Functions Admin, Cloud Functions Developer, Cloud Functions Invoker, and Cloud Functions Viewer. You can authorize access to a function in the Google Cloud console or with the gcloud CLI. For a complete list of user roles and service accounts used with Cloud Run functions, see the access control with IAM documentation. For a list of permissions in each role, see the Cloud Functions IAM Roles documentation. Event-driven functions can only be invoked by the event source that they are subscribed to. HTTP functions can be invoked by different types of identities, for example, a developer who is testing the function, or a service that uses the function. These identities must provide an ID token with the appropriate permissions for authentication and authorization. When testing a function as a developer, you must have a user account to access Cloud Run functions with a role that contains the appropriate permissions on the function being invoked. Then, generate an ID token using this account, and pass the token in the Authorization header of the request to the function. Functions often need access to other resources in Google Cloud to do their work. Every function is associated with a service account that serves as its identity when the function accesses other resources. The service account that a function uses as its identity is known as its runtime service account. Cloud Run functions uses a default runtime service account for function identity: The Compute Engine Engine default service account, or the App Engine default service account for 1st generation. Use the default service account for testing and development purposes only. For production, specify a different individual runtime service account when deploying a function, and grant the runtime service account only the minimum set of permissions required to achieve its goal. When building services that connect multiple functions, ensure that each function can only send requests to a specific subset of your functions. To configure a receiving function to accept requests from a specific calling function, grant the Cloud Run Invoker (roles/run.invoker) role to the calling function's service account on the receiving function. For Cloud Run functions (1st generation), grant the Cloud Run functions Invoker role (roles/cloudfunctions.invoker). The calling function must also provide a Google-signed ID token for authentication, with the audience field (aud) set to the URL of the receiving function. The ID token must be sent in an Authorization header in the request to the function. To learn more about generating the token, view the documentation. You can also limit access by specifying network settings for Cloud Run functions. Network settings enable you to control network ingress and egress to and from individual functions. Ingress settings restrict whether a function can be invoked by resources outside of your Google Cloud project or VPC Service Controls service perimeter. You can choose to allow all traffic, allow internal traffic only, or allow internal traffic and traffic from Cloud Load Balancing. Internal traffic is traffic from Workflows and VPC networks in the same project or VPC Service Controls perimeter. Egress settings control the routing of outbound HTTP requests from a function. To specify egress settings, you must connect functions to a VPC network using a Serverless VPC Access connector. Egress settings control which types of traffic are routed through the connector to your VPC network. You can set egress settings to route all outbound traffic from the function through the connector, or, route only requests to private IPs through the connector. You can use VPC Service Controls with Cloud Run functions to add additional security to your functions. To do this, you create a service perimeter, and add one or more projects to the perimeter. For Shared VPCs, add the host and service projects to the perimeter. And restrict the Cloud Functions API by setting up organization policies that control the network settings for functions in the service perimeter. With the organization policies in place: HTTP functions will only accept traffic that orginates from a VPC network within the service perimeter. All functions must use a Serverless VPC Access connector. And functions must route all egress traffic through your VPC network. View the VPC Service Controls with Cloud Run functions documentation for more details.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.