bjornhauge opened a new issue, #19633: URL: https://github.com/apache/superset/issues/19633
This feature is for minimizing data security risk, and doesn't really change the way an admin would *intend* for anything to happen (except in one minorly beneficial way). **Is your feature request related to a problem? Please describe.** Sometimes the "normal" idea is that a whole table is public, while the "specific situation" is that a user should have more limited access. But sometimes, a table is *always* supposed to have row-level security (RLS) applied to it. For example, employee salary data; special HR users should have universal access, managers have limited access, and employees only see themselves (if they have any access at all). I haven't yet found a way in Superset to make the default behavior — in absence of a security filter, that is — be to return nothing instead of everything. This seems ***extremely dangerous*** to me (forgive my emphasis if there is such a feature and I just don't know about it. I am only poking around in Superset for a little while now, and have not yet discovered everything about it.). **Describe the solution you'd like** Provide a way to tag situations where security filters are expected: - Specific `table` - Specific `table` + `role` combination In these situations, queries should return no rows (instead of all the rows) if there do not happen to be any filters. **Describe alternatives you've considered** Being super careful to never ever forget to assign someone a role with the appropriate row-level filter. The only mitigating technique I've come up with is to use a single role to *both* give access to the table in the first place *and* to filter it, at the same time. The problem is that there are some business requirements that necessitate an enormous number of roles for RLS (e.g. the employee-specific example from above), which just increases the likelihood of making an occasional mistake. Note that in the `table` + `role` combination flag above, the `role` could be one that's applied much more widely than the more specific roles for each security filter, which would substantially reduce danger in that example case, beyond what could be achieved with the existing mitigating technique. For example, flag the `employee` role + `salary` table combination as requiring security filters, and then provide those filters in employee specific roles like `emp123abc` with `emp_id = 123abc`. **Additional context** Add any other context or screenshots about the feature request here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
