Secrets

Vault-backed references for connection credentials.

BARRY keeps credentials out of your configuration. Every connector secret is encrypted at rest and is never returned to the browser — when you edit a connection you leave a secret field blank to keep the stored value. On top of that, you can keep secrets in an external vault and reference them from any connection instead of storing a literal value at all.

Supported vaults

• Azure Key Vault
• HashiCorp Vault

The vault is optional. Until one is configured, connections simply store their (encrypted) secrets directly.

Enabling a vault

Configure the provider under Settings → Runtime (the Vault / Secrets section): pick the provider and fill in its connection details. Once a vault is configured, a Secrets entry appears in the sidebar — this happens immediately after you save, no page reload required.

The Secrets page

The Secrets page browses the names stored in the configured vault and lets an administrator add, update, and delete them. A few rules:

• The secret value is never displayed or retrievable through the UI — you can set or replace it, but not read it back.
• Each row offers Copy reference, which copies an @kv("…") reference (see below) to the clipboard.
• Where the provider supports it, an expiry status is shown so you can spot secrets that are about to lapse.
• Anyone may browse; create / update / delete require the Admin role.

Referencing a secret — @kv(...)

Anywhere a connection asks for a secret, you can enter a reference instead of a literal value:

• @kv("my-secret") — the latest version
• @kv("my-secret", "version") — a pinned version

The reference is resolved server-side at run time; the literal value never travels to the browser and never lands in your configuration. This is also what makes a connection safe to version in Git — see Git integration, where a connection holding a literal secret is flagged as a readiness violation and blocks export.

See also Connections and the Connector Catalogue.