Securing and Networking Cloud Run Services
Introduction: From Deployment to Production Security
In Unit 3, you successfully deployed Cloud Run services and learned the fundamentals of service lifecycle management—deploying with gcloud run deploy, viewing configurations with gcloud run services describe, managing revisions, and cleaning up with gcloud run services delete. If you need a refresher on these basic operations, please review Unit 3's "Deploying Cloud Run Services" lesson.
This lesson focuses on securing and networking your Cloud Run services for production use. While Unit 3 covered how to deploy services, this lesson covers how to secure them through authentication controls, how to grant access using IAM policies, and how to make them accessible via custom domains. These are critical skills for operating Cloud Run services in real-world environments where security, access control, and professional URLs are essential requirements.
By the end of this lesson, you'll understand Cloud Run's authentication modes, how to configure IAM policies to control who can invoke your services, how to configure network ingress settings, and how to map custom domains to give your services professional URLs instead of the default *.run.app endpoints.
Understanding Cloud Run Authentication Modes
Cloud Run provides two fundamental authentication modes that control who can access your services: unauthenticated (public) access and authenticated (private) access. This choice determines whether anyone on the internet can call your service or whether callers must provide valid Google Cloud credentials.
When you deploy a service with --allow-unauthenticated, you're creating a public endpoint that anyone can access without credentials. This is appropriate for public-facing web applications, marketing websites, or APIs that need to be accessible to external users. The service URL is publicly accessible, and Cloud Run accepts all incoming requests without verifying the caller's identity.
Conversely, when you deploy with --no-allow-unauthenticated or omit the authentication flag entirely, you're creating a private endpoint that requires authentication. Only callers with valid Google Cloud credentials and appropriate IAM permissions can invoke the service. This is essential for internal APIs, backend services, or any application that should only be accessible to authorized users and service accounts.
The key difference is in the default IAM policy. Public services have allUsers granted the roles/run.invoker role, while private services have no default invokers—you must explicitly grant access through IAM policies.
Changing Authentication Mode on Existing Services
You can modify the authentication mode of an existing service without redeploying it. This is useful when you need to quickly restrict access to a service that was initially public or open up a private service for testing.
To restrict a public service to require authentication:
This command updates the service's IAM policy to remove the allUsers binding, immediately requiring authentication for all new requests. Existing connections are not affected, but subsequent requests will fail unless the caller provides valid credentials.
To make a private service publicly accessible:
This grants the roles/run.invoker role to allUsers, making the service publicly accessible. Use this cautiously, as it exposes your service to the entire internet.
Understanding when to use each authentication mode is crucial for Cloud Run security. Public services are convenient but require additional application-level security measures like API keys or OAuth. Private services provide strong authentication by default but require you to manage IAM policies carefully to grant access to legitimate callers.
