Runtime-Generated Short-Lived Harness API Tokens for CI Pipelines
P
Probable Kite
Summary
Harness currently lacks a native mechanism to generate ephemeral, short-lived API tokens at pipeline runtime — comparable to GitHub Actions' GITHUB_TOKEN or the OIDC-based tokens available for GCP and Azure in Harness CI.
Reviewed Documentation & Why It Is Insufficient
- API Keys & Token Expiry
Harness allows setting an expiration date (30, 90, 180 days or custom) when creating a token. However, this is a statically configured expiry, not a dynamically generated short-lived token. The minimum API key duration is 30 days. This does not meet the requirement for tokens that are valid only for the duration of a single pipeline run.
- Delegate Token Revocation
Delegate tokens can be created with a revokeAfter epoch timestamp via API. However, this mechanism is scoped to delegate authentication only and is not applicable to general CI pipeline use cases.
- IDP Create/Delete Secret Pattern
The IDP workflow pattern allows creating a Harness secret before a pipeline run and deleting it afterward using harness:create-secret and harness:delete-secret actions. This is a workaround, not a native solution — and explicitly noted in the documentation that if a pipeline step fails, the secret is not automatically cleaned up, requiring manual deletion.
- Token Rotation [Rotate tokens]
Token rotation is a manual process and does not provide runtime-scoped ephemeral tokens.
What Is Needed
A native Harness CI mechanism to generate a short-lived, pipeline-scoped token at runtime that:
Is automatically invalidated when the pipeline run ends.
Requires no manual cleanup.
Can be used to authenticate against the Harness API within the same pipeline run.
Is comparable to GitHub Actions' GITHUB_TOKEN or the existing OIDC plugins for GCP
and Azure
Log In