How-to guideApplies to: Unified engine deployments
Create a named reference and use its value through a matching credential.
Before you start
Have an administrator configure the engine provider alias recipe_vault before
running SQL. Configure type vault with the KV v2 mount, API address, and
optional namespace. Set an authorized API token in VAULT_TOKEN or the variable
named by token_env. The returned data object must be a supported document for
its consumer. See
provider configuration.
Store an AWS JSON credential bundle as the KV v2 data object, with
aws_access_key_id and aws_secret_access_key, plus aws_session_token when needed.
The provider returns the complete data object as JSON, so use the saved AWS
bundle field. Use an existing nonempty Parquet dataset and a configured S3
file-source root covering its prefix. A credential does not authorize an
arbitrary storage root. The identity needs list/read access to the bucket and
actual files, plus KMS decrypt permission when needed. Use the region and HTTPS
endpoint for that bucket. Keep the temporary view and its SELECT in the same
Workbench workspace. Use a real existing version. The version must hold valid
access material; pinning does not extend its lifetime.
Values to collect
- A configured provider alias, secret identifier, existing version, and the data
connection values shown below.
Run the SQL
Replace every <placeholder> before running. Use unused names for the resources
below. Run the statements in order in Workbench.
Check the result
DESCRIBE shows the provider reference and selected version, not its plaintext
value. The SELECT should return actual table or file rows and proves that the
consumer can resolve and use the selected secret.
Clean up
This removes the local references and view, without deleting the remote Vault
secret.
Last modified on November 4, 2026