Administrators · Privileged access (PAM)
Application secrets for applications and CI pipelines
Not available yet
This article describes a feature in development. You cannot use it yet; the article is here to help you plan.
Application secrets let your applications and CI pipelines fetch passwords, API tokens and configuration values from the privileged access vault when they need them, instead of keeping a copy in a file or in the pipeline's settings. Nobody stores a long-lived password for the pipeline itself: it proves who it is with the identity its platform already gives it.
Is it available?
Not yet. The command-line tool and its protocol are in the product, but the console screens and the API that serve the secrets are still in development. This article describes how it will work.
What can be stored?
| Kind | Example |
|---|---|
| Password | A database or service account password |
| API token | A payment provider's key |
| Key-value set | Several related values, such as host, user and password (up to 16 KiB) |
Secrets live in the same vault as privileged credentials: each change creates a new version, sealed with your organization's key, and after a rotation the previous version keeps working for an overlap period (7 days in the current design), so applications can move to the new one.
How does an application prove who it is?
You register a workload identity:
- GitHub Actions, GitLab or Kubernetes. The platform's own signed identity token is accepted when it matches a rule you set, for example a repository, a branch and an environment. Rules on the branch are always exact, a GitHub rule must name the repository owner and a GitLab rule the namespace, and pull request runs are refused unless you allow them. The console warns about broad rules.
- A registered key. For servers outside those platforms, the application signs with its own Ed25519, ES256 or ML-DSA-65 key. RSA keys are refused.
You then bind the workload to the secret names it may read, with a maximum lease (from 1 minute to 12 hours; 1 hour by default).
What protects the secrets in transit?
- The identity token is exchanged for an access token of 5 minutes, bound to a key that never leaves the job.
- Each secret is sealed to that job's own key with hybrid post-quantum encryption, so a proxy that inspects TLS cannot read it.
- Every read is audited, secret by secret.
Good practice
- One workload per pipeline and environment; never one identity for everything.
- Pin production secrets to the production branch and environment.
- Rotate on a schedule, and right away if a secret may have leaked. See Credential rotation.
Was this page helpful?
Thank you. Your answer stays in this browser; nothing is sent.
Sorry about that. Try:
- searching for the exact text of the message or the error code
- the error code index
- asking your organization's administrator