Snowflake Service Account Security, Part 3
Jul 15, 2020 | 7 Min Read
Author: Jonathan Sander
In Part 1 and Part 2 of this blog post series, Snowflake Service Account Security, discussed service accounts threats and how to mitigate those threats with Snowflake features. Part 3 demonstrates how to manage credential rotation with a sample Hashicorp Vault plugin. You can use many platforms to achieve similar results. The important thing is to understand the patterns used to apply these controls to protect your service accounts.
Mitigations Offered Using Credential Rotation
This table shows how credential rotation benefits our mitigations:
How the Vault Plugin Works
For complete instructions and to get the plugin for testing, please see the github repository with the code and documentation. The following two scenarios demonstrate how to use the plugin to attain strong controls.
The scenarios assume that you have already done all the setup.
In the first scenario, you use the plugin to create ephemeral users with very specific rights. To do this you create a role in Vault. The role contains the instructions to create the user properly in Snowflake. You can then read from this Vault role to get a temporary username and password.
We will create a role called xvi and then call it to get a user:
This results in a user being created in Snowflake:
This user is later deleted by Vault when the lease expires (this is from the Vault logs):
Notice a couple key points that relate to our mitigation goals:
- The role creates users with a specific set of rights encapsulated in their roles and warehouses. This allows us to create a user with the least privilege needed.
- The role defines a default and maximum time for a user’s credentials to be active. This ensures that it will be a short-lived credential.
Our second scenario rotates the credentials of an existing Snowflake user. If the user’s name for the service account is important to the application, using this approach allows the name to be pre-defined. Again, we create a Vault role to achieve this. The role, named teamdp, will map to an existing user named bob. We will rotate the password for bob every five minutes.
After creating the role, we called it to get the new password Vault created for it. When we call it again a little while later, we see the five-minute time to live (TTL) counting down. We can also call rotate-role on the Vault role, and this forces the password to be rotated immediately.
Notice a few key points that relate to our mitigation goals:
- The role defines a maximum time for the user’s password to be valid. This ensures that it will be a short-lived credential.
- Anyone with this password can use it for a limited time before it rotates again automatically. This helps to prevent unwanted access to persistent service accounts.
- After a program is done with the password, it can call rotate-role to immediately have the password changed to a new value. This controls the password lifecycle completely, preventing the need for any human access.
To prevent attacks, it is critical to automate control of your service account credentials. A variety of systems can help you set up automation and create a moving target, which is the hardest kind of target to hit. Learn more about Snowflake’s commitment to security.