Best practice on configuring role(s) that my Terraform user will use

[louis-vines]

I'm just wondering if there are any best practices for how I should configure the role(s) that Terraform will assume when administering snowflake. I've setup all of the Snowflake RBAC at a previous company in terraform and am just about to start from scratch at a new company and would like to get this nailed before I proceed.

I've noticed in the snowflake terraform tutorial (https://quickstarts.snowflake.com/guide/terraforming_snowflake) it just grants SYSADMIN and SECURITYADMIN to snowflake, but it then states:

We grant the user SYSADMIN and SECURITYADMIN privileges to keep the lab simple. An important security best practice, however, is to limit all user accounts to least-privilege access. In a production environment, this key should also be secured with a secrets management solution like Hashicorp Vault, Azure Key Vault, or AWS Secrets Manager.

So what are the best practices for this? How should I grant privileges to my Terraform user?

At my previous company I just did this:

USE ROLE ACCOUNTADMIN;

-- set up role and user
CREATE USER TERRAFORM <... credentials etc ...>; 
CREATE ROLE TERRAFORM;
GRANT ROLE TERRAFORM TO USER TERRAFORM;

-- configure role privileges
GRANT CREATE USER ON ACCOUNT TO ROLE TERRAFORM;
GRANT CREATE DATABASE ON ACCOUNT TO ROLE TERRAFORM;
GRANT CREATE INTEGRATION ON ACCOUNT TO ROLE TERRAFORM;
GRANT CREATE ROLE ON ACCOUNT TO ROLE TERRAFORM;
GRANT CREATE WAREHOUSE ON ACCOUNT TO ROLE TERRAFORM;
GRANT CREATE NETWORK POLICY ON ACCOUNT TO ROLE TERRAFORM;
GRANT ATTACH POLICY ON ACCOUNT TO ROLE TERRAFORM;
GRANT MANAGE GRANTS ON ACCOUNT TO ROLE TERRAFORM;

But I think this also violates a best practice as I now have a role that both administers data base objects (i.e. like SYSADMIN) and users + roles (i.e. like SECURTYADMIN).

So what roles/priviliges should I grant to my terraform user and how???

(One final related question is how can I make terraform responsible for administering parameters on my account too? I think to do this then terraform has to be an ACCOUNTADMIN but again this doesn't sound like something I should be granting to my Terraform user)

[kevinstapleton]

Hi @louis-vines,

I've set it up by creating 3 roles which align to the suggested hierarchy, allowing resource ownership to be rolled up to the top-level "admin" roles without "crossing the streams". That is, SECURITYADMIN owns all users and roles; SYSADMIN owns databases and warehouses; and ACCOUNTADMIN owns integrations.

USE ROLE ACCOUNTADMIN;

CREATE USER TERRAFORMER <...>;

CREATE ROLE ACCOUNTTERRAFORMER;
GRANT ROLE ACCOUNTTERRAFORMER TO ROLE ACCOUNTADMIN;
GRANT ROLE ACCOUNTTERRAFORMER TO USER TERRAFORMER;

GRANT CREATE INTEGRATION ON ACCOUNT TO ACCOUNTTERRAFORMER;
GRANT CREATE NETWORK POLICY ON ACCOUNT TO ACCOUNTTERRAFORMER;
-- additional account grants

CREATE ROLE SECURITYTERRAFORMER;
GRANT ROLE SECURITYTERRAFORMER TO ROLE SECURITYADMIN;
GRANT ROLE SECURITYTERRAFORMER TO USER TERRAFORMER;

GRANT CREATE USER ON ACCOUNT TO ROLE SECURITYTERRAFORMER;
GRANT CREATE ROLE ON ACCOUNT TO ROLE SECURITYTERRAFORMER;
GRANT MANAGE GRANTS ON ACCOUNT TO ROLE SECURITYTERRAFORMER;

CREATE ROLE SYSTERRAFORMER;
GRANT ROLE SYSTERRAFORMER TO ROLE SYSADMIN;
GRANT ROLE SYSTERRAFORMER TO USER TERRAFORMER;

GRANT CREATE DATABASE ON ACCOUNT TO SYSTERRAFORMER;
GRANT CREATE WAREHOUSE ON ACCOUNT TO SYSTERRAFORMER;

Then within the terraform module, I create 3 snowflake provider instances (same user, different role):

provider "snowflake" {
  alias = "accountterraformer"

  username = local.snowflake.username
  account  = local.snowflake.account
  role     = "ACCOUNTERRAFORMER"

  # auth attributes
}

provider "snowflake" {
  alias = "securityterraformer"

  username = local.snowflake.username
  account  = local.snowflake.account
  role     = "SECURITYTERRAFORMER"

  # auth attributes
}

provider "snowflake" {
  alias = "systerraformer"

  username = local.snowflake.username
  account  = local.snowflake.account
  role     = "SYSTERRAFORMER"

  # auth attributes
}

Lastly, when creating resources, you need to specify the provider which aligns with the correct role for that resource:

resource "snowflake_storage_integration" "s3" {
  provider = snowflake.accountterraformer
  # ... snip ...
}

resource "snowflake_user" "user" {
  provider = snowflake.securityterraformer
  # ... snip ...
}

resource "snowflake_database" "db" {
  provider = snowflake.systerraformer
  # ... snip ...
}

A quality-of-life feature request would be to have an "execute_as_role" attribute on all resources which would allow us to accomplish the above without needing distinct providers (if one user has all the necessary roles, of course).

I hope this helps!

[chrisweis]

@kevinstapleton, super helpful info thanks! I’m curious, how do you handle roles for developers that work on the Terraform code?

[kevinstapleton]

@chrisweis, for the most part, developers are only granted read-only roles within the databases they need, and all terraform plan and terraform apply commands are run with the TERRAFORMER user via our CI/CD pipelines.

Diving a bit further into our setup, we actually have pipelines split out for the "account" level things (databases, warehouses, integrations, users, roles, etc.), which is run as the TERRAFORMER user, and for each database. As part of the database setup in the "account" pipeline, we create an owner role, a read-only role, and a terraformer user. The CI/CID pipeline for the database would then run as the DB-specific terraformer user. If a developer were then having issues with the snowflake TF and the read-only role was not sufficient to diagnose (it would be nice if a MONITOR-like grant existed for more than pipes), then they would either enlist the help of a DBA (SYSADMIN/ACCOUNTADMIN) or be temporarily granted the owner-role for that database. We have separate snowflake accounts for different environments, so this would typically only be done in our "DEV" account.

With that said, we do have a "playground" database which is not managed by TF (except for the DB itself) where developers are free to create database-level resources to do PoC and learning.