Zero Trust & Security
Adventive runs Cloudflare Zero Trust as the front door to its internal and administrative surfaces, and as the only inbound path to its databases. The team domain is adventive.cloudflareaccess.com.
Access applications
Section titled “Access applications”Fifteen Access applications are configured. Most are self-hosted apps protecting admin and API surfaces; the rest are the App Launcher, the WARP login app, and a SaaS SAML integration for Stripe.
| Application | Domain | Type | Session |
|---|---|---|---|
admin.adventive.com | admin.adventive.com | self-hosted | 30m |
| Adventive CMS | cms.adventivestg.com + cms.adventive.com (/admin, /auth) | self-hosted | 6h |
| admin-api | admin-api.adventive.dev | self-hosted | 24h |
| genesis-admin | genesis-admin.adventive.dev | self-hosted | 24h |
| Status Admin (dev) | status.adventive.dev/admin | self-hosted | 8h |
| productlove | productlove.adventive.dev | self-hosted | 24h |
| NewRelic Proxy (dev) | nr.adventive.dev/v1 | self-hosted | 24h |
| docs | docs.adventive.dev | self-hosted | 24h |
| Hyperdrive, dev console / billing / aggregate | db-*-dev.adventive.dev | self-hosted | 24h |
| Stripe | SAML SaaS | saas | 24h |
| App Launcher | adventive.cloudflareaccess.com | app_launcher | 30m |
| Warp Login App | adventive.cloudflareaccess.com/warp | warp | 24h |
| jlambert-test admin | jlambert.admin.adventive.dev | self-hosted | 24h |
Two items are worth a cleanup pass: jlambert-test admin reads as a personal test application and should be removed if it is no longer needed, and the session durations vary widely (30m to 24h). Standardising session length by sensitivity, short for admin surfaces, longer for low-risk apps, would make the posture easier to reason about.
Identity providers
Section titled “Identity providers”| Provider | Type | Role |
|---|---|---|
| JumpCloud SAML | saml | Primary |
| Adventive (Google Workspace) | google-apps | Fallback |
| One-Time PIN | onetimepin | Break-glass / external |
This matches the documented design: JumpCloud is the primary SSO with Google as the fallback. Access policies resolve against the single reusable group Adventive Employees.
Zero Trust organisation
Section titled “Zero Trust organisation”The organisation is named Adventive with a 6-hour default session and a custom-branded login page. allow_authenticate_via_warp is off at the organisation level, and the dashboard is not in read-only mode.
Access service tokens
Section titled “Access service tokens”| Token | Client ID | Expires |
|---|---|---|
adv-hyperdrive-dev | 99fc0a3d…access | 2027-04-29 |
adv-nr-proxy-admin-ui-dev | e6e572b6…access | 2027-05-05 |
adv-nr-proxy-admin-ui-dev-rotate | 02448f46…access | 2027-05-05 |
All three are one-year tokens expiring in 2027. The -rotate companion token indicates a rotation pattern is already in place for the New Relic proxy; the same approach should be applied to adv-hyperdrive-dev before its 2027 expiry.
Gateway
Section titled “Gateway”Two Gateway rules are configured: an enabled Layer-4 rule, Allow AWS Private IPs, and a disabled DNS rule, Content Blocks. Gateway is therefore lightly used, primarily to permit the private-network path to AWS rather than for broad content filtering.
Cloudflare Tunnels
Section titled “Cloudflare Tunnels”| Tunnel | Status | Connections | Configuration |
|---|---|---|---|
adv-cflared-dev | Healthy | 4 | Locally configured (dev) |
cf-tunnel.us-east1.aws.adventive.com | Healthy | 4 | Dashboard-managed (AWS us-east-1, since 2023) |
Both tunnels are healthy with four connections each, replica high-availability, consistent with the standing tunnel pattern. adv-cflared-dev is the newer, locally-configured tunnel that fronts the development databases; the older tunnel fronts the legacy AWS estate.
Notifications
Section titled “Notifications”Four notification policies are enabled, all delivering by email: origin monitoring on console.adventive.com and ads.adventive.com, a Layer-7 DDoS alert, and the default web-analytics summary. Email-only delivery is a single channel; routing the DDoS and origin alerts to a chat channel or PagerDuty would shorten response time on the highest-severity events.
Posture against the six Cloudflare design pillars
Section titled “Posture against the six Cloudflare design pillars”| Pillar | Current state |
|---|---|
| Redundancy | Both tunnels run four connections (replica HA). The adv-status-artifacts-dev R2 bucket has a paired replica. Production AWS origins sit behind load balancers. |
| Resiliency | Databases are private-only, reachable solely through Access-authenticated tunnel hostnames; a compromised edge cannot reach them directly. Read/write database roles are separated (see Hyperdrive SOP). |
| Disaster recovery | Identity recovery codes are held out-of-band in AWS Secrets Manager (production gate). Tunnel and Access configuration is reproducible. RTO/RPO targets are not yet documented per service. |
| Backup | R2 replica exists for status artifacts; extend to other non-reproducible buckets. Database backups live in AWS (RDS/Aurora), out of scope for Cloudflare. |
| Deployment | Workers deploy from the local sandbox, promoted dev → stg → prd; deploys never run from GitHub Actions. |
| Observability | OpenTelemetry → New Relic is the mandated baseline; the New Relic proxy Worker is deployed. Cloudflare-side alerting is email-only across four policies. |
Security observations
Section titled “Security observations”- 2FA is universal across all four account members. A strong baseline.
- Review the
orchestrator@andjlambert-test adminsurfaces, automation accounts and personal test apps deserve a periodic audit. - Standardise Access session durations by sensitivity tier.
- Add a second notification channel for high-severity alerts beyond email.
- Plan
adv-hyperdrive-devtoken rotation ahead of its 2027 expiry, mirroring the New Relic proxy’s rotate pattern.