Cloud Run and Cloud Functions Security Guide: Service Identity, Ingress and Invoker IAM

A Cloud Run service or Cloud Run function deployed with defaults runs as the Compute Engine default service account, which in many older projects still holds the Editor role, so any code execution bug in the service becomes project-wide write access. Combine that with ingress set to all and a public invoker setting, and a single vulnerable endpoint is both internet-facing and over-privileged. This guide covers Cloud Run services, jobs and functions (including functions deployed through the Cloud Functions v2 API, which run on Cloud Run): service identity, the deployer's actAs escalation path, invoker IAM and public access, ingress and egress, secrets, Binary Authorization, logging and the organisation policies that make secure settings the default. It is for platform engineers, application security engineers and cloud security reviewers. For serverless principles across providers, read the Serverless Security Guide first.

Key takeaways

• Never run on the default compute service account. Give each service its own user-managed service account with only the roles it needs, and enforce iam.automaticIamGrantsForDefaultServiceAccounts so default accounts stop receiving Editor.
• Deploy rights plus actAs equals the service's privileges. Anyone who can deploy a revision and act as the service account can run code with that account's roles, so roles/iam.serviceAccountUser on a powerful service account is a privilege escalation path.
• Ingress and invoker IAM are separate gates. Ingress decides which networks can reach the service; roles/run.invoker decides which identities can call it. Internal services want internal or internal-and-cloud-load-balancing plus authenticated invokers.
• Public access is a deliberate exception. Disabling the Invoker IAM check makes a service public even where domain restricted sharing blocks allUsers, so govern who can set it.
• Secrets come from Secret Manager, not images or plain variables. Mount as volumes for rotation, or pin versions in environment variables, and grant roles/secretmanager.secretAccessor per secret to the service identity.

How identity and access work in Cloud Run and Cloud Functions

Three identities matter for every service: who deploys it, what it runs as, and who may call it.

Why the default service account is the classic escalation

• Editor by default: depending on organisation policy, the Compute Engine default service account may hold Editor on the project. Organisations created after 3 May 2024 enforce iam.automaticIamGrantsForDefaultServiceAccounts by default, but older organisations and projects often do not.
• Token on demand: the code obtains access tokens from http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token with the Metadata-Flavor: Google header. A server-side request forgery or remote code execution flaw therefore yields a cloud credential (ATT&CK T1552.005 Cloud Instance Metadata API, then T1078.004 Cloud Accounts).
• Shared blast radius: every service and function on the default account shares one identity, so you cannot tell from audit logs which service made a call, and you cannot reduce one service's rights without affecting the others.
• Do not set key files: Google warns against setting GOOGLE_APPLICATION_CREDENTIALS on a service that uses its service identity. A key file in the container is a portable credential. See the Google Cloud Service Account Keys Security Guide.

Admin roles and privileged access

• Grant actAs on the account, not the project: project-level Service Account User lets a deployer attach any service account in the project, including highly privileged ones. Grant it only on the specific runtime account each pipeline deploys. See the Google Cloud IAM and Service Accounts Guide.
• Treat the CI identity as production admin: a pipeline with Developer plus actAs can deploy any code as the runtime identity (ATT&CK T1648 Serverless Execution). Federate it with workload identity federation rather than a key, and protect the pipeline definition.
• Remove Editor and Owner from humans in production projects: both include Cloud Run deploy rights. Use read-only roles plus break-glass.
• Replace Editor on default accounts with care: Google suggests using Policy Simulator before removing Editor so you can see which workloads depend on it.

Integrations, API tokens and service accounts

Invoker IAM and public access

• Authenticated by default: callers need run.routes.invoke and must present an OIDC ID token. Service-to-service calls get an ID token from the metadata server's /identity?audience=AUDIENCE endpoint with the receiving service URL as audience.
• Two ways to go public: Google now recommends disabling the Invoker IAM check (gcloud run services update SERVICE --no-invoker-iam-check) over granting roles/run.invoker to allUsers. allUsers can only be bound per service, never at project level.
• Domain restricted sharing does not stop it: if an organisation policy blocks allUsers bindings, Google points users to disabling the Invoker IAM check instead, so the domain restriction is not a control against public services on its own. Restrict who holds run.services.update on production and detect services with the check disabled.
• Public behind a gate: for user-facing internal apps, keep invoker IAM on and put Identity-Aware Proxy in front, either directly on the service or on a load balancer. See the Identity-Aware Proxy Guide.

Ingress and egress

• Disable the default URL with --no-default-url when a load balancer or domain mapping is the only intended entry point. This breaks integrations that call run.app, including Pub/Sub push, Cloud Scheduler, Eventarc, Workflows and the cloudfunctions.net URL for Cloud Functions v2, so test first.
• Constrain choices: the run.allowedIngress organisation policy limits which ingress settings developers can choose, and the Allowed VPC egress settings constraint can force all egress through the VPC.
• Egress through the VPC: with Direct VPC egress or a Serverless VPC Access connector and all traffic routed to the VPC, you can apply firewall rules and VPC Flow Logs to outbound traffic and stop functions calling arbitrary internet hosts. See the Google Cloud VPC and Cloud NGFW Security Guide.
• Perimeters: include Cloud Run as a restricted service in VPC Service Controls so internal ingress honours the perimeter. See the VPC Service Controls Guide.

