Cloudflare Terraform Integration

Integration plan for adding Cloudflare to the Cirius Group edge stack on the free tier, managed as code via Terraform. This document satisfies DECOMM-010 and is a dependency of the dashboard migration (DECOMM-009, see runbooks/dashboard-migration-plan.md).

Goals

• Edge security and performance: WAF and CDN in front of dashboard.ciriusgroup.com (and future hosts as scoped) using the Cloudflare free tier.
• Infrastructure as Code: Cloudflare configuration lives in Terraform alongside the rest of the infrastructure, reviewed in pull requests, applied through the existing pipeline.
• DNS clarity: authoritative DNS for the Cloudflare-fronted hostnames moves to Cloudflare via delegation from the registrar (U2 Web).

Cloudflare Free Tier — Capabilities and Limits

The free tier is adequate for the initial scope. Relevant capabilities and limits:

What the free tier provides

• Unmetered DDoS mitigation.
• Global CDN with edge caching for static assets.
• WAF: Cloudflare Managed Ruleset (core OWASP-aligned protections) is available on the free plan; custom WAF rules are limited (see limits below).
• Universal SSL (free TLS at the edge, shared certificate).
• DNS management.
• Always Online and basic analytics.
• Page Rules (3 on free plan) and equivalent Rules engine quotas.

Free tier limits that matter for this integration

• Custom WAF rules: capped; complex custom rule sets require a paid plan. The plan here is to rely primarily on the Managed Ruleset and use custom rules sparingly.
• Rate limiting rules: one free rate-limiting rule with fixed thresholds.
• Page Rules / Rules engine quotas: three Page Rules on free; the newer Rules engine has similar quotas per ruleset. Design for simple rule sets.
• Bot management: basic bot fight mode is free; advanced bot management is paid.
• Log retention: analytics retention is limited on free; real-time logs and Logpush are paid features.
• SLA: no uptime SLA on the free plan. Acceptable for internal dashboard scope.

If WAF or rate-limiting needs exceed the free tier as the deployment grows, an upgrade to Pro or Business will be evaluated then.

Terraform Provider

Use the official cloudflare/cloudflare Terraform provider. The provider is configured with a scoped API token (not a global API key). Token scope: edit access to the specific zone(s) managed by Terraform, read access for account context.

High-level provider configuration (not executable as-is — follow the repo's conventions for variables and state):

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

The API token is stored in the existing secret store and surfaced to the pipeline in the same pattern used for other provider credentials. The token is rotated on the standard secret rotation cadence.

DNS Delegation

Cloudflare needs to be authoritative for the zones it fronts. Delegation happens at the registrar (U2 Web) where ciriusgroup.com, ciriusdde.com, and ciriussupport.com are registered.

For dashboard.ciriusgroup.com (initial scope)

Two options are evaluated:

1. Zone-level delegation — move the entire ciriusgroup.com zone to Cloudflare. Cloudflare becomes authoritative for all records in the zone. Best for long-term; needs a careful lift-and-shift of all records.
2. Subdomain delegation — delegate only dashboard.ciriusgroup.com via NS records at U2 Web pointing at Cloudflare's assigned nameservers for a child zone. The parent zone ciriusgroup.com stays at the current authoritative DNS.

Chosen approach for initial scope: subdomain delegation for dashboard.ciriusgroup.com. This minimizes blast radius — if there is any issue with the Cloudflare path, only the dashboard subdomain is affected and rollback at U2 Web is a single NS record change.

Zone-level delegation for the parent zone can be revisited once the subdomain pattern is proven.

Procedure

1. Create the Cloudflare zone for the delegated name (for example, dashboard.ciriusgroup.com as a standalone zone) via cloudflare_zone.
2. Cloudflare provides two assigned nameservers for the zone.
3. Log in to U2 Web and add NS records at the parent zone level for the dashboard label pointing to the two Cloudflare nameservers.
4. Validate with dig NS dashboard.ciriusgroup.com that both the authoritative answer and the glue path resolve to the Cloudflare nameservers.
5. Activate the zone in Cloudflare once propagation is observed.

A nameserver change at U2 Web is the DNS root-of-trust action and is coordinated with the dashboard migration change window.

Terraform Resources Needed

The minimum resource set for this integration:

Resource	Purpose
cloudflare_zone	The delegated Cloudflare zone (for example, the dashboard.ciriusgroup.com zone).
cloudflare_record	DNS records within the zone (A / AAAA / CNAME for the origin, plus any TXT records needed).
cloudflare_ruleset (managed)	Deploy the Cloudflare Managed Ruleset in the WAF engine for OWASP-aligned protection.
cloudflare_ruleset (custom)	Custom WAF rules within free-tier quota — for example, country allowlisting or specific path hardening.
cloudflare_rate_limit	Single rate-limiting rule (free tier) scoped to the login or high-risk endpoint.
cloudflare_page_rule or Rules engine equivalent	Cache behavior and edge-level redirects as needed.

Optional but recommended:

Resource	Purpose
cloudflare_zone_settings_override	Set zone-wide defaults (TLS min version, always-use-HTTPS, Brotli, etc.) declaratively.
cloudflare_origin_ca_certificate	Mint an origin certificate for edge-to-origin re-encryption (TLS end-to-end).

Out of scope for this integration

• Logpush, advanced bot management, advanced rate limiting — paid features, deferred.
• Cloudflare Tunnel to the origin — evaluated as an alternative to origin IP allowlisting; decision recorded in the dashboard migration plan.
• Workers, Pages, R2 — not in scope for the dashboard migration.

Rollout

1. Add the provider configuration and initial zone to Terraform in a feature branch.
2. Apply in a non-production context first (DDE or equivalent) if possible; otherwise, first apply is the dashboard zone creation, which is additive and safe.
3. Configure U2 Web delegation (NS records) as a coordinated change.
4. Validate DNS, TLS, and WAF behavior with synthetic traffic before flipping the origin for real traffic (the origin flip is handled in the dashboard migration Stage 3 DNS cutover).

Related Documents

• runbooks/dashboard-migration-plan.md — dashboard migration plan (DECOMM-009)
• compliance/vendor-phi-inventory.md — vendor inventory (Cloudflare is edge for a PHI-adjacent surface; transmission-only path, no PHI storage at the edge)
• runbooks/backup-architecture.md — backup architecture