CV_Auth Credential Vault

The Credential Vault (CV_Auth) is a first-class store for the secrets your workflows depend on — third-party API keys, bearer tokens, basic-auth username/password pairs, AWS access keys. You save a credential once; functionals reference it afterward by id or by a stable alias. The plaintext secret is encrypted at rest, redacted on every read, and never sent back to the browser or embedded in a model definition — only a reference to it is.

Why a Credential Vault

Before the vault, a secret a workflow needed either lived in plain sight on a functional’s input or had to be re-entered every time it was used. The vault fixes that: create the credential once, hand out access to it like any other brewlytics resource (an ACL), and let functionals resolve it by reference at run time. The functional’s author never sees the secret, the model that uses it never stores the secret, and the browser that configured it never receives the secret back — only a masked hint (e.g. ****90AB) so you can recognize which credential you’re looking at.

Credential Types

Which fields a credential needs — and which of those fields are encrypted versus stored in the clear — depends on its type:

Type	Fields
API Key	apiKey
Bearer Token	token
Basic (HTTP)	username, password
Username / Password	username, password
AWS Keys	accessKeyId, secretAccessKey, sessionToken (encrypted) + region (stored in the clear)

The type list itself comes from a server-side registry rather than being hard-coded into the UI, so the Type step of the create wizard always reflects what the running server actually supports.

Creating a Credential

You can create a credential from two places: the admin Credentials console (system-wide — visible to every admin, namespaced under sys) or your own Profile → Auth Credentials tab (personal — scoped to your own namespace, for credentials only you manage). Either way, creating one walks a 3-step wizard:

1. Type — pick one of the registered credential types. This can’t be changed once the credential is saved.
2. Details — a label, an optional description, an optional Service tag (see below), and the type’s own fields: secret fields render as masked password inputs, non-secret fields as plain text. From the admin console you can also set a stable alias — a name functionals can reference instead of the raw id; alias changes are admin-only and each alias must be unique.
3. Sharing — opens the ACL editor so you can set who else can read, update, delete, or use the credential.

Editing an existing credential skips straight to the Details form in a focused modal — sharing is a separate “Share” action on the credential’s row, so a small edit like renaming a credential doesn’t force you back through the stepper. To rotate a secret, leave its field blank to keep the currently stored value, or type a new one to replace just that field — the other secret fields on the same credential are left untouched.

If a credential is tagged with a Service, your first credential for that service automatically becomes your default for it, and you can flag a different one as the default at any time. Functionals that target a service can then resolve “the calling user’s own credential for this service” instead of one credential shared by everyone.

Using a Credential in a Functional

A functional that needs a third-party secret exposes a CV_Auth input. On the Build canvas, that input’s property editor only lists credentials you’re allowed to use (see Sharing & ACL below) — narrowed further to the type the input requires, and, if the functional targets a specific service, to credentials tagged with that service. When a service is set, you choose between picking a specific credential or binding to “my default,” which resolves to whichever credential the user running the model has set as their own default for that service — so a shared model can run under each collaborator’s own key instead of one hard-coded credential. You can also create a brand-new credential inline from the picker without leaving the canvas.

At run time, the platform re-checks that the running user may use the referenced credential, decrypts it, and hands the functional its fields — the secret is never written into the model definition or returned to the browser, only the credential’s id or alias is. Every resolution is recorded as an audit event, so credential use is traceable back to the functional, model, and job that triggered it.

Sharing & ACL

Every credential carries the same kind of access-control list as other brewlytics resources — separate grants for who can read, update, delete, or use (execute) it. “Manage sharing” from either the wizard or a credential’s row opens that ACL editor directly.

A credential shows up as usable to you — in the canvas picker and via the API’s usable=true filter — if any of the following is true: you own it, you’re an admin, it’s been shared with everyone, or you (or a group you belong to) hold explicit execute access to it. Owning and admin access don’t require an ACL entry at all; everything else does.

Programmatic Access

Credentials can be created, searched, updated, and deleted through the REST API as well as the UI — list and single-item responses redact the encrypted secret the same way the UI does. See the auths tag on the API Reference page for the full endpoint and schema documentation.