Store and Access Sensitive Information Securely

Secrets let you store sensitive values (API keys, passwords, certificates) outside your flow definitions and inject them at runtime via the secret() function.

How secrets are stored depends on your edition. Enterprise Edition connects to a dedicated Secrets Manager backed by AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or Kestra’s own store. Open-Source has no secret store — secret() reads a base64-encoded environment variable instead.

Enterprise Edition

Secrets are the right choice for static sensitive values: API keys, passwords, webhook URLs, certificates, and long-lived tokens. For reusable server-to-server authentication — where Kestra needs to mint or refresh short-lived tokens at runtime — use Credentials instead. Credentials can reference secrets for sensitive inputs such as client secrets and private keys.

Secrets are available under Namespaces → [namespace] → Secrets or under Tenant → Secrets in the sidebar. Click New secret, set a key name such as MY_SECRET, and optionally add a description and tags. From the same tab you can edit, delete, or copy a secret as a Pebble expression — for example, "{{ secret('API_TOKEN') }}" — ready to paste into a flow.

For available backends, see the Secrets Manager page. For best practices, see Secrets management and Choosing where to store sensitive and shared values.

Reading secrets from another namespace

By default, secret() reads from the flow’s own namespace. You can pass a namespace argument to read a secret stored in a different namespace:

tasks:
  - id: use_shared_secret
    type: io.kestra.plugin.core.log.Log
    message: "{{ secret('SHARED_TOKEN', namespace='shared.secrets') }}"

The secret resolves using the target namespace’s own backend, so a flow can read a value from a namespace backed by a different secrets manager. Cross-namespace reads stay within the same tenant. Access is allowed by default; restrict it by configuring allowedNamespaces on the target namespace.

Secrets in Open-Source

Open-Source has no dedicated secret store. Kestra reads base64-encoded environment variables prefixed with SECRET_ and exposes them via the secret() function. This keeps sensitive values out of flow YAML, but offers no encryption at rest, no audit trail, and no access control beyond what your host environment provides.

See Configure secrets in Kestra (OSS) for step-by-step instructions on encoding values and wiring them into your Docker Compose file.