cloudflare v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-cloudflare-api-token

Custody

customer_vault

Injection

header (Authorization)

A Cloudflare API token for the customer's own account, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token — 'Bearer <token>'. Issuance is external: a user creates the token in the Cloudflare dashboard (My Profile > API Tokens), choosing the token's permission groups and the zones and accounts it covers; the token value is shown once at creation, so capture it into the vault at that moment. Least privilege: grant only the permissions the registered capabilities need — Zone.Zone Read for the zone collection read, Zone.DNS Read/Edit on the bound zone(s) for the DNS capabilities (per the retrieved DNS records list reference, the endpoint accepts DNS Read or DNS Write), and Cache Purge only where the purge capability is enabled — and scope the token to the specific zones the deployment binds, not All zones. Expiry and revocation: a token may be created with an optional TTL, after which it fails closed, but a token without one does not expire on its own; revocation is rolling or deleting the token in the dashboard — the token-roll operation's documentation was not retrievable in this session, so the previous value's exact invalidation timing after a roll (including any grace period) is unverified here and must be confirmed against Cloudflare's roll-token reference before relying on roll as a revocation mechanism; deleting a token is immediate — and disabling issuance, or the creating user losing permission to create tokens, does NOT invalidate tokens already issued: each issued token must be rolled or deleted individually. Rotation therefore sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle of its own. Two-header honesty: Cloudflare also still accepts the legacy Global API Key scheme, which authenticates with TWO headers — X-Auth-Email (the account email) plus X-Auth-Key (the global key); per the retrieved get-started reference the Global API Key is the previous scheme and is less secure than API tokens, and this pack registers the single Bearer header only — a deployment that insists on the legacy key must wire both headers itself and accept that the global key is unscoped and grants everything the account can do. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• cloudflare-account (api, internal): https://api.cloudflare.invalid/client/v4/zones
• cloudflare-zone (site, internal): https://api.cloudflare.invalid/client/v4/zones/ZONE_ID

The endpoint host 'api.cloudflare.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the real Cloudflare API authority (api.cloudflare.com, or the customer's API host for a partner/custom deployment) before enabling, in every endpoint, in the resource locators and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. ZONE_ID and DNS_RECORD_ID in the endpoint paths are placeholders the deployment binds to concrete identifiers before enabling. Every read endpoint here is a COLLECTION read: single-record reads (GET one zone, GET one DNS record) are not registered. Tiering rationale: DNS record creation registers as create AND deploy, and edit as update AND deploy, at the R3 floor: creating or editing A, AAAA, CNAME or MX records provisions or reroutes production traffic routing — a deploy-equivalent effect on live infrastructure, and deploy is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer) — so no lower tier is honest; only the partial-edit PATCH is registered, not the PUT overwrite. DNS record deletion registers as delete at the R3 floor: removing the record that resolves a name can take the service behind it offline — the outage is neither immediate nor guaranteed, because resolver caches and unexpired TTLs can keep stale answers alive until they lapse — and delete is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). Cache purge registers as delete at the R3 floor, judged by effect: the endpoint's caller-controlled body accepts purge_everything=true, which per the retrieved purge reference removes ALL files from the zone's cache in every Cloudflare data center and forces all subsequent requests back to the origin — a high-blast-radius burst of origin load — so an unrestricted body defeats any lower tier, and purge is treated as an irreversible-action equivalent. Documented exclusions — this pack does not register: zone creation and zone deletion (DELETE /zones/{zone_id} removes the whole zone and every record and setting in it), the DNS record PUT overwrite, zone settings changes (SSL mode, security level, TLS minimum), WAF and firewall rules, Page Rules and cache rules, Workers scripts and routes, Load Balancers, API token creation/verification/roll and user or account membership management, registrar operations, and every other Cloudflare API — a documented exclusion, not an approximated capability.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://developers.cloudflare.com/fundamentals/api/get-started/ (retrieved 2026-09-21)
• https://developers.cloudflare.com/api/resources/dns/subresources/records/methods/list/ (retrieved 2026-09-21)
• https://developers.cloudflare.com/api/resources/cache/methods/purge/ (retrieved 2026-09-21)
• https://developers.cloudflare.com/cache/how-to/purge-cache/purge-everything/ (retrieved 2026-09-21)
• https://developers.cloudflare.com/api/resources/zones/methods/list/ (retrieved 2026-09-21)
• https://developers.cloudflare.com/api/resources/dns/subresources/records/methods/create/ (retrieved 2026-09-21)
• https://developers.cloudflare.com/api/resources/dns/subresources/records/methods/edit/ (retrieved 2026-09-21)
• https://developers.cloudflare.com/api/resources/dns/subresources/records/methods/delete/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.