Secret Stores

Secret Stores are configured per Domain. There is no separate organization or User Settings page for registering Secret Stores.

The Data Platform decides which Secret Stores you are offered, and preselects its default:

A Domain's Secret Store must be readable by its production runs. Internal and Local File can be read only by your Agent, so they are offered for DuckDB-local alone.

Store	Offered for	Preselected for
Internal	DuckDB-local	DuckDB-local
Local File	DuckDB-local	none
Azure Key Vault	Fabric Lakehouse and Fabric Warehouse	Fabric Lakehouse and Fabric Warehouse
Databricks Unity Catalog secrets	Databricks	Databricks
MotherDuck Flight Secrets	MotherDuck	MotherDuck
AWS Secrets Manager	Redshift, once an administrator enables it	none
Google Secret Manager	BigQuery, once an administrator enables it	none
No Secret Store	Redshift, BigQuery and Snowflake	Snowflake; Redshift and BigQuery until their store is enabled

Databricks and MotherDuck have no in-container run, so only their own store works there: every run executes in the platform's own workspace, which reads nothing else.

No Secret Store holds nothing. Sources that need credentials aren't supported on that Domain yet; sources that need none still work.

Enabling AWS or Google Secret Manager only affects new Domains. A Domain already bound to a store keeps it, and the picker keeps showing it, even if its platform no longer offers it; an advisory says so. Optional connection reuse depends on compatible credentials; it does not widen which stores are offered.

MotherDuck Flight Secrets serves a MotherDuck Domain only, holds no credential of its own, and lists the flights secrets of the account the Domain's MotherDuck token opens — the names a Flight run reads.

Databricks Unity Catalog secrets serves a Databricks Domain only, holds no credential of its own, and binds the catalog and schema where the Domain's secrets live. It needs no Identity Provider of its own. Unity Catalog secrets belong to the metastore, so one catalog and schema serve every workspace attached to it, production and Ephemeral alike. Vibedata lists the secret names with your Databricks connection and never reads a value: a Databricks pipeline runs as a Databricks job, and that job reads each secret with dbutils.secrets.get(catalog=, schema=, key=).

Vibedata grants nothing. The Domain Owner creates each secret and grants READ SECRET on it, per secret, to the people who run against it and to the Domain's service principal; both also need USE CATALOG and USE SCHEMA on the schema. Grant READ SECRET, never REFERENCE SECRET, to people who run sandboxes: a secret held with either privilege appears in the listing, but only READ SECRET lets a job read the value. A secret you hold no privilege on does not appear in your listing, and the Open check reports it by name when the Domain's service principal can see it; ask the Domain Owner to grant it. Vibedata cannot detect a REFERENCE SECRET-only grant, so it shows up when the sandbox run fails. What you and the agent running as you can read is whatever you hold READ SECRET on.

Name a secret in lowercase letters, digits, _ and - (up to 255 characters): a dotted key such as sources.sf_prod.client_id is held as sources__sf_prod__client_id.

Databricks secret scope (the workspace secret scope) is legacy and is no longer offered for a new Domain. A Domain already bound to one keeps working and shows an advisory. To move, create the secrets in a Unity Catalog schema, grant READ SECRET, then choose Databricks Unity Catalog secrets in the Domain's settings; Vibedata does not copy values.

How to choose a Secret Store for a new Domain

1. Open Domains from the global application rail.
2. Select Add domain.
3. Complete Basics, including Repository, and Data platform, including Workspace. On Secret store, keep the preselected default for your platform or choose another store it offers.
4. For Azure Key Vault, complete Authentication. User connection and service identity are independent choices; Reuse data platform connection appears only when the corresponding requirement is compatible. Dedicated identity alone requires separate Client ID and Client secret. Ambient mode uses the host Azure identity and requires Azure tenant ID instead.
5. For Azure Key Vault, select Continue to vault. Choose a discovered vault or explicitly commit a supported canonical Resource ID through the same editable dropdown. Vibedata derives the read-only Vault URL. Reopen Authentication through its header without losing compatible draft values. Internal and Local File skip this step.
6. Confirm the safe Domain summary, then select Create. Vibedata opens General and reconciles applicable saved service and resource readiness after saving.

Local File, when you choose it, requires no configuration in this form. Secrets are supplied outside Vibedata; Vibedata does not create or edit that file.

Internal also requires no external identity or resource. After saving the Domain, use Secrets to manage its Internal inventory. Your Agent can discover active secret names in the selected Domain without receiving their values. Archived names are excluded; a listed name may still need a value before it can be used.