Secrets

• Volumes: each read fetches the current value of the referenced version, so latest works for rotation without redeploying; access failures appear at read time.
• Environment variables: resolved at instance start; pin to a version number and redeploy on rotation. A failed lookup stops the instance starting.
• Grants: the service identity needs roles/secretmanager.secretAccessor on each secret, and the deployer needs Cloud Run Admin and Service Account User. Do not grant Secret Accessor at project level.
• Mount paths: avoid /dev, /proc and /sys, and mount into a new subdirectory.

Supply chain

Enable Binary Authorization on services and jobs (--binary-authorization=default) and require it through organisation policy, because developers can otherwise turn it off. The built-by-cloud-build attestor limits deployments to images built by Cloud Build; breakglass deployments are possible but each creates an audit log entry. A non-compliant revision fails while the service keeps serving the last healthy one. This addresses ATT&CK T1525 Implant Internal Image and T1195.002 Compromise Software Supply Chain. See the Container Image Security Guide.

Logging and detection

Dedicated service accounts make the last row usable: with one identity per service, a sudden IAM write from orders-api@ is unambiguous. Route these logs centrally. See the Google Cloud Audit Logs and Log Sinks Guide.

Metrics that show it is working

• Dedicated identities: percentage of services and functions not running as a default service account (target 100 percent in production).
• Default account privilege: number of projects where the Compute Engine default service account still holds Editor (target zero).
• Public exposure: services with ingress all or invoker check disabled, each with a recorded exception.
• Secret hygiene: services with secrets in plain environment variables or unpinned env secret versions (target zero).
• Supply chain: percentage of production services with Binary Authorization enforced, and breakglass uses per quarter.

Hardening baseline

Phased rollout

1. Inventory: list every service, job and function with its service account, ingress, invoker setting and secret references, using Cloud Asset Inventory or gcloud run services list per region.
2. Create identities: one service account per service, granted the roles observed in its audit logs (Policy Intelligence role recommendations help here).
3. Switch identity per revision: deploy a new revision with --service-account, send a small share of traffic, check for permission errors, then move all traffic. Rolling back is a traffic shift to the previous revision.
4. Remove Editor from the default account: after nothing uses it, using Policy Simulator first; enforce the automatic grants constraint for new projects.
5. Tighten ingress and invoker: move internal services to internal, put public ones behind a load balancer with Cloud Armor or IAP, then disable the default URL where safe.
6. Enforce supply chain and organisation policies: Binary Authorization in dry run, then enforce; apply ingress and egress constraints at folder level.

Decision guidance

• Cloud Functions API vs Cloud Run deploy: Google suggests moving to functions in Cloud Run. Either way the same service identity, ingress and invoker controls apply, because v2 functions are Cloud Run services.
• Disable invoker check vs allUsers: follow Google's recommendation to disable the check for genuinely public services, but record each as an exception and detect it, because it bypasses domain restricted sharing.
• Volumes vs environment variables for secrets: volumes for credentials that rotate often; pinned environment variables for values that must exist at start-up.
• Small vs large estates: a small team can create service accounts by hand and review quarterly; large estates should generate them per service in infrastructure as code and block deploys without --service-account.

Framework mapping

Common misconfigurations

• Default service account with Editor: one injection flaw in any function gives an attacker project-wide write access through the metadata server token.
• Project-level Service Account User for CI: the pipeline can attach any service account, including one with Owner, to a new revision.
• Load balancer in front, run.app still open: Cloud Armor and IAP protect the load balancer path while the default URL accepts direct internet traffic.
• Public by invoker check: a developer disables the Invoker IAM check to "fix" a 403 and the organisation's allUsers restriction never fires.
• Secrets in plain environment variables: values set directly in the service configuration are visible to anyone with view access to the service, unlike Secret Manager references.
• Build account forgotten: function source deploys build as the Compute Engine default account in newer projects or the legacy Cloud Build account in older ones, both often broader than needed.

Practitioner checklist

• Enforce iam.automaticIamGrantsForDefaultServiceAccounts and remove Editor from existing default service accounts.
• Deploy every service, job and function with a dedicated user-managed service account.
• Grant Service Account User only on specific runtime accounts to specific CI identities.
• Set a user-specified build service account for source and function deployments.
• Use internal or internal-and-cloud-load-balancing ingress and constrain it with run.allowedIngress.
• Keep the Invoker IAM check on; record and alert on every public service.
• Disable the run.app URL where a load balancer is the entry point, after testing integrations.
• Reference secrets from Secret Manager as volumes or pinned versions with per-secret grants.
• Enforce Binary Authorization and require it by organisation policy.
• Alert on revision deploys outside CI, service account changes and public IAM bindings.

Standards and references

• Google Cloud: Introduction to service identity (Cloud Run)
• Google Cloud: Restrict network ingress for Cloud Run
• Google Cloud: Access control with IAM (Cloud Run)
• Google Cloud: Cloud Run security design overview
• Google Cloud: Configure secrets for services
• Google Cloud: Use Binary Authorization with Cloud Run
• Google Cloud: Cloud Build service account change
• Google Cloud: Function identity

Related NHI Mgmt Group resources: Serverless Security Guide · Google Cloud IAM and Service Accounts Guide · Workload Identity Federation Guide · Identity-Aware Proxy Guide · Google Cloud Security Guide