Data Source Secret Storage Provider
Data Source Secret Storage Provider stores encrypted secret payloads in an Agent-managed database selected through a Data Source component.
Use a database with an explicit ownership boundary
Start a Data Source first, then configure this provider with that active data source and a master password. When Create if missing is enabled, the provider creates its own verifier record on first start. Secret rows are scoped to the provider UUID, so more than one provider can use the same database without sharing an alias namespace.
Choose the database role
Use a dedicated database or schema where possible. The selected Data Source must be able to persist the secret-store entity and maintain the required table.
Set the master password
This password opens the store and is required again for UI reveal through Secret Manager. It must match an existing store.
Attach Secret Manager
After the provider starts successfully, choose it as the backing store in Secret Manager.
Configuration parameters
| Parameter | Required | Description | Default |
|---|---|---|---|
Title | Yes | Display name of the provider. | Database Secret Storage |
Master password | Yes | Password that establishes and unlocks the store. Changing it restarts the provider; it must match the existing verifier. | None |
Data source | Yes | Active Data Source used for persistence. Changing it restarts the provider and points it to a different database boundary. | None |
Create if missing | Yes | Initialises the selected store when its verifier is absent. Disable when the store must already exist. | Enabled |
Use a database without making it a plaintext vault
The provider writes secret payloads as AES-256-GCM ciphertext in the secret_store table. Alias, provider UUID, type, name, description, format and update time remain queryable metadata. A special provider-scoped verifier is used to confirm the master password before stored secrets can be opened.
The implementation uses an unbatched write path for large payloads and checks older table layouts for an undersized payload column. It can widen an older Derby payload column through a temporary-column migration. Database backups, replicas and administrators therefore still require the same governance as any other system that holds encrypted security material and visible secret metadata.
Provider scope
Rows are scoped by the provider UUID, allowing independent stores in one database.
Encrypted material
Only encrypted payload is persisted; the Data Source does not receive a plaintext secret column.
Database controls
Apply backup, access, retention and audit controls to the database and its replicas.
Prepare for backup, restore and schema ownership
Use least-privileged database access
The Data Source account should have only the permissions needed to maintain and use the designated schema. Separate secret storage from unrelated application data where policy requires it.
Coordinate schema policy
Ensure the Data Source schema mode and database ownership model permit the secret-store table and required migrations. Test this before production deployment.
Restore consistently
Restore the database with the correct master password and Agent configuration. Restoring only one of those elements does not recreate a usable secret store.
Do not edit rows manually
Create, update and delete secrets through Secret Manager. Manual changes to ciphertext, verifier or provider scope can make entries unavailable.