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.

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:

When you configure a Cloud Run service to require authentication, you must explicitly grant permissions to users and service accounts that need to invoke it. Cloud Run uses Identity and Access Management (IAM) to control access, with the roles/run.invoker role being the key permission for calling a service.

The IAM model for Cloud Run is straightforward: who (the member) can do what (the role) on which resource (the service). Members can be user accounts, service accounts, Google Groups, or domains. The role for invoking services is always roles/run.invoker. The resource is your specific Cloud Run service.

To grant a specific user permission to invoke your service:

This command adds an IAM policy binding that allows developer@example.com to invoke the my-web-app service. The user can now call the service by including their Google Cloud credentials in the request. Common tools like curl with gcloud auth print-identity-token or client libraries with Application Default Credentials automatically handle this authentication.

You can also grant access to service accounts, which is essential for service-to-service communication:

This allows the specified service account to invoke your service. This is common when one Cloud Run service needs to call another, or when Cloud Scheduler, Cloud Tasks, or Pub/Sub needs to trigger your service.

For broader access within your organization, you can grant permissions to entire Google Groups or domains:

Beyond authentication, Cloud Run provides ingress settings that control which networks can reach your service. While authentication determines who can invoke your service, ingress settings determine where requests can originate from. This provides an additional layer of security for services that should only be accessible from specific network contexts.

Cloud Run supports three ingress settings:

1. All traffic (all) - The default setting. Your service accepts requests from the public internet, your VPC network, and other Google Cloud services. This is the most permissive setting and appropriate for public-facing services.

2. Internal traffic only (internal) - Your service only accepts requests from other services in your Google Cloud project, VPC networks connected via VPC Service Controls, and Cloud Load Balancer. Requests from the public internet are rejected. This is ideal for backend services that should never be directly exposed to external users.

3. Internal and Cloud Load Balancing (internal-and-cloud-load-balancing) - Similar to internal traffic only, but also accepts traffic from Google Cloud Load Balancer. This is useful when you want to use a load balancer to provide a custom domain or apply advanced routing rules while still restricting direct access.

To configure ingress settings when deploying a new service:

This creates a service that's only accessible from within your Google Cloud project and VPC networks. External requests are rejected at the network level before reaching your application.

To update the ingress setting on an existing service:

You can verify the current ingress setting by describing your service:

By default, Cloud Run assigns your service a URL like https://SERVICE-NAME-HASH-REGION.a.run.app. While functional, these URLs aren't suitable for production applications where you need branded, memorable URLs like https://api.example.com or https://app.example.com. Cloud Run supports custom domain mapping to associate your services with domains you own.

Prerequisites for Domain Mapping

Before mapping a custom domain, you must:

1. Own the domain - You must have registered the domain through a domain registrar like Google Domains, GoDaddy, or Namecheap.
2. Verify domain ownership - You must verify that you control the domain in Google Cloud Console. This typically involves adding a TXT record to your domain's DNS configuration.
3. Have DNS access - You need the ability to add DNS records (A, AAAA, or CNAME) to your domain's configuration.

Creating a Domain Mapping

Once you've verified domain ownership in the Google Cloud Console, you can map a domain to your Cloud Run service using the gcloud run domain-mappings create command:

This command initiates the domain mapping process. Cloud Run returns DNS records that you must add to your domain's DNS configuration:

You've now mastered the essential security and networking configurations for Cloud Run services in production environments. You learned how to control access through authentication modes, configure granular permissions using IAM policy bindings, restrict network access with ingress settings, and provide professional URLs through custom domain mapping.

These capabilities transform Cloud Run from a simple deployment platform into a production-ready environment. By combining authentication, IAM policies, and network controls, you create defense-in-depth security that protects your services at multiple layers. Custom domains complete the picture, giving your services the professional appearance and memorability that users expect.

In the next unit, you'll explore logging, monitoring, and debugging—the operational skills you need to maintain and troubleshoot these secured services in production. You'll learn how to use Cloud Logging to diagnose issues, Cloud Monitoring to track performance, and systematic debugging approaches to resolve problems quickly when they arise.