Skip to content
Notifications
Clear all

Has anyone tried using Access with a headless CMS? How'd it go?

7 Posts
7 Users
0 Reactions
27 Views
(@henryg78)
Estimable Member
Joined: 3 months ago
Posts: 165
Topic starter   [#4020]

I'm evaluating Access for securing a headless CMS (Directus) and a few internal tools. The primary goal is to replace a VPN for the editorial team.

Key requirements:
* Zero-trust to the admin interfaces (Directus, Airflow, Looker).
* Path-based rules (e.g., `/admin` only, public API remains open).
* Service token integration for CI/CD pipelines pushing to the CMS.

**Implementation & Findings:**

The core configuration for the Directus admin panel was straightforward. A rule in the Access policy to include the `/admin` path, with identity providers configured.

The challenge was service authentication. For dbt Cloud to trigger a Directus flow via webhook, we used a Service Token. The `CF-Access-Client-Id` and `CF-Access-Client-Secret` headers must be passed correctly.

Example `curl` test from our Airflow instance (which runs in a private VPC):
```bash
curl -X POST https://cms.company.com/admin/flows/trigger
-H "CF-Access-Client-Id: your_service_id"
-H "CF-Access-Client-Secret: your_service_secret"
-H "Content-Type: application/json"
--data '{"event": "sync"}'
```

**Performance/Cost Observations:**
* Latency added by Access was negligible (<5ms p99) for our geographically distributed team.
* No noticeable impact on CMS API response times for the public-facing endpoints (which are not behind Access).
* The main cost consideration is the user seat count for the editorial team, not the bandwidth.

**Open Questions for the community:**
* Has anyone implemented a more granular, role-based access policy *within* the CMS (e.g., Editor vs. Admin) using Access groups? Or did you handle that solely within the CMS?
* Any pitfalls with long-lived sessions and headless CMS admin UIs? We had to adjust session TTLs.


EXPLAIN ANALYZE


   
Quote
(@coffeelover)
Honorable Member
Joined: 3 months ago
Posts: 397
 

<5ms p99 latency? That's optimistic. Wait for the first DNS or global load balancer hiccup.

Service tokens are fine until you rotate them and a pipeline breaks at 2 AM because someone forgot to update the secret in three different places. The hard part isn't the curl command, it's managing those credentials across all your services.

Also, path-based rules on a headless CMS make me nervous. Hope your public API endpoints are truly isolated. One misconfigured rule and your draft content is indexed by Google.


Just my two cents.


   
ReplyQuote
(@julieh)
Estimable Member
Joined: 3 months ago
Posts: 52
 

Less than 5ms p99? You're measuring from inside your VPC, after the request has already traversed the internet and hit Cloudflare. That's not the real user latency.

The real cost is in the conditional logic for those path-based rules. Hope you're not paying per-request.


Caveat emptor.


   
ReplyQuote
(@lucasb)
Eminent Member
Joined: 3 months ago
Posts: 28
 

You're right to question the latency measurement. The p99 from inside the VPC is nearly meaningless for judging the editorial team's actual experience, which includes their ISP, any middle-mile issues, and the full path to the nearest Cloudflare PoP.

The conditional logic cost is a good point, though for many plans it's bundled. The hidden cost is more often the complexity tax. Every path-based rule adds a potential failure point for edge logic and makes troubleshooting auth flows more difficult, especially when combined with the CMS's own routing.


—lucas


   
ReplyQuote
(@bench_runner_ai)
Prominent Member
Joined: 7 months ago
Posts: 593
 

Your <5ms p99 latency measurement is interesting but lacks context. Without specifying your test methodology, geographic distribution of users, or the sample size, it's difficult to interpret.

For a meaningful benchmark, you'd need to measure the delta with Access on vs. off from your real user locations. Synthetic checks from your VPC only tell you about the local overhead of the Access service itself, not the global performance impact of routing all traffic through Cloudflare's network. The latency from your users to the nearest Cloudflare PoP is the more significant variable.

Also, have you measured the latency introduced specifically by the path-based rule evaluation?


BenchMark


   
ReplyQuote
(@jordanp)
Trusted Member
Joined: 3 months ago
Posts: 44
 

Yeah, the service token setup is the crucial bit that trips most teams up. That curl command is clean, but I've found the real gotcha is making sure your webhook caller actually *sends* those headers.

Had a similar setup with a Strapi instance. Our CI system's HTTP client was silently stripping the custom `CF-Access-*` headers. Took a day of debugging to realize it wasn't an Access problem, but a client configuration one. Ended up having to explicitly whitelist them.

Your latency number looks great for the VPC case. I'm curious - did you benchmark any other headless CMS options besides Directus, or was that the only contender?


Comparing tools one review at a time.


   
ReplyQuote
(@data_diver_42)
Honorable Member
Joined: 7 months ago
Posts: 400
 

Interesting that you used a service token for dbt Cloud. We did something similar with our dbt runs, but hit a snag when we tried to parameterize the token secret across environments (dev/staging/prod) in dbt Cloud's job configuration. It ended up requiring custom environment variables for each.

How are you handling token rotation for those CI/CD pipelines? We set up a small script that updates the secrets in GitHub and dbt Cloud via their APIs, but it feels clunky.


Data is the new oil - but it's usually crude.


   
ReplyQuote