Updated October 30th, 2024

Snowflake Data Access Control: A Complete Guide for 2024

Atlan helps businesses on Snowflake make confident decisions with trusted, governed data.
Book a Demo →

Share this article

Snowflake’s data access control model lets you oversee access to any securable object within Snowflake, enabling a zero-trust security posture with multiple lines of defense. The model is built on two core frameworks – DAC and RBAC.

DAC (Discretionary Access Control) allows object ownership definition and transfer, while RBAC (Role-based Access Control) supports a role hierarchy that mirrors organizational structures.
See How Atlan Simplifies Data Governance – Start Product Tour

Together, DAC and RBAC form the foundation of Snowflake’s fine-grained access control. However, maintaining consistent data access control across your data ecosystem can be challenging without a data control plane.

So, this article explores Snowflake’s RBAC features and how an organization-wide control plane for data can enhance them.

Table of contents #

  1. Snowflake data access control: Native features
  2. Data access control with Snowflake and Atlan
  3. Summing up
  4. Snowflake data access control: Related reads

Snowflake data access control: Native RBAC features #

Snowflake’s data access control is organized around four key elements:

  1. Securable object : Any Snowflake object, such as a table, view, database, or schema, that can be secured.
  2. Privilege: The level of access to that object (CREATE, DELETE, READ, WRITE, MODIFY).
  3. Role: The Snowflake entity to which privileges can be granted. Note: They cannot be granted to a user, as Snowflake only allows role-based access control. Roles can be assigned to a user.
  4. User: A Snowflake database user who can log into Snowflake (either via the UI or programmatically) and is assigned a role.

Let’s explore each of these elements further.

1. Snowflake securable objects #


Snowflake organizes objects in a logical hierarchy, with each object contained within higher-level objects.

To understand more about the organization of securable objects in Snowflake, take a look at the image below.

Securable objects in Snowflake

Securable objects in Snowflake - Source: Snowflake Documentation.

Ownership of each object defaults to the role that created it, but you can transfer ownership with the GRANT OWNERSHIP command.

For example, if you want to transfer ownership of the role sales_analyst to the role marketing_analyst for the marketing schema, you can use the following SQL commands.

REVOKE ALL PRIVILEGES ON SCHEMA marketing FROM ROLE sales_analyst;
GRANT OWNERSHIP ON SCHEMA marketing TO ROLE marketing_analyst;
GRANT ALL PRIVILEGES ON SCHEMA marketing TO ROLE marketing_analyst;

After running these SQL commands, the marketing_analyst role will be the new owner of the marketing schema.

Besides these, there are other ways of managing privileges in a more centralized manner, which you’ll learn in the next section.

2. Snowflake access control privileges #


Snowflake offers several hundred access control privileges, some broadly applicable and others object-specific, organized by scope (e.g., account-level, database-level).

Users with ownership rights can grant privileges within their schema. By default, Snowflake creates non-managed schemas where object owners within that schema can grant privileges to other roles. This can lead to some problems, as described in the following example.

Let’s say you have a marketing team with analysts who are responsible for marketing analytics. They’ve been assigned a marketing_analyst role. They primarily use the marketing schema.

While most of the data source integrations are centrally managed by an ETL pipeline, there are times when marketing analysts create new tables, views, functions, etc., within the marketing schema. This would give the marketing_analyst role the ownership of those objects, so when there’s a requirement for other teams to access those objects, you’d need to ask someone with the marketing_analyst role to grant access to those objects.

A scenario like this often leads to problems related to overly permissive grants and unnecessarily complicated access request processes, which is why Snowflake recommends creating managed schemas with the option WITH MANAGED ACCESS. As a result, the schema owner can centralize privilege management instead of having every object owner in that schema their privilege management.

To simplify this for the aforementioned example, you’d do something like this if you’re creating a new schema:

CREATE SCHEMA marketing WITH MANAGED ACCESS;

You can also use the ALTER SCHEMA statement to edit the settings of an existing schema.

ALTER SCHEMA marketing ENABLE MANAGED ACCESS;

Once that’s done, the owner of the schema object will have granting rights on all objects in that schema, irrespective of which role was used to create them.

3. Snowflake role types #


Snowflake offers several types of roles that you can use to align with different use cases and functions, such as authentication, authorization, networking, application integration, etc.

Here’s a quick summary of the role types:

  • Account roles: These roles work across the whole Snowflake account, i.e., you can grant permissions to perform any action on any object.
  • Database roles: These roles are limited to a single database. Database roles are similar to account roles in capability, but only limited to one database.
  • Instance roles: In Snowflake, you can create class constructs to abstract and manage various objects better. You can also create roles tied to specific instantiations of those classes. Those are instance roles.
  • Application roles: These roles are created for specific applications created using the Snowflake Native App Framework, e.g., a Streamlit app.
  • Service roles: These roles work with Snowpark Container Service objects, such as registry, repository, compute pools, jobs, and snapshots.

