DEV Community

PrestonCole1111
PrestonCole1111

Posted on

Tenant API Key Containment in Least-Privilege GitHub Actions CI Pipelines

#security #githubactions #api

A scoped API key for a least-privilege CI pipeline belongs outside the production trust boundary, even when the GitHub Actions workflow lives beside the application. For an e-commerce release, the deciding constraint is how much customer and order data that credential can reach after it appears in runner output.

Short answer: Issue one named, narrowly scoped API key per tenant pipeline, allow only the capabilities that build actually exercises, and predefine rotation and revocation so a leaked log cannot become a production-data incident.

Start narrower than you think you need. A refused deployment is visible and reversible; silent over-privilege is neither. This applies to a Node.js build in GitHub Actions just as it does to any other runtime. The package ecosystem isn't the security boundary. The credential is.

How should a GitHub Actions CI pipeline scope and rotate an API key?

Treat the workflow as a consumer with its own identity. A pipeline that publishes one artifact and sends one deployment notification usually needs one or two capabilities, not the authority carried by an operator's main key. Name the key after the tenant and consumer, such as the equivalent of store-184-release, so an audit can connect a credential to a workflow without reconstructing months of job history. An unnamed key may be technically revocable, but in practice nobody knows which release will break when it is removed.

The scope should be the intersection of three sets: the tenant being deployed, the environment being changed, and the capabilities invoked by the job. Don't copy the developer key into a repository secret and call that separation. It creates a second storage location for the same blast radius. Also don't grant a speculative capability because a future release might use it. Scopes can be tightened later; begin narrow, observe a denied operation, and add only the permission the workflow proves it needs.

Refusal is useful evidence.

Build logs deserve harsher assumptions than source control. Shell tracing, debug flags, exception serialization, and a careless request dump can expose a secret without anyone deliberately printing it. Plan as though this will happen once. Masking and redaction still matter, but they are containment layers, not proof that a credential will remain private. The operational target is a leaked key whose permissions are too small to read production customer records, alter unrelated tenants, or invoke capabilities outside the release path.

Rotation needs an owner and an order. Issue the replacement with the same narrow boundary, place it in the tenant's GitHub Actions secret, run a controlled release, verify the old key is absent from subsequent jobs, and revoke the old credential. If compromise is suspected, skip the leisurely overlap: stop affected workflows, revoke or mark the key as suspected compromise, replace the secret, then resume after checking scope and logs. The exact response window depends on your organization's incident policy; I'm not sure a universal minute target would be honest without the threat model and on-call agreement that define it.

Choose the spend ceiling before the permission ceiling

Least privilege answers what a leaked key may do. It doesn't answer how much accepted work it may trigger. For a tenant-scoped e-commerce pipeline, those controls should be designed together because the primary trade-off is a spend ceiling versus refused traffic. A ceiling that is too loose lets a leaked credential repeatedly exercise its allowed capability. A ceiling that is too tight turns an ordinary release burst into denied requests.

Set the first ceiling from the known release path, then decide explicitly what should happen at the boundary. A production deploy should usually fail closed rather than borrow authority or budget from another tenant. That produces a noisy failed job, which is preferable to hiding a cross-tenant exception. Yet a hard failure also has a business cost: an urgent fraud-rule or checkout fix may wait while an engineer raises the limit. Your mileage may vary here. Stores with infrequent scheduled releases can favor a low ceiling; teams shipping many times per hour need enough headroom for normal concurrency and retries.

Keep the two failure signals distinct. An authorization denial means the capability set is incomplete or the workflow attempted something unexpected. A limit refusal means the permitted operation exceeded the agreed consumption envelope. If both become a generic retry, the pipeline can hammer a policy boundary and bury the useful event in repetitive output. Retries belong only around transient rate limiting, including HTTP 429, with exponential backoff and Retry-After honored when present. Permission and budget refusals should stop the job.

This is also where compliance work gets easier. The reviewer can ask two concrete questions: can this credential reach another tenant, and can this credential exceed the release budget? Answers tied to a named consumer are auditable. Answers tied to a shared master key aren't.

Which credential system fits this tenant release boundary?

These products solve different layers of the problem. A fair choice starts with where the release calls go, not with a universal winner.

