As Platform Engineers we would like to investigate the use of row-based and tag-based security to allow restricting access to data both for QS dashboard authors and viewers so that we can achieve similar level of permission granularity as we currently maintain in AP
Value / Purpose
Being able to autogenerate RLS or TBS rules from users' IAM permissions would allow us to potentially reduce the number of datasets we manage in QuickSight while maintaining the same level of access security.
What happens when a user tries to use a dataset that has more data in it than they have access to via their IAM permissions?
What happens if a user uploads a manifest file for more paths than they have access to?
How does this work for Athena-based data sets?
Definition of Done
[ ] Research and document answers to "Things we don't currently know."
[ ] Based on this research, investigate whether implementing row-based or tag-based security rules would be a viable way forward instead of managing multiple s3 manifest files.
[ ] Investigate and document whether RBS or TBS rules can be generated programmatically from user's IAM permissions
[ ] Present findings to team and recommend way forward
tom-webber
commented
8 months ago
User Story
As Platform Engineers we would like to investigate the use of row-based and tag-based security to allow restricting access to data both for QS dashboard authors and viewers so that we can achieve similar level of permission granularity as we currently maintain in AP
Value / Purpose
Being able to autogenerate RLS or TBS rules from users' IAM permissions would allow us to potentially reduce the number of datasets we manage in QuickSight while maintaining the same level of access security.
Useful Contacts
@julialawrence @Ed-Bajo
Proposal
Hypothesis
Additional Information
https://docs.aws.amazon.com/quicksight/latest/user/row-level-security.html
Things we don't currently know:
Definition of Done