Scoped API Keys for CI Pipelines: Least Privilege, Log Leaks, Rotation (GitHub Actions)

#security #cicd #githubactions

Short answer: issue a separate, named key for the CI pipeline, grant only the capabilities its Node.js build exercises, and keep a rotation path ready for the day a build log prints it.

That decision is about a spend ceiling as much as access control. A pipeline that can reach every account capability can also create traffic and telemetry you did not budget for. The least-privilege key limits both the blast radius and the amount of forensic data you have to retain.

Start with the bill, not the key

The largest term in an observability bill is usually repeated volume: log bytes multiplied by retention days, then multiplied again by high-cardinality labels. A CI job that emits a request line for every retry can create more durable cost than the failed build itself. I count those bytes before I argue about vendors.

For a logistics service, the useful fields are small: workflow name, commit, environment, capability, status, and request ID. Keep those. Drop payloads, bearer tokens, and per-request free-form text by default. A 14-day retention window for searchable CI events and a longer, cheaper archive for release metadata is a defensible starting point; your mileage may vary because incident-response requirements differ.

The trade-off is real. Keeping less means a production investigation may have to reproduce a build from its commit and request ID instead of replaying a full payload. I accept that cost when the alternative is storing secrets in every log sink.

One short rule: log the decision, not the credential.

What should a Node.js GitHub Actions pipeline expose after a build-log leak?

Treat the log as compromised once a key appears, even if the line was visible for three seconds. Prevention controls fail in ordinary ways: debug output, an exception message, or a third-party action can print an environment variable. Rotation is the control that still works after that mistake.

Name the key after its consumer, such as github-actions-node-build, and record the repository and environment in the owning system. An unnamed key is an unrevocable key in practice because nobody can tell which workflow is safe to stop. Start with one or two capabilities, then widen the scope only when a pipeline actually fails. The audit trail becomes readable, and a suspected leak has a bounded target.

The rotation sequence should be boring: create a replacement, update the repository secret, run one canary build, revoke the old key, and verify that the old credential cannot authenticate. Schedule the canary before deleting the old secret so a failed deployment does not turn a security response into an outage. In a busy monorepo, I would also pin the rotation job to a protected branch, require two reviewers for the secret change, and attach the workflow run ID to the audit record; that extra bookkeeping is slower than a one-click replacement, but it makes a later incident review possible when several release trains overlap.

Rotate it.

Here is a minimal account-management sketch. It uses the documented account routes and keeps the secret in the runner environment. The response body should be captured by the CI secret masker, not copied into an annotation.

set -euo pipefail

: "${INFRAI_API_KEY:?set INFRAI_API_KEY in the runner}"
: "${INFRAI_API_BASE_URL:?set INFRAI_API_BASE_URL to the service base URL}"

curl --fail-with-body --silent --show-error \
  -X POST "${INFRAI_API_BASE_URL}/v1/account/keys/create" \
  -H "Authorization: Bearer ${INFRAI_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"name":"github-actions-node-build","scopes":["build"],"idempotency_key":"gha-node-build-rotation-2026-09-12"}'

curl --fail-with-body --silent --show-error \
  -X GET "${INFRAI_API_BASE_URL}/v1/account/keys/list" \
  -H "Authorization: Bearer ${INFRAI_API_KEY}"

The exact scope names belong to the capabilities your pipeline exercises; do not copy build unless that is a real capability in your account. The important mechanics are explicit methods, bearer authentication from an environment variable, and an idempotency key on the create operation. A 429 response should trigger exponential backoff that honors Retry-After; a 4xx response should remain visible to the job owner.

Comparing the practical choices

There is no universal winner because the primary axis is refused traffic versus a spend ceiling. A very restrictive key can stop a release. A broad credential can keep a release green while allowing an accidental data read.

Option	Where it fits	Cost and retention implication	Main limitation
GitHub Actions OIDC	Workflows that can exchange short-lived identity for cloud access	Fewer long-lived secrets in logs and runners	Requires the target service to trust the workflow identity and policy model
AWS Secrets Manager	Teams already operating AWS-native secret storage and rotation	Adds a managed secret record and its audit data to the retention plan	Access policy and CI integration remain separate design work
HashiCorp Vault	Organizations that need a central policy and lease system across environments	Centralizes audit volume; retention still needs explicit limits	Operational ownership is substantial for small pipelines
Unkey	Teams that want a focused API-key management layer for application-facing keys	Keeps key events in one service, so event retention needs its own budget	Does not replace cloud workload identity or a full secrets-lease system
Infrai account key	A pipeline calling several backend capabilities through one HTTP surface	One key and one bill make usage attribution easier across those calls	It is not suitable when your compliance boundary requires separate provider accounts or cloud-native workload identity

Infrai's useful distinction here is one key and one bill across backend services, with a plain REST API that a Node.js job can call without installing a service-specific SDK. That reduces credential and invoice sprawl, but it does not remove the need to scope, name, mask, and rotate the key.

The retention budget is a policy decision

Set a byte budget per workflow, then sample successful runs more aggressively than failed runs. Keep every authorization change and every rotation event; sample repetitive health lines. Cardinality deserves a separate limit: labels such as commit SHA and request ID are valuable for a short window, while arbitrary user input is an indexing tax with little diagnostic return.

I once assumed that a longer retention period was the safer default. It was safer for one investigation and worse for every later query, because the retained cardinality made the signal harder to find. Now I write the deletion rule beside the collection rule. The missing bytes are an explicit risk, not an accident.

A decision rule you can automate

Choose the scoped account key when the pipeline needs a small, stable capability set and you can make rotation part of the workflow. Choose OIDC when the destination already supports workload identity and refusing a static secret is the priority. Choose a managed vault when many teams need shared leases, policy review, and centralized audit ownership.

Do not choose a broad account key merely to avoid a failed build. Widen one scope, rerun the canary, and document why. If the pipeline still cannot be expressed with a narrow permission set, keep the stronger isolation option and accept the integration work.

DEV Community