Cloudflare Zero Trust for every tenant

Direct answer

Cloudflare Tunnel creates an outbound-only connection from a Kubernetes environment to Cloudflare, so an origin does not need a publicly routable IP. Cloudflare Access then decides which users, devices, or services can reach an application. OpenTenant automates the tenant-specific layer: hostname, route, access profile, connector secret reference, release binding, and lifecycle are compiled from the same tenant declaration.

“Deployed for every tenant” should not mean one hand-configured tunnel process per customer. It should mean every tenant receives an explicit, reviewable edge configuration with no shared hostname or accidental policy inheritance.

What Cloudflare Tunnel changes

Cloudflare describes Tunnel as a connection initiated by the cloudflared daemon from the origin to Cloudflare's global network. Because the connector establishes the connection outbound, the origin can avoid a publicly routable IP and block general inbound traffic. See How Cloudflare Tunnel works.

For Kubernetes, this changes the common ingress model. Instead of exposing a public load balancer and allowing the Internet to reach it, cloudflared can route an approved hostname to a cluster-local service.

user or service
  → Cloudflare edge
  → Access policy evaluation
  → outbound-established Tunnel
  → cloudflared deployment
  → tenant Kubernetes service

The origin still needs normal application security. Tunnel removes direct public origin exposure; it does not make an unsafe service safe.

Kubernetes connector architecture

Cloudflare's Kubernetes deployment guide recommends running cloudflared as a deployment adjacent to application deployments. Keeping it separate allows connector replicas and application replicas to be managed independently.

Cloudflare's example uses two connector replicas on the same remotely managed tunnel for high availability. It stores the tunnel token in a Kubernetes Secret and reads it through the TUNNEL_TOKEN environment variable.

Two caveats matter for platform teams:

• Connector replicas provide availability, not application load balancing.
• Cloudflare warns against autoscaling cloudflared because downscaling removes connectors and breaks connections assigned to those replicas.

OpenTenant should therefore treat the connector plane as controlled infrastructure. Tenant workloads may share a hardened connector deployment while retaining distinct hostnames, services, routes, and policies. A deployment profile can choose dedicated connectors when a stronger operational boundary is required.

Access policies and service authentication

A Tunnel route answers where traffic goes. An Access policy answers who or what may use it.

Cloudflare Access policies can evaluate identity, group membership, device posture, network context, and service credentials. For machine-to-machine traffic, Cloudflare's Access policy documentation describes Service Auth, including service tokens and mutual TLS.

Cloudflare also warns that Bypass does not enforce Access controls and does not log requests through Access. It should not become a permanent shortcut for internal services. If a service should remain non-interactive while retaining authentication and logs, Service Auth is the more appropriate model.

For a tenant platform, policy should be selected by workload type:

• Public application: no user login at the edge, but the origin remains reachable only through the tunnel and normal WAF/rate controls can apply.
• Tenant admin: require the approved identity provider, tenant group, and optionally device posture.
• Service endpoint: use Service Auth with a tenant-scoped service token or mutual TLS.
• Operator access: use a separate administrative hostname and a stricter policy than customer traffic.

What “per tenant” should mean

Per-tenant Zero Trust is a data-model decision before it is a deployment decision. Each tenant needs explicit state for:

• Public and administrative hostnames
• Target Kubernetes service and port
• Access application or policy profile
• Allowed identity group or organization
• Service credentials, when needed
• Session and posture requirements
• Enabled or suspended state
• DNS, certificate, and route ownership

A single wildcard DNS record can simplify domain operations, but it must not collapse authorization. The requested hostname should resolve to exactly one tenant route, and administrative policies should not be inferred from naming conventions alone.

How OpenTenant automates the edge lifecycle

OpenTenant's existing architecture already models a tenant as a release, secret scope, domain, and configuration. Cloudflare becomes another reconciled layer of that tenant record.

tenant enabled
  → validate hostname and ownership rules
  → resolve the tenant release service
  → create or update DNS and Tunnel route
  → attach the selected Access policy profile
  → bind connector credentials through Vault
  → verify edge and origin readiness
  → mark the tenant route active

The reverse path matters just as much. Suspending a tenant should revoke edge access before workloads are removed. Offboarding should remove or disable Access applications, hostname routes, service credentials, and DNS state according to policy.

OpenTenant can keep secrets out of the release manifest by storing Cloudflare API credentials, tunnel tokens, and tenant service credentials in Vault. The release references the appropriate scope; an operator materializes only what the connector or workload requires.

Security and operational guardrails

Minimize Cloudflare API permissions

Use scoped API tokens for the exact account and zone operations required by reconciliation. Separate platform-wide connector administration from tenant route changes where possible.

Protect connector credentials

A remotely managed tunnel token authorizes a connector to run that tunnel. Store it in Vault and limit which namespace and service account can receive it. Do not copy it into tenant values files or Git history.

Default-deny the origin

Restrict inbound network paths so traffic reaches the service only through the intended connector and cluster controls. Apply Kubernetes NetworkPolicies between cloudflared and tenant services instead of allowing the connector namespace to reach every workload by default.

Separate customer and operator access

Customer-facing application routes, tenant administration, and platform operations should have independent Access applications or policy profiles. A broad policy reused everywhere turns configuration convenience into shared blast radius.

Test suspension and rollback

Verify that disabling a tenant removes access promptly, that failed edge changes do not publish an unready service, and that the last known-good route can be restored without exposing a different tenant.

Evaluation checklist

• The Kubernetes origin has no unintended public ingress path.
• cloudflared runs as a controlled deployment with an intentional replica count.
• Connector token delivery is Vault-backed and namespace-scoped.
• Every hostname maps to one expected tenant service.
• Administrative routes require stronger policy than public routes.
• Service-to-service routes use Service Auth rather than permanent Bypass.
• Tenant disablement revokes edge access before destructive cleanup.
• Cloudflare API operations and Access decisions are auditable.
• Negative tests prove that one tenant's identity and hostname cannot reach another tenant's service.

Sources

• Cloudflare Tunnel
• Deploy Cloudflare Tunnel on Kubernetes
• Cloudflare Access policies

OpenTenant's contribution is the repeatability: the edge route, access policy, release, and secret scope move together as one tenant lifecycle instead of four separate operational tickets.