Runway uses Cloudflare Authenticated Origin Pulls (AOP) with mutual TLS (mTLS) to ensure all traffic to your Kubernetes applications flows through Cloudflare’s security controls. This prevents direct origin access attacks and ensures that WAF rules, rate limiting, and other security features cannot be bypassed.

When a user requests your application, the request flows through multiple validation layers:

1. User → Cloudflare: The request reaches Cloudflare’s edge network
2. Cloudflare → Your Origin: Cloudflare presents a client certificate signed by Runway’s certificate authority
3. Load Balancer Validation: Your cloud load balancer validates the certificate against the trusted CA
4. Application Access: Only requests with valid certificates reach your application pods

┌─────────────┐
│   Internet  │
│   Users     │
└──────┬──────┘
       │ HTTPS
       ▼
┌──────────────────┐
│   Cloudflare     │
│   Edge Network   │
└──────┬───────────┘
       │ HTTPS + mTLS
       │ (client cert)
       ▼
┌──────────────────────────┐
│  Cloud Load Balancer     │
│  (validates cert)        │
└──────┬───────────────────┘
       │ (only if valid)
       ▼
┌──────────────────────────┐
│  Your Application Pods   │
└──────────────────────────┘

Runway automatically manages the complete certificate lifecycle using HashiCorp Vault:

Root CA (20 years)
  └─ Intermediate CA (10 years)
      └─ Client Certificates (90 days, auto-rotated)

• Root CA: Stored securely in Vault, signs the intermediate CA
• Intermediate CA: Stored in Vault, issues client certificates for Cloudflare
• Client Certificates: Short-lived (90 days), automatically rotated before expiration

Client certificates are automatically rotated every 90 days with zero downtime. Runway detects expiring certificates, issues new ones from Vault, uploads them to Cloudflare, and your load balancers continue validating against the same intermediate CA without requiring any manual intervention.

AOP is enabled by default for all external facing workloads. To explicitly configure it, add the following to your workload in the inventory file located at config/runtimes/[eks|gke]/workloads.yml:

- runway_service_id: my-service
  project_id: 12345
  cloudflare:
    enabled: true

To disable AOP, set enabled: false for your workload. Then add the following to your service configuration in .runway/${RUNWAY_SERVICE_ID}/default-values.yaml located in your service repository:

spec:
  load_balancing:
    cloudflare: false

For GKE services, contact the Runway team in #g_runway when enabling AOP. The GCP Gateway API currently lacks native mTLS support, so Runway performs additional configuration steps to ensure certificate validation. GCP has indicated native mTLS support will be available in H2 2026. See issue #713 for details.

Runway implements mTLS validation differently depending on your cloud provider, but both use the same certificate hierarchy and validation logic.

• Trust Store: Stores the Intermediate CA certificate
• Ingress Annotations: Configure mTLS validation on ingress resources
• Validation: AWS Application Load Balancer (ALB) validates all incoming client certificates

• Trust Config: Stores the Intermediate CA certificate
• Server TLS Policy: Configures mTLS validation on Cloud Load Balancer Target HTTPS Proxy
• Validation: GCP Cloud Load Balancer validates all incoming client certificates

Runway provides observability for mTLS validation:

• Certificate Expiration Tracking: Monitor and alert when certificates are approaching rotation
• Validation Metrics: Track and alerts based on HTTP 525(TLS Handshake) error rates

Contact the Runway team in #g_runway if you notice any certificate-related issues or validation failures.

For questions about mTLS, certificate rotation, or security configuration, reach out to the Runway team in #g_runway.

In addition to mTLS validation, Runway provides IP filtering capabilities to restrict inbound traffic to your Kubernetes workloads exclusively from Cloudflare’s IP ranges. This adds an extra layer of security by preventing direct access to your origin.

When IP filtering is enabled, Runway will:

1. Allow traffic only from Cloudflare IP ranges: Ingress traffic is restricted to Cloudflare’s published IP address ranges
2. Block all other traffic: Any requests from non-Cloudflare sources are blocked

The filtering is implemented at the edge layer (loadbalancer) using Cloud Armor policies in GKE and Security Groups in EKS.

IP filtering is enabled by default for workloads with external loadbalancer setting. To disable it, add the following to your .runway/${RUNWAY_SERVICE_ID}/default-values.yaml file located in your service repository (the same way you can disable AOP):

spec:
  load_balancing:
    cloudflare: false

For maximum security, Runway recommends enabling both mTLS and IP filtering (both are enabled by default).

This creates a defense-in-depth strategy:

1. Network Layer: IP filtering blocks non-Cloudflare traffic at the loadbalancer layer
2. TLS Layer: mTLS validates that traffic comes from Cloudflare with a valid certificate and only from Runway’s account
3. Application Layer: Your application receives only validated, authenticated requests