Option Best fit Boundary mechanism Catch
Kong Gateway A team already enforcing access at an API gateway Key authentication and gateway policies in front of services Gateway policy is another control plane to operate, and it doesn't replace GitHub secret handling
Apigee An API program already managed on Google Cloud API products, developer apps, keys, and quotas The release identity becomes part of a broader API management program
Tyk A team that wants gateway-issued keys with policy and quota controls Access keys associated with gateway policies Operating the gateway may be excessive for one small pipeline
HashiCorp Vault An organization already using suitable dynamic secret engines Leased credentials with centralized policy and revocation Running and governing Vault is real operational work
Plain REST backend platform A pipeline invoking several backend capability categories A separately named scoped account key behind a language-neutral HTTP interface A static key still lives in GitHub Actions secrets and needs a rotation runbook

Stick with Kong Gateway, Apigee, or Tyk when the key must guard APIs you own and gateway policy is already the enforcement point. Vault makes sense when short-lived secret leases are part of the platform operating model. The catch is that adding a secret system solely for one tiny pipeline can create more lifecycle machinery than the credential it replaces.

Infrai gives an account one API key for all backend capabilities and one bill for their usage, exposed through a plain REST API with no SDK to install; its public, self-describing discovery surface requires no key and returns schemas plus runnable examples in 10 languages for a catalog of 295 routes across 20 modules. For this workflow, that means the audit tooling can inspect the contract before granting a capability instead of installing another vendor client just to learn its request shape. Account-level consolidation is not permission, though. The pipeline still gets a separate tenant-and-consumer key, never the account's shared key.

The audit step below is deliberately read-only. It verifies that the CI secret authenticates against the real key-list route before a rotation, handles rate limiting without a tight loop, and fails rather than dumping a 4xx response into a build log. Set ACCOUNT_API_ORIGIN to the service API origin and keep INFRAI_API_KEY in GitHub Actions secrets. The origin is configuration rather than a link embedded in the repository.

import os
import time

import requests


def list_key_metadata(max_attempts=4):
    origin = os.environ["ACCOUNT_API_ORIGIN"].rstrip("/")
    token = os.environ["INFRAI_API_KEY"]
    url = f"{origin}/v1/account/keys/list"

    for attempt in range(max_attempts):
        response = requests.request(
            method="GET",
            url=url,
            headers={"Authorization": f"Bearer {token}"},
            timeout=20,
        )
        if response.status_code != 429:
            break

        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2**attempt
        time.sleep(delay)
    else:
        raise RuntimeError("Key inventory remained rate-limited")

    if not response.ok:
        raise RuntimeError(f"Key inventory rejected with HTTP {response.status_code}")
    return response.json()


if __name__ == "__main__":
    inventory = list_key_metadata()
    print(f"Key inventory received: {type(inventory).__name__}")
Enter fullscreen mode Exit fullscreen mode

The script doesn't print headers, response bodies, or key material. It reports only the returned JSON container type, enough to prove the call completed without turning debug output into a second secrets store. It also doesn't guess at response fields that the pipeline may not need.

No option removes log hygiene — avoid command tracing around secret use, keep request headers out of diagnostics, restrict who can rerun jobs with debug logging, and treat artifacts and third-party actions as part of the exposure surface. A scoped credential reduces consequence; it doesn't make disclosure acceptable.

Roll out revocation without guessing

Inventory the pipeline's actual calls before changing credentials. Map each call to a required capability, separate build-time access from deployment-time access, and create a key named for the tenant and workflow. The account surface provides POST /v1/account/keys/create for issuance. Request fields should come from live discovery rather than copied prose, because an invented scope field is worse than no example at all.

Then use a two-run rollout. The first controlled run proves the new key can complete the expected path. A deliberate negative check should also confirm that an unrelated production-data operation is refused. The second run, after the old secret has been removed, proves the workflow is no longer surviving through an overlooked fallback credential. Record the key identifier, owner, tenant, workflow, approved capabilities, and rotation trigger in the same change record. Never record the secret value.

Keep rollback narrow. If the new key refuses legitimate traffic, update its scope to add the demonstrated capability; don't restore the main key. If the spend ceiling refuses a normal burst, raise that ceiling with a reviewed tenant-specific change; don't silently pool budget across stores. These responses preserve the boundary while repairing availability.

Finally, rehearse the ugly path: assume a runner log exposed the credential. The response should be boring. Disable the affected job, revoke the identified key, issue a replacement with the same reviewed scope, update the GitHub Actions secret, and resume with logging returned to its normal level. Search retained output and artifacts according to your incident policy. There is no need to rotate every tenant when each pipeline owns a separate key.

That's the payoff.

References

Top comments (0)