How do you prevent Google Cloud Run services from being publicly accessible?

What “publicly accessible” means in Cloud Run

A Cloud Run service is publicly accessible when it can be invoked without an authenticated caller or when permissions allow broad invocation beyond the intended audience. In practice, the control point is not the URL alone, it is the service’s IAM policy and the identity path used to reach it. If unauthenticated access is enabled, anyone who can reach the endpoint can attempt requests.

Public exposure often happens through convenience settings during initial testing, through a later deployment that relaxes the policy, or when a team assumes network location alone will keep the service private. For a broader Google Cloud control baseline, see the Google Cloud Security Guide, which covers IAM, org policy, audit logging and related guardrails.

The key distinction is that “not listed in a browser” is not the same as private. A service can be effectively public if anonymous invocation is allowed, if a broad principal has invoker rights, or if downstream exposure paths let an unintended caller reach it through another trusted component.

How to remove public invocation

Prevent public access by requiring authentication for every request and by removing public invoker permissions from the service. Confirm that the service IAM policy does not grant broad invocation to all users or all authenticated users unless that is explicitly intended. For Cloud Run, the practical question is always: who can present a valid identity and who is authorized to invoke this service?

That identity path should be explicit and constrained. In many environments, the best pattern is to use private or identity-aware access paths rather than exposing the service directly. If the service is part of a larger serverless estate, the Serverless Security Guide is the most relevant companion for understanding execution roles, function URLs, secrets and serverless misconfiguration.

For teams standardising on service-to-service access, use short-lived, workload-bound credentials rather than relying on shared secrets or ad hoc exceptions. The Cloud Workload Identity Guide is useful when the real goal is controlled machine or service identity rather than public reachability.

When Cloud Run is used in a Google Cloud environment with multiple projects and services, the Google Cloud IAM and Service Accounts Guide helps frame the difference between a service account that can authenticate and a principal that is actually allowed to invoke a service.

What to verify after deployment changes

Do not treat a one-time fix as permanent. Recheck the service after every deployment, policy change, and infrastructure update, because configuration drift can reintroduce public access even when the intent was to keep the service private. The most useful verification is simple: test the service as an unauthenticated caller and confirm it is rejected.

Also verify that the IAM policy still matches the intended access model after any pipeline or platform automation runs. If the service depends on a managed identity path, confirm that the caller identity, role binding, and audience are all still aligned with the expected access pattern. Drift in any one of those layers can reopen the service unexpectedly.

At scale, the failure mode is usually not a single deliberate exposure, but repeated small changes that slowly widen invocation rights. Teams should therefore treat public access as a policy state to be continuously checked, not a one-time deployment decision.

Risk and Threat Considerations

Publicly accessible Cloud Run services expand the attack surface immediately, especially when the service exposes business logic, internal APIs, or sensitive data. The main risk is not just accidental use, but automated discovery, abuse, and unauthorized invocation once the endpoint is reachable without the intended identity controls.

Failure mechanism: A permissive invocation policy or drifted IAM binding allows anonymous or overbroad callers to reach the service, bypassing the intended authentication and authorization path. Once exposed, the service can be probed, scraped, rate-limited, or used as an entry point into downstream systems.

Impact: The result can include data exposure, unauthorized actions, cost growth, abuse of downstream dependencies, and a wider trust boundary than the team intended. In a serverless environment, the service itself may look small, but its permissions and integrations can make the blast radius much larger than the endpoint suggests.

Practitioner Guidance

What to verify: Check the deployed service policy, the effective invoker rights, and the actual runtime response for an unauthenticated request. The safest test is behavioral, not just declarative, because the effective access state is what matters.

Decision rule: If the service must be reachable outside a trusted path, require an authenticated caller and route access through the least-privilege identity path that matches the use case. If you cannot explain which identity is allowed to invoke it, the service is not sufficiently private.

Common mistake: Teams often assume that “internal by design” or “not linked anywhere” means private. In Cloud Run, privacy depends on authorization state, so every deployment should be treated as a fresh opportunity for access drift.

Practitioner takeaway: The goal is not merely to hide the endpoint, but to make invocation dependent on an explicit identity and a policy that stays correct after every change.

Related resources from NHI Mgmt Group

• How do you prevent a GKE control plane from being publicly accessible?
• How do you prevent Amazon RDS databases from being publicly accessible?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams run access reviews for non-human identities?