Metabase Enterprise Edition’s data sandboxing feature gives us granular control over what data people can access, from entire databases down to specific columns and rows.
“Sandboxing” often refers to creating an isolated environment that’s used to protect or isolate part of a system.
Metabase uses the term sandboxing in a similar way, except in this case the isolated environment refers to a “data environment.” When an admin grants a group sandboxed access to a table, they can only see the rows and columns included in that sandbox.
In this article, we’ll walk through an example of setting up sandboxed access with the Sample Dataset included with Metabase. Data sandboxes can restrict access to both columns and rows. We’ll cover row-level permissions in this article, and follow up with another article that shows how we can restrict access to table columns as well.
Our goal is to make sure a customer, Ms. Brown, is only able to see table rows related to her account.
Before you sandbox
You should back up your Metabase application data.
Creating a customer group
Metabase uses groups to organize permissions, so we’ll first need to create a group, which we’ll call Customers.
We can create Groups in the People tab, which you can get to by clicking on the gears icon in the upper right, selecting Admin to bring up the Admin panel, and clicking on the People tab.
Creating a user and adding an attribute
Before we can set sandboxed permissions to the Customers group, we’ll need to create our user, Ms. Brown, and add an attribute to her account.
From the Admin panel’s People tab, we’ll click Add Someone. We’ll fill out the names and email fields, and add her to the Customers group.
And here’s the important part for sandboxing: we’ll add an attribute to our new user, Ms. Brown, with a key of
user_id and a value of
Note that there’s nothing magical about the
user_id key. It’s just a variable. We can add attributes with whatever key-value pairs we want. And what we want is to use a key that corresponds to a column, and a value that corresponds to row values, for the relevant table that we want to sandbox. The idea is that we’ll link this attribute to a column in a table to determine which rows Ms. Brown can view.
For the sake of this walkthrough, we’re setting this attribute up manually, but we can use authentication services (SSO), like SAML to programmatically assign and synchronize attributes to users.
Granting a group sandboxed access
Now that we have our group, and at least one member of that group with an attribute, we’re ready to head over to the data permissions page to grant the Customers group sandboxed access to tables in the Sample Dataset.
To the left of the grid, under Sample Dataset, we’ll click View tables to view the current data permissions of all the tables.
To grant the Customers group sandboxed access to the Orders table, all we need to do is click on the Customers’ data access cell in the Orders table row and select Grant sandboxed access.
The sandboxed modal will ask “How do you want to filter this table for users in this group?” and present two options:
- Filter by a column in the table.
- Use a saved question to create a custom view for this table.
We’ll cover using saved questions in another article, as they are an advanced use case. For now, we’ll leave the setting as Filter by a column in the table.
For the Column, we’ll select the
User ID column of the
Orders table, and we’ll connect that to the
user_id attribute from the dropdown menu of attributes we’ve assigned to users.
Metabase will provide us with a summary of the changes we’ve made: “Users in Customers can view rows in the Orders table where User ID field equals
user_id.” Let’s save our changes and repeat the process for the People table.
- Grant sandboxed access to the Customers group for the People table
- Select the Filter by a column access.
- Select the
IDcolumn of the
Peopletable and connect that to the
- Review the summary and click save.
Finally, we’ll need to click the Save Changes button to confirm our changes.
Check settings as our user
Now let’s test out our settings to confirm that our customer, Ms. Brown, can only see orders connected to her User ID.
We’ll open our Metabase instance in an incognito browser window and log in as Ms. Brown. When we navigate to the
Orders table, Ms. Brown will only see the orders she placed (User ID 20).
Sandboxing applies to aggregate questions as well. Here’s an Admin’s view of a question that groups all orders by category:
When viewing that same question, Ms. Brown will only see her orders:
By sandboxing the table, we can create a single question or dashboard, and rest assured that people with sandboxed access to that data will only be able to see the data associated with their account.
If we combine sandboxing with full-app embedding, we can embed these dashboards in our application, and use SSO to pass attributes to the embedded Metabase instance, allowing us to provide sandboxed access to the questions and dashboards embedded in our application. To learn more, see How to embed Metabase in your app to deliver multi-tenant, self-service analytics.
- Sandboxing only works with SQL databases.
- A user can only have one sandbox per table, so only add users to a single group with sandboxed access to a table.
- If a group has SQL querying access to a database, sandboxing cannot prevent people in that group from viewing data in those tables.
- By extension, if people in that group have access to questions written in SQL, those questions are unaware of the sandboxing access, and will show people in that group all results, not just the results in that group’s sandbox.
Learn more about the limitations of data sandboxing.
Stay tuned for an article with an advanced sandboxing walkthrough!
In the meantime, check out our documentation on data sandboxing