How-to guideApplies to: Unified engine deployments
Use a local secret name for a client secret held in AWS. The local resource
contains a reference; the value stays managed by the external provider.
Prepare the external source
Have an administrator create Secrets Manager secret
/laminar/recipes/polaris-client-secret containing the raw Polaris client secret
as its SecretString. A JSON wrapper is not selected automatically.
The engine’s secret-service identity needs secretsmanager:GetSecretValue and,
for a customer-managed key, kms:Decrypt.
Configure engine provider alias recipe_sm with type aws-secrets-manager.
Set its optional region and profile. Supply the AWS SDK identity through the
secret-service process environment or its workload identity. For Pod Identity,
the SDK uses the Pod’s container credential settings. For IRSA, it uses the role
ARN and mounted web identity token file. Grant this identity access to the secret.
Load this provider configuration before running the SQL. See
Secrets configuration.
Use an existing Polaris catalog with a retail warehouse and the SF1 item
table in namespace tpcds_sf1. Replace the example URLs, client ID, warehouse,
namespace, and Region with your values. The Polaris client needs access to the
warehouse and table. These examples request PRINCIPAL_ROLE:ALL; use the scope
granted to your client.
For the final SELECT, Polaris must supply usable temporary S3 credentials for
the table. Otherwise attach a separate storage credential as shown in
Separate catalog and storage credentials.
A successful login or table listing alone does not prove S3 access.
AWS documents the required permissions in GetSecretValue.
Create the reference and query data
The reference uses the configured alias, not an automatically registered AWS
provider name. A successful SELECT confirms the reference can resolve, OAuth
can obtain a token, and the table files can be read.
Remove the local resources
This does not delete the AWS secret or parameter.Last modified on November 4, 2026