# Cloud Run Authentication and Security Patterns: A Complete Implementation Guide

> Master Cloud Run authentication and security patterns with this implementation guide. Learn about IAM, network controls, and app hardening for robust serverless protection.

- Repository: [Google/skills](https://github.com/google/skills)
- Tags: how-to-guide
- Published: 2026-08-13

---

**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`](https://github.com/google/skills/blob/main/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`](https://github.com/google/skills/blob/main/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`](https://github.com/google/skills/blob/main/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`](https://github.com/google/skills/blob/main/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`](https://github.com/google/skills/blob/main/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

```bash
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

```bash
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

```bash
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

```bash
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`](https://github.com/google/skills/blob/main/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.