Слияние кода завершено, страница обновится автоматически
| title | redirect_from | |
|---|---|---|
Data sandboxes |
|
{% include plans-blockquote.html feature="Data sandboxes" %}
Data sandboxes let you give granular permissions to rows and columns for different groups of people. You can sandbox what data a group can view, as well as what data a group can query with the query builder.
You can use sandboxes to set up self-service analytics, so that each of your customers only views the rows that match their customer ID. For example, if you have an Accounts table with information about your customers, you can sandbox that table so that each customer only sees the data relevant to them.
You can skip the theory and go straight to sandbox examples.
You can think of a data sandbox as a bundle of permissions that includes:
You can define up to one data sandbox for each table/group combo in your Metabase. That means you can display different versions of a table for different groups, such as "Sandboxed Accounts for Sales" to your salespeople, and "Sandboxed Accounts for Managers" for sales managers.
Data sandboxes show specific data to each person based on their user attributes. You can:
| Basic sandbox (filter by a column in the table) | Custom sandbox (use a saved SQL question) | |
|---|---|---|
| Restrict rows by filtering on a single column | ✅ | ✅ |
| Restrict rows by filtering on multiple columns | ❌ | ✅ |
| Restrict columns | ❌ | ✅ |
| Edit columns | ❌ | ✅ |
To restrict rows, use a basic sandbox. A basic sandbox displays a filtered version of a table instead of the original table to a group. The filter works by setting a column in the table to a specific user attribute value.
For example, you can create a basic sandbox to filter the Accounts table for a group so that:
Plan = "Basic" (rows where the Plan column matches the value "Basic").Plan = "Premium" (rows where the Plan column matches the value "Premium").To restrict columns as well as rows, use a custom sandbox (also known as an advanced sandbox). A custom sandbox displays the results of a saved SQL question in place of your original table.
For example, say your original Accounts table includes the columns: ID, Email, Plan, and Created At. If you want to hide the Email column, you can create a "Sandboxed Accounts" SQL question with the columns: ID, Plan, and Created At.
A custom sandbox will display the "Sandboxed Accounts" question result instead of the original Accounts table, to a specific group, everywhere that Accounts is used in Metabase.
You can also use a custom sandbox to:
Things that don't play well in a sandbox.
You can't set up query builder and native for sandboxed groups.
To enforce row-level permissions with the native query editor, check out impersonation.
Since Metabase can't parse SQL queries, the results of SQL questions will always use original tables, not sandboxed tables.
Use collection permissions to prevent sandboxed groups from viewing saved SQL questions with restricted data.
Data sandbox permissions are unavailable for non-SQL databases such as Apache Druid or MongoDB.
A basic sandbox displays a filtered table, in place of an original table, to a specific group. How Metabase filters that table depends on the value in each person's user attribute.
For example, you can set up a basic sandbox so that:
Plan = "Basic" (that is, only the rows where the Plan column matches the value "Basic").Plan = "Premium" applied.User attributes are required for basic sandboxes, and optional for custom sandboxes. When adding a new user attribute, you'll set up a key-value pair for each person.
Metabase uses the user attribute key to look up the user attribute value for a specific person. User attribute keys can be mapped to parameters in Metabase.
The user attribute value must be an exact, case-sensitive match for the filter value of a sandboxed table. For example, if you're creating a basic sandbox on the Accounts table with the filter Plan = "Basic", make sure that you enter "Basic" as the user attribute value. If you set the user attribute value to lowercase "basic" (a value which doesn't exist in the Plan column of the Accounts table), the sandboxed person will get an empty result instead of the sandboxed table.
Examples of user attributes in play:
If you have saved SQL questions that use sandboxed data, make sure to move all of those questions to admin-only collections. For more info, see Permissions conflicts: saved SQL questions.
You can find a sample basic sandbox setup in the Data sandbox examples.
In an advanced data sandbox, Metabase will display a saved question in place of an original table to a particular group.
Use a SQL question to define the exact rows and columns to be included in the sandbox. If you use a query builder (GUI) question, you might accidentally expose extra data, since GUI questions can include data from other saved questions or models.
Make sure to save the SQL question in an admin-only collection (collection permissions set to No access for all groups except Administrators). For more info, see Permissions conflicts: saved SQL questions.
Aside from excluding rows and columns from an custom sandbox, you can also display edited columns (without changing the columns in your database).
For example, you can create a "Sandboxed Accounts" SQL question that truncates the Email column to display usernames instead of complete email addresses.
If you edit a column, the schema of the saved SQL question (the question you want to display in the sandbox) must match the schema of the original table. That means the "Sandboxed Accounts" SQL question must return the same number of columns and corresponding data types as the original Accounts table.
You cannot add a column to a custom sandbox.
If you have saved SQL questions that use sandboxed data, make sure to move all of those questions to admin-only collections.
You can find sample custom sandbox setups in the Data sandbox examples.
You can set up an custom sandbox to restrict different rows for each person depending on their user attributes. For example, you can display the "Sandboxed Accounts" question with the filter Plan = "Basic" for one group, and the filter Plan = "Premium" for another group.
WHERE clause to your SQL query, such as {%raw%}WHERE plan = {{ plan_variable }} {%endraw%}.For a sample SQL variable and user attribute setup, see the Data sandbox examples.
How user attributes, SQL parameters, and custom sandboxes work together to display different rows to different people.
A standard WHERE clause filters a table by setting a column to a fixed value:
WHERE column_name = column_value
In step 2 of the row restriction setup above, you'll add a SQL variable so that the WHERE clause will accept a dynamic value. The SQL variable type must be text, number, or date:
WHERE plan = {%raw%}{{ plan_variable }}{%endraw%}
In steps 9-10 of the row restriction setup above, you're telling Metabase to map the SQL variable plan_variable to a user attribute key (such as "User's Plan"). Metabase will use the key to look up the specific user attribute value (such as "Basic") associated with a person's Metabase account. When that person logs into Metabase and uses the sandboxed table, they'll see the query result that is filtered on:
WHERE plan = "Basic"
Note that the parameters must be required for SQL questions used to create a custom sandbox. E.g., you cannot use an optional parameter; the following won't work:
[[WHERE plan = {%raw%}{{ plan_variable }}{%endraw%}]]
Learn more about SQL parameters
Some Metabase permissions can conflict with data sandboxes to give more permissive or more restrictive data access than you intended.
Say you have an custom sandbox that hides the Email column from the Accounts table (for a particular group).
The Email column may get exposed to a sandboxed person if:
Multiple data sandboxes on the same table can create a permissions conflict. You can add a person to a maximum of one data sandbox per table (via the person's group).
For example, if you have:
Plan = "Basic".Trial Converted = true.If you put Vincent Accountman in both groups, he'll be in conflicting sandboxes for the Accounts table, and get an error message whenever he tries to use Accounts in Metabase.
To resolve data sandbox permissions conflicts:
Data sandbox permissions don't apply to the results of SQL questions. That is, saved SQL questions will always display results from the original table rather than the sandboxed table.
Say that you have an custom sandbox which hides the Email column from the Accounts table. If a non-sandboxed person creates a SQL question that includes the Email column, anyone with collection permissions to view that SQL question will be able to:
To prevent the Email column from being exposed via a SQL question:
Collection permissions must be used to prevent sandboxed groups from viewing saved SQL questions that reference sandboxed tables. That's why, when you create an custom sandbox, you have to put the saved SQL question (the one you want to display in the sandbox) in an admin-only collection.
Data sandbox permissions don't apply to public questions or public dashboards. If a non-sandboxed person creates a public link using an original table, the original table will be displayed to anyone who has the public link URL.
To prevent this from happening, you'll have to disable public sharing for your Metabase instance.
Metabase can only create a data sandbox using the group membership or user attributes of people who are logged in. Since public links don’t require logins, Metabase won’t have enough info to create the sandbox.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )