Cloudflare Access is a good product. We deploy it. But I keep seeing it put in front of an in-cluster application as a substitute for doing OIDC properly, and that’s the wrong call. Here’s the short version of why.
Cloudflare Access decides who gets in at Cloudflare’s edge. For an in-cluster workload, that means an external SaaS is the authority for access into your cluster. The application trusts a header it was handed. If anything can reach the application’s port without going through Cloudflare, that header is forgeable and the protection is gone.
So you start bolting on mitigations. mTLS to the origin, IP allowlists pinned to Cloudflare’s ranges, service tokens for machine calls. The tidy pattern stops being tidy, and your identity decision still lives in someone else’s trust domain instead of the cluster’s.
The promise is “no identity code to write.” The reality is you now manage origin certificates, a tunnel daemon or a set of firewall rules tracking Cloudflare’s IP space, and Access service tokens for service-to-service calls. Three external-facing surfaces, all needing rotation. Doing OIDC in-cluster with cert-manager and External Secrets Operator gives you automatic certificate renewal and secrets that rotate from Key Vault without touching a manifest. The “no work” option is often more work.
When Cloudflare has an outage, and it happens, your internal auth flow goes down with it. The cluster is healthy, the app is healthy, the IdP is healthy, and users still can’t get in because the access decision lives at an edge that’s currently unreachable. You’ve coupled internal tooling availability to an external provider. An in-cluster auth path fails only when the cluster fails, which is the same failure domain as the workload anyway.
Every request detours through a Cloudflare PoP for the policy decision before reaching your origin. For one page load nobody notices. For a chatty internal app making dozens of API calls, each call carries the edge hop. We’ve measured 60-120ms added to internal tooling that never needed to leave the region. In-cluster validation is a local call next to the workload.
Access decisions land in Cloudflare’s logs. Application activity lands in your SIEM. Correlating a denied access with what happened inside the cluster means stitching two systems together across an organisational boundary. Do identity in-cluster and the IdP events, the proxy logs, the ingress logs, and the application logs all flow to one place. One query answers who did what.
Cloudflare Access decides whether a request gets through. That’s it. An in-cluster workload usually needs more than a binary gate. It needs to know which user this is, which groups they belong to, and which scopes apply, so the application can make fine-grained authorization decisions of its own. Edge access control gives you a doorman. Proper OIDC gives you identity that flows all the way into the application’s own permission checks. For anything with roles, tenants, or per-resource permissions, the doorman isn’t enough.
The pitch for putting Access in front of a workload is that you skip writing auth. In practice the in-cluster alternative is mostly assembly, not code. oauth2-proxy handles the OIDC dance as a deployment in front of the workload. Keycloak, or Entra ID directly, is the identity provider. cert-manager and External Secrets Operator handle the certificates and secrets without anyone editing a manifest. You wire components together rather than write an auth system from scratch, and what you get is identity that lives inside your boundary instead of at someone else’s edge. The work you save with Access is smaller than it appears, and the dependency you take on is larger.
None of this is an argument against the product. It’s an argument about boundaries. Cloudflare Access is excellent for:
Public marketing sites and documentation behind a staff login. Low risk, no in-cluster identity needs, and the edge is the natural place to gate it. We use it for exactly this.
Low-stakes employee dashboards that live outside the cluster. A status page, an internal wiki, a tool with no regulated data. Putting Access in front is proportionate and less work than running identity infrastructure for it.
Simple SaaS frontends where you want SSO in front of an off-the-shelf tool and have no backend identity concerns to speak of.
The deciding question is always the boundary. If the thing you’re protecting is a standalone web property, the edge is a fine place to make the access decision. If it’s a workload inside a cluster that has its own identity and authorization needs, put the decision inside the cluster, enforced by infrastructure you run.
For the full pattern, the topology with Application Gateway WAF, oauth2-proxy, Keycloak, External Secrets Operator, and cert-manager, see our deeper write-up on building zero-trust ARO platforms. This is the short version of that argument.
If you’re deciding where identity should sit for a Kubernetes workload, our cybersecurity team does this work daily. Book a consultation and we’ll tell you which of your services belong behind an edge and which need identity of their own.