Cloud Run Authentication and Security Patterns: A Complete Implementation Guide

TLDR: Cloud Run authentication and security patterns rely on a three-layer model combining IAM policies, ingress/egress network controls, and application-level hardening to protect serverless container workloads.

Cloud Run authentication and security patterns form the foundation for securing production workloads on Google Cloud's fully-managed serverless container platform. According to the google/skills repository, implementing defense-in-depth requires configuring identity management, network boundaries, and runtime protections across multiple configuration layers defined in skills/cloud/cloud-run-basics/references/iam-security.md and related networking documentation.

IAM and Service Identity Management

Identity and Access Management represents the first line of defense for Cloud Run resources, controlling who can deploy, modify, or invoke services.

Predefined IAM Roles

According to skills/cloud/cloud-run-basics/references/iam-security.md, Google Cloud provides four primary predefined roles for Cloud Run access control:

• roles/run.admin – Full control over Cloud Run resources including IAM policy management
• roles/run.invoker – Permission to invoke services without administrative access
• roles/run.developer – Read and write access to services excluding IAM policy modifications
• roles/run.viewer – Read-only access for monitoring and auditing

Service Account Strategy

Every Cloud Run revision executes under a service account that determines its runtime permissions. The source code analysis distinguishes between two approaches:

User-managed service accounts (recommended): Create dedicated service accounts per service with minimal required permissions. For example, grant only roles/cloudsql.client for Cloud SQL connectivity rather than broad project-level access.

Compute Engine default service account: Automatically attached when no service account is specified, often possessing excessive Editor permissions. Disable automatic grants via the iam.automaticIamGrantsForDefaultServiceAccounts organization policy to enforce least-privilege deployment.

Network Security Controls

Traffic management in Cloud Run implements zero-trust networking through explicit ingress restrictions and controlled egress pathways.

Ingress Restriction Patterns

The skills/cloud/cloud-run-basics/references/networking.md file documents three ingress configurations that determine service accessibility:

• all – Permits public internet access (default configuration)
• internal – Restricts access to VPC resources only, suitable for internal microservices
• internal-and-cloud-load-balancing – Requires traffic to traverse an external HTTP(S) Load Balancer, enabling Cloud Armor WAF integration and preventing direct *.run.app domain bypass attacks

Setting ingress to internal-and-cloud-load-balancing eliminates the "critical ingress bypass gotcha" identified in skills/cloud/google-cloud-solution-n-tier-serverless-web-app/SKILL.md, where attackers might otherwise access services directly via the default URL.

VPC Egress Architecture

Cloud Run supports two methods for private resource communication:

Direct VPC egress: The modern implementation scales to zero instances, eliminates connector overhead, and delivers higher throughput compared to traditional methods. Configure with --vpc-egress=all-traffic during deployment.

Serverless VPC Access connector: The classic approach maintains always-on connector instances incurring continuous costs regardless of traffic volume.

When implementing Direct VPC egress, enable Private Google Access and configure DNS to resolve Google API endpoints (*.run.app) to private VIPs (199.36.153.4/30, 199.36.153.8/30). This ensures Cloud Run services reach Google APIs like sqladmin.googleapis.com without traversing the public internet, a requirement for Cloud SQL IAM authentication.

Application-Level Security Hardening

Runtime security extends beyond network boundaries into container configuration and supply chain verification.

Container Provenance and Secrets

According to skills/cloud/cloud-run-basics/references/iam-security.md, implement these controls:

• Binary Authorization: Enforce deployment of only cryptographically signed container images from trusted repositories
• Secret Manager integration: Inject sensitive data via environment variables or mounted volumes rather than hardcoding credentials
• Vulnerability scanning: Activate Artifact Registry scanning combined with minimal base images (Alpine or scratch) and non-root user execution
• Image immutability: Pin deployments to specific image digests rather than mutable tags

End-User Authentication with IAP

Identity-Aware Proxy (IAP) provides an authentication layer for Cloud Run services regardless of ingress configuration. When enabled via --add-cloudrun-iap, IAP intercepts requests to validate Google Workspace or Cloud Identity credentials before forwarding traffic to the container.

