Runtime-Generated Short-Lived Harness API Tokens for CI Pipelines
pending feedback
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
P
Probable Kite
ompragash
I’ve just found this documentation and have also submitted a support request to clarify whether the feature flag described there only enables the function for the "Agent CI Step".
If this is the case, I would ask that someone on your side checks whether the approach from the Agent Step can also be enabled for the Run Step / a CI Step Template. Essentially, this involves a permissions specification in which we can define the short-lived token permissions for the CI step.
P
Probable Kite
In my opinion, using a dedicated service account would be fine as long as we don't have to generate a static key.
What we want to avoid are static secret tokens/API keys that aren’t properly rotated or deleted.
That’s the crux of the matter and the reason why I compared the situation a bit to GitHub, but this would also apply to other CI products on the market.
Because once we start using static tokens, it’s very hard to get rid of them.
I also looked at the Access level of the internal DRONE_CI JWT Token. Which would be an alternative way to look at this. Because somehow we clone the Harness Code Repo inside a CI init step right? But why can´t i control the access level of this CI token?
Some sort ephemeral token mechanism with an level of access control is clearly missing in my opinion.
ompragash
marked this post as
pending feedback
ompragash
Thanks for the detailed request. Today this can be done in a CI Run step by storing a Harness API key, usually a service account token, as a Harness secret and calling the Harness API directly with x-api-key.
The IDP pattern you referenced is similar: it can create a temporary Harness secret, pass the generated secretId to a pipeline runtime secret input, and then attempt to delete the secret afterward. However, it still depends on a stored Harness API key, and cleanup is not guaranteed if the pipeline fails.
Can you confirm that the main requirement is to avoid storing a long-lived Harness API key in the pipeline/IDP workflow, and instead have Harness issue a native short-lived token at runtime that is scoped to the pipeline execution and expires automatically when the run ends?
Also, should that runtime token inherit permissions from a selected service account, or should it be limited to the current pipeline/project execution context?