SYS.DOCS // DOCS

Cloudflare Zero Trust Private Access

Edka supports Cloudflare Zero Trust as the routed private-network path for cluster traffic that stays on the cluster private subnet.

Unlike Tailscale, the current Edka Cloudflare integration does not publish per-workload hostnames by itself. Instead, it advertises the subnet behind a Cloudflare Tunnel so WARP clients can reach the private IPs and private Gateway VIPs that already exist inside the cluster.

This is the recommended Cloudflare pattern in Edka:

Use MetalLB private VIP Gateway classes when you want private hostname routing through Gateway API.
Use Private LoadBalancer when you only need a private service IP.
Install the Cloudflare connector so WARP clients can actually reach that private subnet.

Prerequisites

Cluster private networking must be enabled.
The cluster must have a private subnet configured.
A Cloudflare account with Cloudflare Zero Trust available.
One or more WARP clients that should be able to reach the private subnet.
Install MetalLB when you want private VIPs for Gateway classes or private LoadBalancer services.

Install the Cloudflare connector

Go to Gateway or Add-ons in the cluster.
Press Install Cloudflare connector.
Provide your Cloudflare Account ID.
Provide a Cloudflare API token (required when Edka creates and manages the tunnel; optional when you supply an existing Tunnel ID and Tunnel Secret).
Optionally expand Advanced to provide an existing Tunnel ID, Tunnel Name, and Replicas (default 2, range 1-10). When you provide an existing Tunnel ID, a Tunnel Secret is required.
Finish the install and wait for the add-on to become ready.

Installation notes:

If you do not provide a tunnel ID, Edka can create and manage the tunnel for you.
If you do provide a tunnel ID, Edka will use your existing tunnel instead of creating one.
The API token is used during install or update and is not persisted by Edka.
The connector advertises the cluster private subnet, not a public hostname.

You can use the same Cloudflare API-driven tunnel flow described in the official Cloudflare Tunnel setup guide.

Choose how to expose your traffic

Pattern	Best for	What Cloudflare provides	What Edka still manages
`MetalLB private VIP` Gateway class	Private hostname routing for multiple workloads	Routed reachability to the cluster private subnet through WARP	Gateway class, wildcard domains, DNS-01 TLS
`Private LoadBalancer` service	Private IP exposure without Gateway routing	Routed reachability to the private service IP through WARP	Service exposure and assigned private IPs
Cloudflare connector only	Routed access to other private cluster services	CIDR route for the cluster private subnet	No hostname or TLS management by itself

Private Envoy Gateway classes with Cloudflare

Use this pattern when you want private hostnames and Gateway API semantics on top of Cloudflare-routed private access.

Install MetalLB.
Create a Gateway class with exposure mode MetalLB private VIP.
Install the Cloudflare connector.
Add a wildcard domain in Cluster > Domains and select that private Gateway class.
Access the hostname from clients that have WARP-based reachability to the cluster private subnet.

Operational notes:

The private VIP stays on the cluster subnet.
Cloudflare provides subnet reachability, not public ingress.
Wildcard domains and DNS-01 certificates still come from Edka’s Domains flow.
Single hostname HTTP-01 certificate flows remain public-only because they need public reachability.

Private LoadBalancer services with Cloudflare

Use this pattern when you do not need Gateway hostname routing and only want private IP access to a service.

Open a deployment networking form.
Select Private LoadBalancer.
Install MetalLB if it is not already present.
Install the Cloudflare connector so WARP clients can reach the private IP on the cluster subnet.

Edka will show the assigned private IPs in the UI. Those IPs are reachable only from networks that can route the cluster private subnet, such as Cloudflare WARP with the connector installed.

What Cloudflare Zero Trust does not do in Edka

The current Cloudflare integration is intentionally narrow:

It does not replace the Domains view.
It does not issue TLS certificates.
It does not create direct per-workload Cloudflare hostnames.
It does not expose traffic publicly.

Think of it as a private subnet transport layer for the traffic patterns Edka already manages with MetalLB, Gateway API, and Domains.