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.

Strict RLS

This is the default setting applied to clusters. This ensures that if an RLS rule is defined then this is always included in any query to the database. A query to the database refers to both a search to return results or a query initiated from a filter widget.

This setting can be disabled so that RLS rules are only included when the table that has the rule defined is included in the search results. This behavior may be desirable for very large datasets to improve performance. That is, the rule is applied to the fact table so that these results are secured. However, the RLS rule does not need to be included for dimensional tables.

See Cluster-level settings.

Search Index and RLS

A search suggestion does not execute a query to the database. Rather, this is a value returned from the index stored by ThoughtSpot. These suggestions are displayed as Search typeahead suggestions, Liveboard Explore suggested tokens, and the Search Data column information card.

These suggestions respect RLS rules when the rule is defined explicitly on the table that the column is derived from. For example, assume the RLS rule is defined on the customer table. Then all search suggestions for the customer columns will have RLS applied. However, columns from the products table will not have the suggestions secured by this RLS rule.

As an analyst, you need to determine which tables require RLS to be applied to the suggestions. You then need to model the data in a way to ensure that the RLS rule can be defined on the table. If a data model includes multiple RLS rules, you may wish to consider disabling strict RLS.

ThoughtSpot Success Series: Row Level Security Design Patterns

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

Was this page helpful?
×