Use the vault dropdown's filter to find a vault by any case-insensitive part of its displayed name. Filtering does not alter the saved vault selection, and deleting the filter restores the discovered options. No matching options is different from discovery returning no vaults, still loading, failing, or reporting a truncated result.

How to change a Domain's Secret Store

1. Open Domains and select the Domain.
2. Open Resources, then expand Secret store.
3. Under Secret store type, choose Local File, Azure Key Vault, or Internal and complete any displayed resource and identity fields.
4. Select Save. Vibedata does not copy secret values when the Secret Store changes.
5. Select Reconcile after saving when you want to refresh the saved service-readiness result.

Selecting Internal in an unsaved draft shows Save to enable the Secrets tab. The tab appears after saving, if you have permission to read secret metadata. Switching away hides Secrets but retains the Internal inventory and every version. Switching back restores access; no values are migrated or deleted.

How to manage Internal secrets

1. Open the Domain's Secrets tab.
2. Select Add secret. Enter Secret name using letters, numbers, or hyphens (1–127 characters). Names are case-insensitive.
3. Enter Secret value. Multiline and empty values are allowed, up to 25 KiB in UTF-8. Saved values cannot be viewed, revealed, or copied from this screen.
4. Set Enabled, Not before, and Expires as needed. Dates use the local timezone shown in the form and are set to the minute. Leave a date blank for no restriction.
5. Select Create. The inventory shows its status and version count.

An imported name with no value shows Needs value. Select Set value to configure its first value.

How to see versions and edit properties

1. Select Manage on a secret to open Versions. The table identifies the Latest version and shows each version's creation date, Enabled state, and date restrictions. Dates read YYYY-MM-DD HH:mm in your local time.
2. Select Add version, enter the new Secret value, then select Save. Saving a value creates another version; it does not replace the history.
3. To change a version without changing its value, select that row's Edit properties. Update Enabled or the date restrictions, then select Save. Clearing an existing date removes that restriction without adding a version.

How to archive, restore, or delete a secret

1. Select Archive, then confirm Archive. All versions and properties are retained.
2. Select Archived to find it. Use Manage to inspect its retained versions, or select Unarchive and confirm to restore it.
3. To remove an archived secret and every version irreversibly, select Delete permanently and review the confirmation. Cancel leaves it unchanged.

What you'll see

• An empty Active inventory says No active secrets. Add a secret to get started.
• Search secrets filters the returned records. When the collection limit is reached, counts include a plus sign and a notice explains that search results and version lists are partial. Refresh checks the current bounded set.
• Refresh reloads metadata. Failed reads offer Retry and disclose that loaded records may be incomplete or stale; a failed read is not an empty inventory.
• A failed save retains your draft. After a conflicting change, select Refresh metadata for review, review the displayed metadata, then select I reviewed the refreshed metadata before saving again.
• Leaving a changed form asks Discard unsaved changes? Use Keep editing to retain the draft, or Discard changes to leave without saving.
• Secret-management permissions are separate from permission to edit Domain settings. Read-only access disables mutations. Domain lifecycle restrictions can also prevent changes; an archived Domain's metadata may be unavailable.

How to manage your connection

If Discover Key Vaults in Domain creation asks you to sign in again (multi-factor or Conditional Access), select Open connections. It opens User settings → Connections in a new tab, so your Domain draft stays in the original tab; reconnect there, return to the draft and select Retry.

Open User settings → Data platforms and select the connection used by your Azure Key Vault requirement. Select Connect or Reconnect to authorize the required identity, or Disconnect to remove the stored credential after reviewing every affected Domain and requirement.

Local File, Internal, and ambient identities appear as shared access sources. They do not offer personal Connect or Disconnect actions; sources that require no credential show Not required. A credential reused by Data Platform and Secret Store requirements appears once, with each affected Domain listed once in its details.

Quick reference

Control	What it does
Secret store type	Chooses one of the stores its Data Platform offers for one Domain (for example Local File or Internal on DuckDB-local, Azure Key Vault on Fabric).
Secrets	Manages the saved Internal inventory; does not manage Local File or Azure Key Vault values.
Manage	Opens retained versions and their properties without retrieving saved values.
Reconcile	Re-checks Domain-wide provisioning, both saved service identities, and your own User identity, live, for every non-terminal Domain lifecycle state (not offered while locked, archiving, or archived).
Connections	Manages personal credentials required by Domain Data Platform and Secret Store requirements.

Related

• Domains
• Connections