This mechanism supports both public and private ingress settings, allowing fine-grained access control based on user identity or group membership through the roles/iap.httpsResourceAccessor role.

Production Deployment Pattern

The google/skills repository documents a five-step hardened deployment workflow:

1. Provision dedicated service accounts with minimal required IAM bindings
2. Deploy with authentication required using --no-allow-unauthenticated to block anonymous access
3. Enable IAP to enforce user-based access controls
4. Restrict ingress to internal-and-cloud-load-balancing and attach external HTTP(S) Load Balancers with optional Cloud Armor policies
5. Configure Direct VPC egress with --vpc-egress=all-traffic and verify Private Google Access for internal API communication

This configuration ensures all traffic flows through authorized pathways with comprehensive audit logging and prevents direct endpoint exposure.

Implementation Examples

Creating Minimal Service Accounts

gcloud iam service-accounts create my-cloudrun-sa \
    --display-name="Cloud Run SA for my-service"

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:my-cloudrun-sa@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudsql.client"

Deploying with Security Constraints

gcloud run deploy my-service \
    --region us-central1 \
    --image=gcr.io/$PROJECT_ID/my-image:latest \
    --service-account=my-cloudrun-sa@$PROJECT_ID.iam.gserviceaccount.com \
    --no-allow-unauthenticated \
    --ingress internal-and-cloud-load-balancing \
    --vpc-egress=all-traffic

Enabling Identity-Aware Proxy

gcloud run services update my-service \
    --region us-central1 \
    --ingress internal-and-cloud-load-balancing \
    --add-cloudrun-iap

gcloud iap web add-iam-policy-binding \
    --resource-type=run.googleapis.com \
    --service=my-service \
    --member='user:alice@example.com' \
    --role='roles/iap.httpsResourceAccessor'

Configuring Direct VPC Access

gcloud compute networks vpc-access connectors create my-connector \
    --region us-central1 \
    --network default \
    --range 10.8.0.0/28

gcloud run deploy my-service \
    --region us-central1 \
    --image=gcr.io/$PROJECT_ID/my-image:latest \
    --vpc-egress=all-traffic \
    --vpc-connector=my-connector

Summary

• Cloud Run authentication and security patterns implement defense-in-depth through IAM controls, network segmentation, and runtime hardening
• User-managed service accounts with minimal permissions eliminate the risks associated with default Compute Engine service accounts
• Ingress restrictions (internal-and-cloud-load-balancing) combined with external load balancers prevent direct URL bypass attacks
• Direct VPC egress provides scalable private connectivity without the operational overhead of persistent connector instances
• Identity-Aware Proxy enables fine-grained user authentication regardless of network ingress configuration

Frequently Asked Questions

What are the predefined IAM roles for Cloud Run?

Cloud Run provides four primary IAM roles defined in skills/cloud/cloud-run-basics/references/iam-security.md: roles/run.admin for full control, roles/run.invoker for execution-only access, roles/run.developer for service management without IAM changes, and roles/run.viewer for read-only auditing. Assign these according to the principle of least privilege.

How do I prevent public access to a Cloud Run service?

Deploy services with the --no-allow-unauthenticated flag to require authentication for all requests. For additional protection, set --ingress internal or --ingress internal-and-cloud-load-balancing to block direct internet access, routing traffic exclusively through VPC resources or authorized load balancers.

What is the difference between Direct VPC egress and Serverless VPC Access connectors?

Direct VPC egress (configured via --vpc-egress=all-traffic) scales to zero instances, incurs no connector maintenance costs, and provides higher throughput. Serverless VPC Access connectors maintain always-on instances regardless of traffic volume, resulting in continuous operational costs. Direct VPC egress requires Private Google Access configuration for internal API resolution to endpoints like 199.36.153.4/30.

How does Identity-Aware Proxy work with Cloud Run?

IAP sits in front of Cloud Run services to enforce Google Account or Cloud Identity authentication before requests reach your container. Enable it with --add-cloudrun-iap during service updates, then bind specific users or groups to the roles/iap.httpsResourceAccessor role. IAP functions with both public and private ingress settings, providing an additional authentication layer beyond network controls.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}