Setting Up Snowflake Secondary Roles with Tableau
By: Pinterest Engineering
Tags: Pinterest, Snowflake, Infrastructure

Jessica Larson | Data Engineer

At Pinterest, we heavily utilize Tableau for our enterprise analytics. In an effort to secure access of sensitive data to the appropriate business units, we moved the enterprise data into a Snowflake data warehouse. Using Snowflake as a data platform, we can create and manage robust role-based access controls (RBAC). Since we want to use Snowflake as the source of truth for RBAC, we connected Tableau to Snowflake through a security integration using OAuth.

In order to check authorization during every use, we only allow live connections from Tableau. Live connections mean that every time a user views a dashboard, their credentials are used to query Snowflake. If that user has access to the dataset, they can view data on the dashboard; if they don’t, the dashboard will not populate, and the attempt to create the connection may raise an error.

Extract connections in Tableau

It is possible to configure Tableau to use extract connections, where an individual user or service account user embeds their credentials in the connection. This would allow a user, intentionally or inadvertently, to circumvent the RBAC system. Because we want to enforce permissions, we have disallowed extract connection configuration. Since we spent the time and resources setting up permissions in Snowflake, we want to leverage the access control configured there, rather than repeating it in other places and having to manage and maintain two or more systems.

Once the extract connection is disallowed, there are two ways to configure a connection to Snowflake in a Tableau dashboard: hardcoding a role or utilizing the default role.

Connecting Tableau and Snowflake

When hardcoding a role, every user that views this dashboard will be prompted to authenticate with Snowflake using that role, and only data that’s visible to that role can be used in the dashboard. One of the limitations of this is that since only one role can be hardcoded per dashboard, all users that need access must be granted the same role. This means that we may need to create a role for all combinations of roles.

Figure 1: Connecting With Specified Roles

When configuring a connection by using the default role, users may view a dashboard using different roles as long as that role has access to the underlying data. However, this would require carefully setting default roles for all of the users, and it may mean that users who support multiple teams will need special roles created. Using this method alone would require a lot of work on our platform team.

Figure 2: Connecting With Default Roles

To get around the complexity of connecting to Snowflake using different roles, we started using Snowflake’s new feature: secondary roles. Secondary roles allow a user to access all of the data to which any of their roles have access. It’s almost like assuming all of your roles at once. While that wouldn’t be ideal for writing data or performing admin actions, it is a really great way to handle read access. To start using secondary roles, we need to enable secondary roles on our security integrations and for all of our human users (more on this below). Instead of the complexity we mentioned above, we simply create connections to Snowflake using the default role and allow secondary roles to handle the rest. If a user has access to the underlying dataset, data will populate on the dashboard. If they don’t have access to the data, the dashboard will remain blank. In addition to this, secondary roles buy us a few other things: analysts now don’t need to worry about who has access to which roles and what data, and users will now only see one connection to Snowflake show up in their user settings.

Figure 3: Combining Default Roles and Secondary Roles

Setting Up Secondary Roles

Enable secondary roles for all human users in your organization. Since we’re only leveraging secondary roles for read access, we are only going to turn this on for human users and not service accounts. Our service accounts do not have associated emails, so we’ll exclude all of the accounts without an email. Here is a python snippet that can be used to do this:

This will generate the SQL that can be run through the python connector (if that fits your business’ practices), or it can be run manually. To remove secondary roles, you can simply change the statement to:

Enable secondary roles for use in security integrations, specifically the integrations like Tableau that support end users.

Utilizing Secondary Roles in Tableau

To capitalize on secondary roles in Tableau, we’ll use the default role in all of our Tableau live dashboards. To do this, simply omit the role parameter when creating the connection to Snowflake in Tableau Desktop. You can republish existing dashboards without the role as well. This means users will be prompted to connect to Snowflake using their default role as the primary role, and if they have access to the datasets used in the report, they will see data populate in the dashboard.

That’s it! The beauty of secondary roles is in its simplicity.

To learn more about engineering at Pinterest, check out the rest of our Engineering Blog, and visit our Pinterest Labs site. To view and apply to open opportunities, visit our Careers page.