Amazon QuickSight Adds Snowflake RSA Key-Pair Authentication for Passwordless BI Automation

Amazon QuickSight Adds Snowflake Key-Pair Authentication — Passwordless BI Done Right

TL;DR

  • Amazon QuickSight now supports RSA key‑pair (passwordless) authentication for Snowflake data sources—QuickSight authenticates with a PKCS#8 private key while Snowflake holds the matching public key.
  • Business impact: fewer leaked passwords, smoother automation for BI and GenAI pipelines, and better alignment with compliance and Zero Trust expectations.
  • Get started: generate RSA keys (OpenSSL), attach the public key to a Snowflake user, then create the QuickSight data source via console or the AWS CLI; optionally store secrets in AWS Secrets Manager for IaC and rotation.
  • Plan for governance: decide rotation cadence, per-service vs shared accounts, logging, and Secrets Manager + KMS policies before enterprise rollout.

Why this matters for business leaders

Passwords are the weak link in automated analytics. They force manual rotation, break CI/CD pipelines, and increase risk when stored in scripts or configuration files. Key‑pair authentication replaces fragile passwords with asymmetric cryptography, enabling reliable, non‑interactive access for dashboards, scheduled jobs, and model training pipelines. That reduces operational friction and lowers security risk—two outcomes that matter for decision velocity and auditability.

How key‑pair authentication works (high level)

