You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@superset.apache.org by GitBox <gi...@apache.org> on 2020/10/08 07:43:27 UTC

[GitHub] [incubator-superset] bolkedebruin opened a new issue #11198: [SIP-?] Extending the security framework to provide data level security

bolkedebruin opened a new issue #11198:
URL: https://github.com/apache/incubator-superset/issues/11198

## [SIP] Proposal for Extending the security framework to provide data level security

### Motivation

In certain Enterprises. like for example financial services, it is often required to limit the accessibility of data to certain people and to have the ability to manage this centrally. This means that users only have a limited ability to publish results in dashboards to a broader public.

Typically this is managed on the data/resource level. For example user "bolke" has access to transaction data from Asia but cannot access transaction from Europe. It might be that "bolke" has access to aggregated data, like a dashboard or a chart, but not to the original datasource.

In such a context you would like to be able to set permissions in a leveled way like:

1. Dashboard
2. Chart -> (Table / View, Function, Column(s))

This type of resource based access is equal to for example what is implemented in Presto.

Superset currently does not have such a model. It only implements table/schema/database with row level filtering it does not have a fine grained permission model on dashboards and charts. This limits the usability in a enterprise context. It also has a technical limitation as we cannot enable the cache as that ignores the permission model that works on the database level (e.g. Presto, Druid etc).

### Proposed Change

A new decorator `@has_access_resource` that takes the resource type, resource name, and its specification (e.g. Chart -> type, table/view, metric, column(s). The request itself (GET/POST) should also be available to this decorator as permissions might be dependent on time of the day, geolocation etc.

Permission checks can be expensive (we have over 1500 policies). Therefore I suggest a default "pass" implementation also for backwards compatibility. The check itself can then be 'outsourced' to highly optimized systems like Open Policy Agent or Apache Ranger.

### New or Changed Public Interfaces

Optionally a Securitymanager that implements `has_access_resource` can be provided in the configuration

### New dependencies

None

### Migration Plan and Compatibility

None, this is backwards compatible.

### Rejected Alternatives

It was mentioned that column access could be solved by proxy with views that expose subsets of columns. This creates an extra burden either in maintaining the Dashboard (which is the not possible to centrally manage) or with the Database team , while the global cache can still not be enabled.

cc @mistercrunch

----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org