Menu AuthGuardHelp centre
Portuguêsauthguard.pt

Administrators · Privileged access (PAM)

Application secrets for applications and CI pipelines

  • 2 min read
  • SaaS · Self-hosted

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?

KindExample
PasswordA database or service account password
API tokenA payment provider's key
Key-value setSeveral 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.
Article referencead-pam-app-secretsquote it to support to identify this article. Checked against the product at commit 78c33b39.