Skip to main content
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