Cloud Run allow unauthenticated: when is it acceptable?

Cloud Run services are deployed privately by default. Allow unauthenticated invocations only for endpoints that are meant to be reachable by anyone on the internet, such as a public website or a webhook that must accept requests without credentials. For internal services and developer access, keep IAM checks on.

The default is private

Google's documentation says all Cloud Run services are deployed privately by default, and requests must carry authentication credentials. Access is controlled by IAM. By default, only project owners, project editors, Cloud Run admins and Cloud Run invokers can call a service. You can give more users access through IAM, and, if your organization allows it, disable IAM checks on a service.

The page lists the common use cases: public access (allow unauthenticated invocations), developer access during development, service to service calls in a multi service application, and end user access from mobile or web clients.

Decide by caller

1. Anyone on the internet, no account. A public site or API. Allowing unauthenticated calls is the intended setting. Protect the code, because the platform will not check callers.
2. A third party webhook. Often cannot attach Google credentials. You may need to allow unauthenticated calls and verify the sender yourself, using a signature or shared secret in the request.
3. Another Cloud Run service you own. Keep it private and grant the calling service's identity the invoker role. The documentation links a service to service guide for the details.
4. Your own developers. Keep it private and grant individuals or groups access.
5. End users who sign in. Authenticate them, rather than opening the service wide.

What allowing unauthenticated access means

It means the IAM check is gone. Every protection from then on lives in your application: input validation, rate limits, authentication of users, abuse controls. Treat the service like any other public endpoint.

It also means cost exposure. Anything on the open internet can be called repeatedly, so consider limits on instance counts and budget alerts. Those settings are worth checking in the product documentation, since this page does not describe them.

Common mistakes

• Opening a service to the world during testing and never closing it.
• Making an internal service public because another team found IAM setup awkward.
• Assuming an obscure service URL protects the service.
• Believing that unauthenticated means unmonitored. Logs should still capture requests.

An audit routine

1. List services that allow unauthenticated invocation.
2. Mark each as intended public or not.
3. Close the ones that are not.
4. For intended public ones, review the code path, input handling and limits.
5. Repeat after large releases.

Quick check

Safeguard's dependency scanning, with its free scan, is useful for the public facing services you decide to keep open.

Sources

• Authenticating, Cloud Run documentation

Last reviewed: 19 October 2026.