Additionally, Snowflake includes seven system-defined roles for flexible permission assignment:

  • GLOBALORGADMIN
  • ORGADMIN
  • ACCOUNTADMIN
  • SECURITYADMIN
  • USERADMIN
  • SYSADMIN
  • PUBLIC

A hierarchy for the system-defined roles in Snowflake

A hierarchy for the system-defined roles in Snowflake - Source: Snowflake Documentation.

A Snowflake user can be assigned many roles. The role a user specifies while logging in to the Snowsight UI or any other IDE becomes that session’s primary or active role. All the other roles are considered secondary roles.

A hierarchy of primary and secondary roles in Snowflake

A hierarchy of primary and secondary roles in Snowflake - Source: Snowflake Documentation.

The secondary roles can be queried by the following SQL command:

SELECT CURRENT_SECONDARY_ROLES();

You can run a USE ROLE or USE SECONDARY ROLES command to switch the role for the session so that you have sufficient privileges to perform the actions you intend to perform.

4. Snowflake user management #


The final element in RBAC is user management. It’s the user who does the following:

  1. Logs into Snowflake either from the Snowsight UI or the SnowSQL console programmatically or using any other IDE.
  2. Uses predefined roles and creates any custom roles that might be required to align with the business’s internal organization.
  3. Assumes those roles to perform actions on Snowflake objects to grant or revoke privileges, create or drop objects, and access and analyze data, among other things.

Snowflake’s user management also integrates with identity and security features like SCIM and network policies.

Additional features that work with Snowflake’s RBAC #


Several other native features tie in with Snowflake’s role-based access control framework to strengthen your control over your data assets:

  • Object tagging: Tags assets with keywords for organizational and access purposes.
  • Data classification: System tags classify data semantically and by privacy level. You can also create custom tags to ensure a finer control on your data.
  • Masking policies: Enforce column-level security by integrating tags and roles.
  • Row access policies: Support row-level security by associating policies with roles.

Snowflake’s RBAC framework provides comprehensive access management within Snowflake. However, extending this model across other ecosystem tools requires a control plane for consistent security standards.

Data access control with Snowflake and Atlan: Setting up a unified control plane for data #

A control plane for data, by definition, sits across all components in your entire data ecosystem—including orchestration engines, transformation tools, and core platforms like Snowflake.

Atlan integrates with Snowflake to bring metadata into a central “lakehouse for metadata” for search, discovery, and governance.

Some of the core capabilities that allow Atlan to integrate with Snowflake and other tools include (but aren’t limited to):

  • User roles: Every Atlan user needs to map to one of the predefined roles: Admin, Member, or Guest. You can also use user groups to organize all of your Atlan users better.
  • Personas: Personas help you better manage access by letting you curate data assets and working with various types of access policies to implement fine-grained access control.
  • Purposes: Purposes allow you to group data assets by team, project, and domain, among other things. They also help you implement granular access control, especially when dealing with sensitive data.

Also, read → The unified control plane in action

Additionally, Atlan enforces a least-privilege approach by following three rules:

  1. Access is denied by default
  2. Explicit grants or allows are combined, i.e., they form a superset of grants or allows
  3. Explicit restrictions or denies take priority over existing grants or allows

Atlan’s integration with Snowflake works well, as Atlan leverages Snowflake’s metadata to its fullest potential.

Atlan makes it very easy to set up a connection with Snowflake while also making sure that the metadata and data transfer between the two tools is safe and secure. This forms the basis for a really robust data governance implementation for your Snowflake-led data ecosystem.

How Indicia Worldwide powered a unified data platform with Atlan and Snowflake #


Indicia Worldwide, a global communications agency, used Atlan as its data discovery and governance backbone. This setup allows Indicia to “understand what’s going on within [its] data estate, what [the] data hold(s), and what its characteristics are, and how it’s being used.”

The core of this data platform is Snowflake. However, grappling with increasing complexity of data, technology, and engineering requests made it challenging to scale the platform.

“We have some clients who have 40 million customers and build tens upon tens of billions of rows of data. There’s a lot to keep an eye on, so when we tried to link this data up with our own tools, we found that we just weren’t keeping up.” - Graham Lannigan, Head of Data Platform at Indicia Worldwide

By integrating Atlan with Snowflake, Graham’s team has increased visibility into their data estate, improved root cause and impact analysis, and saved engineering time and resources. Today, Indicia manages over 500,000 assets in Atlan.

With a Snowflake+Atlan setup, Indicia maintains control over data assets across the ecosystem without directly interacting with each individual component.

“Atlan gives us that [single pane of glass] in one tool, which is incredible. So the more Atlan is able to integrate natively with things like Snowflake’s object tagging capabilities, the more powerful Atlan gets, and it becomes more and more important in our stack.”

Summing up #

Using Snowflake’s data access control alongside Atlan’s control plane provides robust, consistent data security and governance across your ecosystem. With Atlan’s integration, you gain centralized control and metadata insight, allowing scalable, fine-grained access management across all data assets.

To learn more about the benefits, visit the Atlan + Snowflake connectivity documentation. Also check out how Atlan helps with better data governance in Snowflake.

Share this article

[Website env: production]