Raxx · internal docs

internal · gated ↑ index

Cloudflare Token Taxonomy

Status: Phase 2 in progress — new names live in code, vault write pending Owner: operator / sre-agent Last updated: 2026-05-01 UTC Tracking: #754 (CF token rename), refs #81 (Epic: SDLC, Tooling, and Security Hardening)

This document is the canonical name-mapping reference for the Cloudflare token rename executed in #754. It maps old names to new names, explains the CF_<FUNCTION>_<SCOPE> pattern, and lists the actions still needed to complete the migration.

See docs/ops/vault-token-taxonomy.md Section 1 for the full naming convention that applies to all vendors.


Mapping table

Old name New name Function Vault path
CLOUDFLARE_RAXX_AUTOMATION_API_TOKEN CF_PAGES_DEPLOY CF Pages deploy + Access app read /MooseQuest/cloudflare/
CLOUDFLARE_ACCESS_MGMT_TOKEN CF_ACCESS_MGMT CF Access app/policy management /MooseQuest/cloudflare/
CLOUDFLARE_PAGES_READ_TOKEN CF_PAGES_READ CF Pages project read-only (status probe) /MooseQuest/cloudflare/
CF_ACCESS_SERVICE_TOKEN_CONSOLE CF_ACCESS_SVC_CONSOLE CF Access service token — console.raxx.app bypass /MooseQuest/cloudflare/
CF_ACCESS_SERVICE_TOKEN_VAULT_PROBE CF_ACCESS_SVC_VAULT CF Access service token — vault.raxx.app bypass /MooseQuest/cloudflare/
CLOUDFLARE_ACCOUNT_ID CF_ACCOUNT_ID Cloudflare account identifier (config value, not secret) /MooseQuest/cloudflare/
CLOUDFLARE_EDIT_DNS CF_DNS_EDIT DNS record write — raxx.app zone /MooseQuest/cloudflare/

Names that already followed the pattern (no change)

These were already correct and are left unchanged:

Name Function
CF_ACCESS_CLIENT_ID CF Access service token client ID for vault bypass
CF_ACCESS_CLIENT_SECRET CF Access service token client secret for vault bypass

Migration state (as of 2026-05-01)

Done

Pending operator actions (post-merge)

  1. Write new-taxonomy secrets to Infisical at /MooseQuest/cloudflare/: - CF_PAGES_DEPLOY = same value as CLOUDFLARE_RAXX_AUTOMATION_API_TOKEN - CF_ACCESS_MGMT = same value as CLOUDFLARE_ACCESS_MGMT_TOKEN - CF_PAGES_READ = same value as CLOUDFLARE_PAGES_READ_TOKEN - CF_ACCESS_SVC_CONSOLE = same value as CF_ACCESS_SERVICE_TOKEN_CONSOLE - CF_ACCESS_SVC_VAULT = same value as CF_ACCESS_SERVICE_TOKEN_VAULT_PROBE - CF_ACCOUNT_ID = same value as CLOUDFLARE_ACCOUNT_ID - CF_DNS_EDIT = same value as CLOUDFLARE_EDIT_DNS

  2. Add new GH secrets (repo-level Actions secrets): - For each CI workflow that uses CLOUDFLARE_* — add the new-named secret alongside the old one. - CI currently uses: CLOUDFLARE_PAGES_READ_TOKEN, CLOUDFLARE_ACCOUNT_ID (in deploy workflows).

  3. Update Heroku config vars for each app: - raxx-console-prod: add CF_PAGES_READ, CF_ACCOUNT_ID, CF_ACCESS_SVC_CONSOLE, CF_ACCESS_MGMT - raxx-console-staging: add CF_ACCESS_SVC_CONSOLE (staging variant) - raxx-api-prod / raxx-api-staging: add CF_PAGES_DEPLOY if referenced

  4. Smoke test after each Heroku config set to confirm probes stay green.

  5. File cleanup card to delete old names from vault + Heroku config vars + GH secrets after one full deploy cycle confirms new names work. Target: one sprint after this PR merges.


Rationale for each name choice

New name Rationale
CF_PAGES_DEPLOY The automation token's primary function is deploying CF Pages projects. "automation" in the old name was vague; "pages-deploy" is self-describing.
CF_ACCESS_MGMT Manages CF Access apps and policies. _MGMT follows the <FUNCTION> convention without a scope suffix (one CF account).
CF_PAGES_READ Read-only status probe for CF Pages deployments. _READ suffix distinguishes from CF_PAGES_DEPLOY.
CF_ACCESS_SVC_CONSOLE Service token for the console CF Access gate. _SVC prefix distinguishes service tokens from user API tokens. _CONSOLE is the scope (which surface it unlocks).
CF_ACCESS_SVC_VAULT Service token for the vault CF Access gate. _VAULT is the scope.
CF_ACCOUNT_ID Short, unambiguous. This is a config value, not a secret — short name reduces friction.
CF_DNS_EDIT DNS record write permission. _EDIT follows the verb-noun <FUNCTION> convention.

Backward compatibility

During the migration window (between this PR and the cleanup card being resolved):


Follow-up cleanup card

After one full deploy cycle confirms new names are live and services are healthy, file a card to:

  1. Delete old-named secrets from Infisical vault.
  2. Remove old-named GH Actions secrets.
  3. Remove old-named Heroku config vars.
  4. Remove legacy-fallback code from Python consumers (the or os.environ.get("OLD_NAME") lines).
  5. Remove legacy entries from vault.py dicts (ROTATION_MODE, SOP_PATH, _CREDENTIAL_CADENCE_KEY, AFFECTED_SITES, _VENDOR_URL_CATALOG).
  6. Remove legacy entries from handler_validator.py HANDLER_REGISTRY.
  7. Update rotation/INDEX.md to mark legacy rows as [archived].