About row-level security (RLS)
Row-level security (RLS) allows you to restrict access to table row data at group-level or user-level. You do this by creating a rule that associates a filter with a group. When a group member searches, views an Answer, or otherwise works with data, ThoughtSpot evaluates the rules and prevents the display of the restricted data. Users see only the data they are permitted to see.
How does RLS impact user interactions?
The security rules apply to objects shared with users individually or through groups they are a member of. The rules restrict the visible data when users:
-
view a table
-
view a Worksheet derived from the table
-
search for data in the Worksheet or table
-
view Answers from restricted data - either that they’ve created or that were shared with them
-
interact with Liveboards from restricted data - either that they’ve created or that were shared with them
Search suggestions also fall under row-level security. If a user would not have access to the row data, then values from the row do not appear in Search suggestions.
If RLS is applied to the cluster, and the creator of a Liveboard sets up default values in a Liveboard filter, the default values will be visible to everyone who has access to the Liveboard in the filter chip preview and in the tooltip. The data is filtered based on RLS, but the filter chip preview and tooltip do not follow RLS.
If you are using pass-through security for a Snowflake or Google BigQuery connection, search suggestions may not fall under row-level security. When using pass-through security, ThoughtSpot builds the search index on the user who created the connection. This user may have less restrictive row-level-security, or may be able to see all data. Other users may be able to see search suggestions for columns or values they should not see. They cannot run queries on these columns or values, however. If you are using pass-through security, ThoughtSpot recommends you turn off indexing for sensitive columns.
Why use RLS?
RLS allows you to set up flexible rules that are self-maintaining. An RLS configuration can handle thousands of groups. There are several reasons you might want to use row-level security:
- Hide sensitive data from groups who should not see it
-
In a report with customer details, hide potential customers (those who have not yet completed their purchase) from everyone except the sales group.
- Filter tables to reduce their size, so that only the relevant data is visible
-
Reduce the number of rows that appear in a very large table of baseball players, so that players who are no longer active are not shown except to historians.
- Enable creation of a single Liveboard or visualization, which can display different data depending on the group who is accessing it
-
Create one sales Liveboard that shows only the sales in the region of the person who views it. This effectively creates a personalized Liveboard, depending on the viewer’s region.
Related information
To continue learning about RLS, see How rule-based RLS works.
Search suggestions relies on compile indices to present suggestions to users from your data. See Manage suggestion indexing to learn how to configure suggestions.