If you’re using Snowflake at scale, you’ve probably bumped into the question: “Where do I keep my API keys, secrets, and tokens?”
It feels simple at first – just stick them somewhere “safe.” But with data security tightening and governance rules getting stricter, this question can turn into a nightmare if handled wrong. The reality is: Snowflake isn’t meant to be your secret manager – but it can integrate with them the right way.
1. What Secrets Are We Talking About?
In a Snowflake context, “secrets” usually mean:
- Database credentials for connecting to Snowflake.
- API keys / OAuth tokens for external services (Salesforce, AWS, Stripe, etc.).
- Private keys for programmatic authentication.
- Encryption keys (less common, but critical).
These are not data – they’re access enablers. Treat them like keys to the kingdom, not as values to casually store in tables.
2. Where Not to Put Them
Let’s start with the don’ts, because that’s where most mistakes happen:
- ❌ Don’t store secrets in plain tables. Even if encrypted, governance will flag it and auditing becomes painful.
- ❌ Don’t hardcode them in Snowflake procedures or UDFs. It’s convenient, but you’ve now buried secrets in code where versioning and auditing are weak.
- ❌ Don’t expose them via views or temp tables – snowballing risk if downstream teams get access.
Remember: Snowflake is amazing for data, but not a vault.
3. Where They Can Go (Safely)
Now to the safer side:
- ✅ External Secret Managers → Best practice. Use AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault. Your Snowflake connection string can then pull from these at runtime.
- ✅ Snowflake External Functions + Secure Integration → Instead of embedding keys, configure integrations (like AWS IAM roles, GCP service accounts, or Azure AD). These shift authentication from “tokens” to “roles,” removing the need to store raw secrets.
- ✅ Snowflake Secrets Management (Scoped Integrations) → Snowflake has been evolving its ecosystem. Features like security integrations allow you to define OAuth clients and credentials in a managed way, without exposing raw keys in SQL.
💡 Rule of thumb: The closer you keep secrets to the actual data, the higher the breach blast radius. Push secrets management outside Snowflake whenever possible.
4. Tokens & OAuth: A Special Case
OAuth tokens often get refreshed automatically. Instead of dropping them in Snowflake tables, let Snowflake integrate with the provider (e.g., Google, Microsoft, Salesforce).
- Short-lived tokens? Use Snowflake external OAuth integrations.
- Long-lived tokens? Store and rotate them in a proper vault, then pass through when connecting.
This avoids the worst-case scenario: a stale, leaked token giving unauthorized access for months.
5. What Shouldn’t Ever Go in Snowflake
- Master credentials for cloud accounts (AWS root keys, Azure tenant secrets, etc.).
- Private SSH keys.
- Encryption root keys.
- Anything you can’t rotate easily.
These belong in enterprise-grade vaults with rotation policies, not in SQL scripts or VARs.
6. Wrapping It Up
Snowflake gives you secure integrations and governance controls, but it was never meant to be a secret manager. Think of it this way:
- Data belongs in Snowflake.
- Secrets belong in vaults.
- Integrations bridge the two.
Get this separation right, and you’ll avoid compliance headaches, keep auditors happy, and sleep better knowing your “keys to the kingdom” aren’t lying around in a schema.
Because in the end, it’s not just about where secrets go – it’s about making sure they don’t end up where they absolutely shouldn’t.
BrontoWise 
Leave a comment