Think of the public key as the lock and the private key as the only key that fits it. You put the public key on the Snowflake user account; QuickSight keeps the private key (PKCS#8 format) and uses it to authenticate. No username/password exchange is required. This is ideal for service accounts and machine-first workflows like scheduled ETL, GenAI fine-tuning jobs, and automated reporting.

Key-pair authentication replaces passwords with asymmetric cryptography so BI services can connect to Snowflake without relying on a username/password.

Prerequisites (what you need)

  • Amazon QuickSight account with appropriate admin or data‑source permissions.
  • Snowflake account and an admin role (ACCOUNTADMIN, SECURITYADMIN, or USERADMIN) to set RSA_PUBLIC_KEY on the target user.
  • OpenSSL available locally or in AWS CloudShell to generate keys.
  • Optionally: AWS Secrets Manager + IAM permissions + KMS key for secure storage and automated workflows.
  • Familiarity with Infrastructure as Code (IaC) and AWS CLI if you plan to automate the setup.

Step-by-step setup (engineer-friendly)

  1. Generate an RSA key pair with OpenSSL (PKCS#8 private key is required by QuickSight).

    1. Generate a base RSA private key:

      openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048

    2. Convert to PKCS#8 (optionally encrypted with a passphrase):

      openssl pkcs8 -topk8 -in private_key.pem -out private_key_pkcs8.pem -v2 aes-256-cbc -passout pass:YOUR_PASSPHRASE

      Note: If you encrypt the PKCS#8 private key, store the passphrase in Secrets Manager so QuickSight can use it programmatically.

    3. Extract the public key:

      openssl rsa -in private_key.pem -pubout -out public_key.pem

    4. Format the public key for Snowflake: remove the —–BEGIN/END PUBLIC KEY—– headers and collapse line breaks into a single line (Snowflake expects a one‑line string).
  2. Attach the public key to a Snowflake user (run as ACCOUNTADMIN/SECURITYADMIN/USERADMIN):

    ALTER USER your_quicksight_user SET RSA_PUBLIC_KEY = ‘ONE_LINE_PUBLIC_KEY_STRING’;

    Validate with: DESCRIBE USER your_quicksight_user;

  3. Create the QuickSight data source

    • Console: Create data source → Select Snowflake → fill host/database/warehouse/role → Authentication Type = KeyPair → paste the full PKCS#8 private key (including PEM headers) and passphrase if used → Validate and Create.
    • AWS CLI example (sanitized skeleton):

    {“AwsAccountId”:”ACCOUNT_ID”,”DataSourceId”:”DATA_SOURCE_ID”,”Name”:”MySnowflakeDS”,”Type”:”SNOWFLAKE”,”DataSourceParameters”:{“SnowflakeParameters”:{“Host”:”.snowflakecomputing.com”,”Database”:”DATABASE”,”Warehouse”:”WAREHOUSE”,”Role”:”ROLE”}},”Credentials”:{“CredentialPair”:{“Username”:”QUICKSIGHT_USER”,”Password”:null},”KeyPairCredentials”:{“PrivateKey”:”“,”Passphrase”:”“}}}

    Run: aws quicksight create-data-source –cli-input-json file://payload.json –region YOUR_REGION

Automation and IaC patterns

For production, avoid pasting private keys into templates. Use AWS Secrets Manager (encrypted with a KMS key) and reference the secret ARN from your IaC templates or automation scripts. A common pattern:

  • Store PKCS#8 private key and passphrase in Secrets Manager (restrict access via IAM and resource policies).
  • Grant QuickSight (or the automation role creating the QuickSight resource) read access to that secret.
  • Provision the QuickSight data source with the KeyPairCredentials populated from Secrets Manager at deployment time.

Rotation workflow (outline):

  1. Generate new key pair in a secure environment (CI job or admin workstation).
  2. Update Snowflake user with the new public key (use ALTER USER).
  3. Update Secrets Manager secret with the new private key and passphrase.
  4. Trigger an automated validation job that recreates/validates the QuickSight data source or updates its credentials.
  5. Keep the old key active until validation passes, then retire it.

Automate these steps with a Lambda or CI pipeline and log each step to CloudTrail and your SIEM for auditability.

Security and governance recommendations

  • Never store private keys in source control or unencrypted file shares.
  • Use AWS KMS to encrypt Secrets Manager secrets and tie access to IAM roles with least privilege.
  • Decide key scope: per-service/per-environment keys (recommended for isolation) vs. a shared service account (simpler but higher blast radius).
  • Suggested rotation cadence: 90–365 days depending on compliance; if you can automate rotation safely, favor shorter cycles.
  • Network hardening: use VPC endpoints/PrivateLink for private Snowflake connectivity where required by data governance.
  • Observability: enable CloudTrail for AWS API access, Snowflake access logging, and forward logs to a central SIEM to correlate QuickSight activity with Snowflake access events.

Troubleshooting & common gotchas

  • Creation fails with authentication errors

    Check that the private key is PKCS#8 formatted and includes PEM headers. If you encrypted the key, verify the passphrase is stored correctly and accessible to the provisioning role.

  • Snowflake rejects the public key

    Ensure the public key string is headerless and single-line. Any leftover newlines or header text will cause Snowflake to ignore the key.

  • QuickSight reports CREATION_IN_PROGRESS for too long

    Confirm QuickSight can reach Snowflake endpoint (network, region, VPC endpoints). Also verify the Snowflake user, role, and warehouse names are correct and grants exist.

  • Permission denied reading Secrets Manager

    Validate IAM policies attached to the role/user executing the CLI or QuickSight API and ensure the Secrets Manager resource policy allows the action.

What to test in your POC

  1. Create a dev Snowflake user and attach a public key.
  2. Create a QuickSight data source using a PKCS#8 private key (console first, then CLI).
  3. Store the private key and passphrase in Secrets Manager and modify your IaC to read from it.
  4. Run a scheduled query (or dashboard refresh) to confirm the end‑to‑end pipeline.
  5. Simulate rotation: generate a new key, update Snowflake and Secrets Manager, validate without downtime, and record timing.
  6. Verify logging: can you link a QuickSight access event to Snowflake activity in your SIEM?

For product and BI leaders

Expected impact: fewer incidents caused by expired or leaked passwords, faster onboarding of automated reporting and AI pipelines, and better posture for audits. Pilot timeline: 2–5 days for a proof of concept (dev Snowflake + QuickSight), 2–6 weeks for enterprise rollout including automation, rotation, and logging integration depending on organizational complexity.

Final thoughts

Enabling RSA key‑pair authentication for QuickSight → Snowflake is a practical, high-value change: it removes brittle human credentials from machine workflows and unlocks more reliable automation for analytics and AI. The feature is straightforward to adopt technically; the heavier lift is governance—deciding how keys are issued, rotated, audited, and networked. Plan those policies up front, automate what you can, and treat the private key like the critical secret it is.

Quick checklist (day-one)

  • Generate PKCS#8 private key and public key with OpenSSL.
  • Attach public key to a Snowflake user and validate with DESCRIBE USER.
  • Create QuickSight data source using KeyPair auth via console or AWS CLI.
  • Move private key and passphrase into AWS Secrets Manager (KMS‑encrypted).
  • Implement automated validation and a rotation playbook.
  • Enable CloudTrail and Snowflake logging; forward to SIEM.

“You can configure the connection interactively in the QuickSight console or automate deployments using the AWS CLI and Secrets Manager for credential storage.”

Contributors: Vignessh Baskaran (Sr. Technical Product Manager, QuickSight), Chinnakanu Sai Janakiram (Software Development Engineer, QuickSight), Nithyashree Alwarsamy (Partner Solutions Architect, AWS), Andries Engelbrecht (Principal Partner Solutions Engineer, Snowflake).

0