Quicksight RLS and LakeFormation RLS

I have a general question on Row-level security in Quicksight. Assuming you are using LakeFormation, does LakeFormation RLS generally replace the need for Quicksight’s RLS?

@jochapjo LakeFormation RLS and QuickSight RLS are designed for different purpose.
LakeFormation RLS is targeted on data access of Author and Admin. For example, when you set an author only can view partial data in a table, the datasets this author created will only contain these partial data. The data ingestion will only ingest these partial data into QuickSight. So, if you open the data prep of a dataset, you only can view the rows defined as “allow” in the LF RLS.
QuickSight RLS is different. It is more for reader experience. All the data of that table actually are stored in the dataset, hosted in QuickSight service. If an author edit the dataset, in the preview section of data prep, this author can view the data no matter the RLS policy it is. But, in analysis/dashboard, the user only can view partial data defined in the RLS policy.

2 Likes

Hi @Ying_Wang, I would like to reopen this (old) discussion by adding two more questions related to the original question, which could be useful for the community and I can’t find answers to elsewhere.

  1. What happens after the data has been ingested into Quicksight if LakeFormation RLS (Row-Level Security) rules are changed? For example, if I remove or add different permissions, will the Author still see the “old” version of permissions (and therefore the data)? If so, is there any way to update the permissions, perhaps by using a direct query instead of SPICE?

  2. Does your answer also apply to LF-Tags (LakeFormation Tags)? Are they “forwarded” in any way to the Quicksight dataset when they are assigned to the Quicksight viewer ARN, or are they completely ignored if the author has the power to ingest the dataset?