Skip to main content
How-to guideApplies to: Unified engine deployments
Choose the exact system and authentication method you need. Each recipe connects one service, runs a small read to verify access, and lists its local cleanup. External services and identities must already exist.

​
Catalog connections

​
File access

​
AWS identities

​
Google Cloud identities

​
Azure identities

​
Secret providers

​
More access recipes

​
Credentials

​
Running the SQL

Run statements in order in Workbench, or through another SQL client. Keep session-local views and their queries in the same session. Replace strings such as <access-key-id> and example service URLs before running a statement. Use unused names for the resources created by a recipe. When changing an AWS Region, update the S3 endpoint to match it. Give each storage connection its own endpoint. A local MinIO endpoint does not provide access to an AWS bucket. The engine must have its secrets and credentials services available. Local secret values also need the encrypted secret store and its persistent <storage_root>/secrets/master.key. See Secrets configuration. A recipe’s setup text describes work done outside SQL. This includes creating AWS resources, granting permissions, installing identity bindings, and configuring external secret-provider aliases. SQL creates the engine’s saved resources and uses those existing services. It does not create AWS keys, IAM roles, remote secrets, or Kubernetes identity associations. Catalog recipes read an existing table selected by the reader. File recipes use an existing configured input or the small fixture described on the page. Some earlier access recipes use TPC-DS scale-factor 1 (SF1) data. These reads do not write to the source dataset. A final SELECT checks actual data access. SHOW and DESCRIBE show metadata, not secret plaintext or acquired tokens. Cleanup removes only the local resources named in that recipe.
Last modified on November 4, 2026