Introducing Snowflake Access-as-Code
Simplify your Snowflake access management with GitOps and CI/CD.
Motivation
DevOps culture has been making its way into the data ecosystem, which has improved data teams’ ability to secure their customer data at scale.
Why is GitOps useful for managing your Snowflake access control?
- Access as Code. Changes are version controlled, auditable, reversible, and can be reviewed and approved through a typical Git workflow.
- Continuous Deployment. Automated pipelines continuously monitor your repository for changes and deploy updates to Snowflake automatically, reducing manual effort and increasing speed of delivery.
- Auditing and Compliance. Ensure you have a transparent trail of who made changes, when they were made, and what was changed.
- Collaboration. Allow team members to provide feedback, catch potential issues, and ensure quality before changes are applied, which promotes knowledge sharing among your team.
- Rollback and Disaster Recovery. Since your infrastructure state is stored in git, it is easy to roll back to a previous known state in case of issues or failures, reducing your mean time to recovery during and incident.
- Environment Consistency. By maintaining a single source of truth, you can ensure consistency across development, staging, and production environments. This reduces configuration drift, increases reliability, and simplifies the management of multiple environments.
Now that we understand the benefits of GitOps, let’s see how we can implement it in practice for Snowflake.
Solution
Open-source tools like Spyglass CLI can be helpful for making the transition from one-off scripts to fully-automated version control.
Step 1 — Import Existing Snowflake Rules
Moving to version control shouldn’t be hard, so Spyglass provides a single import
command, which takes all of your existing Snowflake rules and translates them to Spyglass YAML.
Once you’ve imported your rules, add and commit the file(s) to your git repo. Now that we have a single source of truth for Snowflake access, we can update them in a repeatable process.
Step 2 — Make Changes
To update your access rules, update the Spyglass YAML file and send it through your standard git-based pull request workflow. Use GitHub Code Owners to ensure only authorized individuals can merge these requests (see security considerations for more info).
From here, use a GitHub Action or other integration to integrate the plan
(dry run) and apply
commands.
Spyglass Cloud is also available to enable integration into your CI/CD system with one click. Reach out to demo@spyglass.software for more information.
Step 3 — Let Automation Take Over
Commands are applied automatically on pull request merge. If they fail for some reason, an error will be printed so you can fix it and then retry the job.
This covers the case of taking your Spyglass YAML and applying it to Snowflake, but what happens when changes are made directly in Snowflake and your Spyglass YAML needs to be updated?
Configuration Drift
Our GitHub Action integration also provides a sync
workflow. This sync ensures a bi-directional update between Spyglass and Snowflake, so that your git repository is always up to date.
Sync commands run on a periodic schedule, and commit back to your git repo with the latest Snowflake access rules.
About Spyglass
Since you’re here, let me tell you what we’ve cooked up at Spyglass. In short, we make Snowflake data access controls easy - or provide an automated and better way to do the above.
If you’ve nodded your head while reading this, reach out at spyglass.software (or demo@spyglass.software) and we’ll show you a product demo to give you a taste of the future of data access management.