Snowflake
Databasessystem_type: "snowflake"Proxy Snowflake SQL queries with PQC-sealed key-pair authentication. Sensitive columns can be tokenized before landing in Snowflake.
Overview#
The Snowflake connector proxies SQL queries to Snowflake Data Cloud. Key-pair authentication private keys are sealed in QuantaVault and wrapped by AWS KMS. PII columns can be tokenized by QuantaSeal before data lands in Snowflake, allowing you to run analytics on tokens rather than raw PII.
https://api.quantaseal.io/api/v2/proxy/outboundAuth header:
X-API-Key: qs_live_...Prerequisites#
- 1A Snowflake account and warehouse
- 2A Snowflake user with key-pair authentication configured (RSA key pair generated, public key uploaded to Snowflake)
- 3Account identifier, username, warehouse, database, schema
- 4A QuantaSeal API key
Configuration#
Follow these steps to connect Snowflake to QuantaSeal. You can configure integrations via the Admin Console or directly via the API.
- 1
Generate an RSA key pair: openssl genrsa -out snowflake_key.p8 2048
- 2
Upload the public key to the Snowflake user: ALTER USER myuser SET RSA_PUBLIC_KEY='...'
- 3
Seal the private key: POST /api/v2/vault/seal with credential_type: database_dsn and the Snowflake connection parameters.
- 4
Create the integration: POST /api/v2/integrations with system_type: snowflake.
Authentication Types#
Use database_dsn to store Snowflake connection parameters including the private key path. For OAuth2, use oauth2_client with the Snowflake OAuth2 security integration credentials.
All credential types are sealed in QuantaVault with ML-KEM-768 + AES-256-GCM and wrapped by your tenant AWS KMS CMK before storage. See the Vault API reference for the full list of credential types and seal/unseal endpoints.
Available Operations#
QuantaSeal enforces a default-deny operation policy. Only operations listed in your integration's allowed_operations array will be permitted. Add operations when creating or updating the integration.
| Operation | Description |
|---|---|
query | Execute a SELECT query and return encrypted results. |
execute | Execute DML statements (INSERT, UPDATE, DELETE, MERGE). |
load_data | Stage and load data into a Snowflake table. |
Code Example#
Every proxy call returns a HybridCryptoEnvelope - the response is ML-KEM-768 key-encapsulated, AES-256-GCM encrypted, and signed with ML-DSA-65 + HMAC-SHA-512. Verify both signatures before trusting the decrypted payload.
curl -X POST https://api.quantaseal.io/api/v2/proxy/outbound \
-H "X-API-Key: qs_live_your_key_here" \
-H "Content-Type: application/json" \
-d '{
"integration_id": "int_01HZ9X2K4MNPQRSNOWFLAKE01",
"operation": "query",
"payload": {
"sql": "SELECT customer_id, revenue FROM analytics.sales WHERE quarter = :q",
"bindings": {"q": "2026-Q1"},
"warehouse": "COMPUTE_WH"
}
}'
# Response - HybridCryptoEnvelope
{
"success": true,
"encrypted": {
"ciphertext_kem": "<base64 - 1088 bytes ML-KEM-768>",
"ciphertext_data": "<base64 - AES-256-GCM encrypted Snowflake result set>",
"nonce": "<base64 - 12 bytes>",
"tenant_id": "ten_01HZ9X2K4MNPQR5STUVWXYZ00",
"algorithm": "ML-KEM-768"
},
"signature": {
"pqc_signature": "<base64 - ~3309 bytes ML-DSA-65>",
"hmac_signature": "<base64 - 64 bytes HMAC-SHA-512>",
"tenant_id": "ten_01HZ9X2K4MNPQR5STUVWXYZ00",
"algorithm": "ML-DSA-65+HMAC-SHA-512"
},
"audit_event_id": "aud_01HZ9XABCDEF"
}client.encryption.decrypt(envelope). Both the ML-DSA-65 signature and the HMAC-SHA-512 signature must pass - QuantaSeal uses a bitwise & check, not short-circuit and.Troubleshooting#
JWT token is invalid - key-pair auth failure
Verify the RSA public key uploaded to Snowflake matches the private key sealed in QuantaVault. Regenerate the key pair if uncertain.