Cloud Functions can be invoked by anyone with the cloudfunctions.functions.invoke permission by default, but you can restrict this using IAM.
Let’s see it in action. Imagine a hello_world function that we want to be callable only by specific users and service accounts.
# IAM policy for the hello_world Cloud Function
bindings:
- members:
- serviceAccount:invoker-service-account@your-project-id.iam.gserviceaccount.com
- user:authorized-user@example.com
role: roles/cloudfunctions.invoker
This YAML snippet defines an IAM policy. The bindings section lists who gets what. Here, members specifies two entities: a service account and a user. The role: roles/cloudfunctions.invoker grants them the explicit permission to invoke this particular function. When these entities try to call the function, Cloud Functions will check their IAM permissions for that function, and if they have the invoker role, the invocation succeeds. If anyone else tries, even if they have broad project-level permissions, the invocation will be denied because they lack the specific cloudfunctions.functions.invoke permission on this function.
This capability is crucial for securing sensitive operations or data exposed via Cloud Functions. Instead of relying on less granular network-level controls or embedding authentication logic within the function itself (which is error-prone and harder to manage), IAM provides a centralized, declarative way to manage access.
The core mechanism is the IAM policy attached to the Cloud Function resource itself. When an invocation request arrives, the Cloud Functions backend consults this policy. It checks if the identity making the request (whether a user’s credentials or a service account’s identity) is listed in any binding that grants the roles/cloudfunctions.invoker role for that specific function.
Here’s how you’d apply this policy using gcloud:
First, ensure you have a policy file, let’s call it policy.yaml:
bindings:
- members:
- serviceAccount:invoker-service-account@your-project-id.iam.gserviceaccount.com
- user:authorized-user@example.com
role: roles/cloudfunctions.invoker
Then, deploy it:
gcloud functions add-iam-policy-binding hello_world \
--member='serviceAccount:invoker-service-account@your-project-id.iam.gserviceaccount.com' \
--role='roles/cloudfunctions.invoker' \
--project=your-project-id
gcloud functions add-iam-policy-binding hello_world \
--member='user:authorized-user@example.com' \
--role='roles/cloudfunctions.invoker' \
--project=your-project-id
Alternatively, you can manage the entire policy at once:
gcloud functions set-iam-policy hello_world policy.yaml --project=your-project-id
The roles/cloudfunctions.invoker role is a predefined role specifically designed for this purpose. It grants only the cloudfunctions.functions.invoke permission. If you need more granular control, you could create a custom IAM role that includes this permission along with others, but for simple invocation control, the predefined role is sufficient and recommended.
You can also remove permissions. For example, to revoke access for a service account:
gcloud functions remove-iam-policy-binding hello_world \
--member='serviceAccount:revoked-service-account@your-project-id.iam.gserviceaccount.com' \
--role='roles/cloudfunctions.invoker' \
--project=your-project-id
The most surprising thing is that even if a user has the iam.serviceAccounts.getAccessToken permission on a service account that is not explicitly listed in the function’s IAM policy, they still cannot invoke the function if their own principal (the user identity) isn’t authorized. The invocation check happens at the function level, not just at the service account level. The identity making the call is what matters, and that identity must be explicitly granted the invoker role for that specific function.
You might hit issues with older functions that were deployed before IAM policies were granularly applied. In such cases, you might find that broader project-level permissions accidentally granted invocation rights, and you’ll need to audit and tighten those down.
The next step is to consider how to manage authentication within your function, especially if it needs to access other Google Cloud services.