@@ -36,7 +36,7 @@ To add a user attribute manually:
4. Click **+ Add an attribute**.
5. Add the name of the user attribute under "Key". For example, "Department".
6. Add the value that applies to the specific person. For example, "Engineering".
7. Optional: if a group for sandboxed people doesn't exist, [create a group](#creating-a-group) to organize people who will get sandboxed table permission, such as "Sandboxed people".
7. Optional: if a group for sandboxed people doesn't exist, [create a group](#creating-a-group) to organize people who will get sandboxed table permissions, such as "Sandboxed people".
8. Add the person to the group.
You can also sync user attributes from your identity provider [via SSO](./start.md#authentication).
@@ -26,15 +26,25 @@ You can set various levels of permissions on a data source, from querying access
## Data access
Data access levels determine which data people can use to ask _new_ questions. Data access is distinct from [collection permissions](./collections.md), which determine which existing things people can view: dashboards, questions, and models. Metabase provides both blunt and sharp tools for you to set up data permissions that suit your needs.
You can click on any cell in the permissions table to change a group’s access level. When you’re done making your changes, just click the **Save changes** button in the top-right, and you’ll see a confirmation dialog summarizing the changes.
-[Granular](#granular-access)(which includes Sandboxed access)
-[No self-service](#no-self-service-access)
-[Impersonation](#impersonation-access)
-[Block](#block-access)
## Unrestricted access
Members of the group can create questions using the graphical query builder on data from all tables (within all namespaces/schemas, if your database uses those), including any tables that might get added to this database in the future.
To grant a group the ability to write native/SQL questions or create [actions](../actions/start.md), you must additionally set [Native query editing](#native-query-editing) to **Yes**.
### Granular access
## Granular access
**Granular access** allows administrators to explicitly set data access to tables or schemas within a database, with "data access" here meaning the ability to create questions using the graphical query builder. In practice, this means that:
...
...
@@ -43,11 +53,44 @@ To grant a group the ability to write native/SQL questions or create [actions](.
Note that [Block](#block-access) access is unavailable for individual tables/schemas. Block is a database-level setting; you can only block the entire database.
### No self-service access
## No self-service access
**No self-service** prevents people in a group from using the graphical query builder to create new questions that query that database, or from seeing this database in the Browse Data section of your Metabase. Groups with No self-service access can still see saved questions that query this data if they 1) have access to the appropriate collection, and 2) aren't in a group with [blocked access](#block-access) to the database.
### Block access
## Impersonation access
{% include plans-blockquote.html feature="Impersonation access" %}
**Impersonation access** allows you to associate user attributes with database-defined roles and their privileges. Metabase queries made by people with attributes that you define will respect the grants given to the database roles.
You can use impersonation to give people access to the native/SQL editor, while at the same time restricting the their access to data based on a specific database role. And not just table-level access, but row-level access---or however you define access for that role in your database. Effectively what this means is that you can use impersonation to set up data sandbox-like access to your data. The difference is that, instead of setting up a data sandbox in Metabase, you need to set up that row-level security via the privileges granted to a role in your database.
When you connect Metabase to a database, you use a database user account that has one or more database roles. When you give a group in Metabase unrestricted access to a database, that group will have the same privileges as the user account that you used to connect Metabase to that database.
If instead you want to give a group SQL access to some, but not all, of the schemas or tables in that database, you can create an additional role in your database that only includes a subset of those tables---or even specific row-level access---and then use Metabase's impersonation feature to associate a user attribute with that role. Essentially what Metabase will do is take the user attribute and pass that attribute as a string into a `SET ROLE` or `USE ROLE` command for the database _before_ Metabase executes the query.
### Setting up connection impersonation
**In your database:**
- Create a new role.
- Grant that role privileges.
For exactly how to create a new role in your database and grant that role privileges, you'll need to consult your database's documentation. We also have some docs on [users, roles, and privileges](../databases/users-roles-privileges.md) that can help you get started.
**In your Metabase:**
- Create a [new group](../people-and-groups/managing.md#groups), or select an existing group.
- Assign a [user attribute](../people-and-groups/managing.md#adding-a-user-attribute) to that group. You'll use this user attribute to associate that group with a role that you created in your database. For example, if you created a role named "Sales" in your database with access to a subset of tables, you would add a user attribute "Sales" to the group. The user attribute should match the name of the role your database. Only some databases enforce case sensitivity, so you might want to make sure the attribute name and role match exactly just in case.
- Next, you'll need to apply the impersonation access to that group. Go to **Admin settings** > **Permissions** > **Data**.
- Select the database you want to set permissions on.
- Find the group that you want to associate with the database role you created. Under **Data access** for that group, select **Impersonation**.
- From the dropdown, select the user attribute that you added that maps to the role you want the group to use when querying the database.
- Save your changes.
Keep in mind that Metabase gives people the most permissive access to data across all of their groups. So if a person is in one group with impersonated access, and one group with unrestricted access, the unrestricted access would override the impersonated access.
## Block access
{% include plans-blockquote.html feature="Block access" %}
...
...
@@ -62,19 +105,19 @@ If a person in that blocked group belongs to _another_ group that _does_ have th
- If the question was created using the [graphical query builder](../questions/query-builder/introduction.md), the person would also need to be in a group with **Unrestricted data access** or **Sandboxed access** to the relevant database (or table) to view that question.
- If the question was created using the [native/SQL editor](../questions/native-editor/writing-sql.md), the person would need to be a member of a group with both **Unrestricted data access** and **Native query editing** set to **YES** to view that question.
### Table permissions
## Table permissions
When you select [Granular access](#granular-access) for a database, you'll be prompted to set permissions on the tables (or schemas) within that database. Here you'll have some options, which differ depending on your Metabase plan.
#### Unrestricted access to the table
### Unrestricted access to the table
Groups with unrestricted access can use the [graphical query builder](../questions/query-builder/introduction.md) to ask questions about this table.
#### No self-service access to the table
### No self-service access to the table
Groups with no self-service access to a table can’t access the table at all. They can, however, view questions that use data from that table, provided the group has access to the question's collection, and they're not in a group with [blocked access](#block-access) for that table's database.
#### Sandboxed access to the table
### Sandboxed access to the table
{% include plans-blockquote.html feature="Data sandboxing" %}
...
...
@@ -133,6 +176,7 @@ Note that only admins can delete database connections in your Metabase, so peopl
