You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@superset.apache.org by Gerard Toonstra <gt...@gmail.com> on 2017/10/18 12:30:26 UTC

Q's about (data) security in superset

Hi,

I'm looking at superset to maybe become a supporting tool for ad-hoc
reporting work. My questions are related to its security model:

- Specific metrics can be hidden for particular reports, which I assume is
column-level security. From the documentation page however, it seems that
this is only implemented for druid data sources?

- (How) is row level security implemented in superset?  Can you have a full
table extract somewhere and, depending on the login of the user, apply a
static filter that the user cannot remove from the dashboard, so it only
shows the extracted row for that user?  Such a simple setup would work for
us already.

Rgds,

Gerard

Re: Q's about (data) security in superset

Posted by Alex Woolford <al...@woolford.io>.
Hi Gerard,

Row level security would be implemented on the database, rather than within
Superset.

When you setup the database connection you'll want to check the
'Impersonate queries to the database' box.

I just tested row-based filtering, in Superset, against a Hive table. The
row-based filter was enforced via a Ranger policy. It worked perfectly.

Cheers,

Alex

On Wed, Oct 18, 2017 at 6:30 AM, Gerard Toonstra <gt...@gmail.com>
wrote:

> Hi,
>
> I'm looking at superset to maybe become a supporting tool for ad-hoc
> reporting work. My questions are related to its security model:
>
> - Specific metrics can be hidden for particular reports, which I assume is
> column-level security. From the documentation page however, it seems that
> this is only implemented for druid data sources?
>
> - (How) is row level security implemented in superset?  Can you have a full
> table extract somewhere and, depending on the login of the user, apply a
> static filter that the user cannot remove from the dashboard, so it only
> shows the extracted row for that user?  Such a simple setup would work for
> us already.
>
> Rgds,
>
> Gerard
>