Give Your OpenAI and Cloudflare Credentials an Expiry Plan
By Greg Nowak. Last updated 2026-08-15.
Most permanent credentials were never meant to be permanent. A developer adds an API key to GitHub Actions, an agency creates a Cloudflare token for a deployment script, and the immediate problem is solved. Months later, the automation still works—but nobody can confidently say who owns the credential, where it is used, or how to replace it safely.
An expiry date helps, but the better question is: does this workload need a stored secret at all? For GitHub Actions calling OpenAI, often it does not. For Cloudflare automation, a token may still be appropriate, but it should have narrow permissions, limited resources, a deliberate lifetime, and a tested replacement procedure.
Expiry is only one part of credential design
A good credential answers five operational questions before it reaches production:
- Owner: Which person or team is responsible for it?
- Purpose: Which job, integration, or deployment uses it?
- Scope: What actions and resources can it access?
- Lifetime: When should it stop working or be reviewed?
- Replacement: How can it be changed without an avoidable outage?
If those answers live only in one developer’s memory, the credential is already an operational liability. A secrets manager can protect the value, but it cannot fix unclear ownership or excessive permissions.
| Workload | Preferred approach | Important control |
|---|---|---|
| GitHub Actions calling OpenAI | Exchange GitHub’s OIDC identity for a short-lived OpenAI access token | Trust a specific repository, branch, workflow file, and environment |
| Cloudflare deployment automation | Use a task-specific API token | Limit permissions and account or zone resources |
| Cloudflare job on a fixed runner | Use a scoped token with TTL and client IP filtering | Confirm the runner has predictable egress addresses |
| Legacy integration that requires a static secret | Keep the secret temporarily, with an owner and replacement date | Document every consumer before rotating it |
OpenAI access from GitHub Actions can be short-lived
OpenAI now documents workload identity federation for GitHub Actions. Instead of storing a long-lived OpenAI API key in repository secrets, the workflow requests a signed OIDC token from GitHub. OpenAI validates that identity and exchanges it for a short-lived OpenAI access token.
The workflow needs permission to request its OIDC identity:
permissions:
id-token: write
contents: readid-token: write does not grant write access to repository contents. It only lets the job request an OIDC token. contents: read is commonly needed for actions/checkout.
The important work happens in the trust configuration. Do not trust an entire GitHub organisation when only one deployment workflow needs access. OpenAI supports matching claims including the repository, Git ref, workflow reference, and GitHub environment. For privileged access, its documentation recommends using the specific workflow_ref rather than relying on a reusable workflow name.
Use a separate OpenAI service account for the workflow and narrow its API permissions where practical. Keep production applications and CI/CD behind different access boundaries. The provider ID, audience, and service-account ID can be stored as GitHub Actions variables because they identify the configuration; they are not bearer secrets. The GitHub OIDC token and exchanged OpenAI token must never be written to logs.
Cloudflare tokens need scope, restrictions, and an owner
Cloudflare recommends API tokens over global API keys wherever possible. A token can be limited by permission group, access level, and resource. A DNS automation job for one zone should not receive edit access to every zone in the account.
Choose Read when the job only retrieves information. Grant write or edit access only when it actually changes configuration. For business-owned automation, consider an account-owned API token rather than a user-owned token when the required endpoints support it. That avoids tying critical infrastructure to an employee or agency account.
Cloudflare also supports client IP filtering and time-to-live restrictions. Without a configured end time, a token does not expire. The dashboard uses dates beginning at 00:00 UTC; the API supports more precise UTC timestamps. Treat the expiry as a planned renewal point, not a surprise failure: record the owner and create an alert well before the token stops working.
After creation, verify that the token is active before deploying it:
curl "https://api.cloudflare.com/client/v4/user/tokens/verify" \
--header "Authorization: Bearer <API_TOKEN>"Rotation and expiry solve different problems
Expiry limits how long a forgotten credential can remain useful. Rotation replaces the active secret. You need both a lifetime policy and a replacement procedure.
Cloudflare can roll a token while retaining its permissions, but rolling immediately invalidates the previous secret. That is useful during an incident, but it can break consumers that have not yet received the replacement. For planned, low-risk rotation, create a second narrowly scoped token, update and test each consumer, then revoke the old token. Use an immediate roll when the old value may be compromised and rapid invalidation matters more than a seamless transition.
A migration sequence that avoids unnecessary outages
- Inventory OpenAI keys, Cloudflare keys and tokens, their owners, consumers, permissions, and last-known use.
- Move suitable GitHub Actions workloads from stored OpenAI API keys to workload identity federation.
- Replace Cloudflare global keys and broad shared tokens with task-specific user- or account-owned tokens.
- Add TTL and client IP restrictions where the workload has a known lifetime or predictable network origin.
- Test replacement and rollback before revoking an existing production credential.
- Add renewal alerts and review the inventory whenever a workflow, supplier, or team owner changes.
This is less a secret-management exercise than an infrastructure-ownership exercise. The goal is not to rotate every credential on an arbitrary calendar. It is to remove stored secrets where possible and make every remaining credential understandable, constrained, and replaceable.
If your team has inherited GitHub workflows, Cloudflare automation, or API integrations nobody wants to touch, Greg can help map the dependencies and plan a safer migration without treating production as a security experiment.
Related on GrN.dk
- Copilot Has Repo-Level Metrics Now. What Should Teams Measure?
- The risky part of AI workflow pilots is often the OAuth screen
- A Voice Agent Is Only Ready When the Human Handoff Works
Need help with this kind of work?
Plan a credential audit with Greg Get in touch with Greg.