2019-01-22 11:21:13 -05:00
|
|
|
.. Licensed to the Apache Software Foundation (ASF) under one
|
|
|
|
or more contributor license agreements. See the NOTICE file
|
|
|
|
distributed with this work for additional information
|
|
|
|
regarding copyright ownership. The ASF licenses this file
|
|
|
|
to you under the Apache License, Version 2.0 (the
|
|
|
|
"License"); you may not use this file except in compliance
|
|
|
|
with the License. You may obtain a copy of the License at
|
|
|
|
|
|
|
|
.. http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
|
|
|
.. Unless required by applicable law or agreed to in writing,
|
|
|
|
software distributed under the License is distributed on an
|
|
|
|
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
|
|
|
KIND, either express or implied. See the License for the
|
|
|
|
specific language governing permissions and limitations
|
|
|
|
under the License.
|
|
|
|
|
2016-06-03 14:33:11 -04:00
|
|
|
Security
|
|
|
|
========
|
2016-11-10 02:08:22 -05:00
|
|
|
Security in Superset is handled by Flask AppBuilder (FAB). FAB is a
|
2016-06-03 14:33:11 -04:00
|
|
|
"Simple and rapid application development framework, built on top of Flask.".
|
|
|
|
FAB provides authentication, user management, permissions and roles.
|
chore: deprecate restricted metrics (#8197)
* chore: deprecate restricted metrics
An early community contribution added the concept of restricted metrics.
The idea was to allow for some metrics to be restricted, and if a metric
was tagged as such, a user would need to be given access to that metric
more explicitely, through a special perm we would maintain for that
metric.
Now since the new concept of "Adhoc Metrics", the popover that lets a
user pick a column and an aggregate function or to write their own SQL
expression inline, this restriction is completely bypassed. Adhoc
metrics was developed without the restricted metrics in mind.
Anyhow, in the near future, we'll be rethinking the ideas behind
data-access permissions, and things like column-level or row-level
security will be redesigned from scratch.
By deprecating this feature, we're removing a confusing and mostly broken
feature, and making it easy to move forward
* Use context manager to drop columns
* disable jest's maxWorkers
2019-09-09 20:20:32 -04:00
|
|
|
Please read its `Security documentation
|
2019-03-18 02:21:32 -04:00
|
|
|
<https://flask-appbuilder.readthedocs.io/en/latest/security.html>`_.
|
2016-06-03 14:33:11 -04:00
|
|
|
|
|
|
|
Provided Roles
|
|
|
|
--------------
|
2016-11-17 14:58:33 -05:00
|
|
|
Superset ships with a set of roles that are handled by Superset itself.
|
|
|
|
You can assume that these roles will stay up-to-date as Superset evolves.
|
2017-12-26 02:39:28 -05:00
|
|
|
Even though it's possible for ``Admin`` users to do so, it is not recommended
|
2016-11-17 14:58:33 -05:00
|
|
|
that you alter these roles in any way by removing
|
|
|
|
or adding permissions to them as these roles will be re-synchronized to
|
|
|
|
their original values as you run your next ``superset init`` command.
|
|
|
|
|
|
|
|
Since it's not recommended to alter the roles described here, it's right
|
|
|
|
to assume that your security strategy should be to compose user access based
|
|
|
|
on these base roles and roles that you create. For instance you could
|
2018-10-31 16:30:15 -04:00
|
|
|
create a role ``Financial Analyst`` that would be made of a set of permissions
|
2016-11-17 14:58:33 -05:00
|
|
|
to a set of data sources (tables) and/or databases. Users would then be
|
|
|
|
granted ``Gamma``, ``Financial Analyst``, and perhaps ``sql_lab``.
|
2016-06-03 14:33:11 -04:00
|
|
|
|
|
|
|
Admin
|
|
|
|
"""""
|
2016-09-23 16:22:56 -04:00
|
|
|
Admins have all possible rights, including granting or revoking rights from
|
|
|
|
other users and altering other people's slices and dashboards.
|
2016-06-03 14:33:11 -04:00
|
|
|
|
|
|
|
Alpha
|
|
|
|
"""""
|
2018-10-31 16:30:15 -04:00
|
|
|
Alpha users have access to all data sources, but they cannot grant or revoke access
|
2016-06-03 14:33:11 -04:00
|
|
|
from other users. They are also limited to altering the objects that they
|
|
|
|
own. Alpha users can add and alter data sources.
|
|
|
|
|
|
|
|
Gamma
|
|
|
|
"""""
|
2018-10-31 16:30:15 -04:00
|
|
|
Gamma users have limited access. They can only consume data coming from data sources
|
2017-09-14 20:41:01 -04:00
|
|
|
they have been given access to through another complementary role.
|
2016-06-03 14:33:11 -04:00
|
|
|
They only have access to view the slices and
|
|
|
|
dashboards made from data sources that they have access to. Currently Gamma
|
|
|
|
users are not able to alter or add data sources. We assume that they are
|
|
|
|
mostly content consumers, though they can create slices and dashboards.
|
|
|
|
|
|
|
|
Also note that when Gamma users look at the dashboards and slices list view,
|
|
|
|
they will only see the objects that they have access to.
|
|
|
|
|
2016-11-17 14:58:33 -05:00
|
|
|
sql_lab
|
|
|
|
"""""""
|
|
|
|
The ``sql_lab`` role grants access to SQL Lab. Note that while ``Admin``
|
|
|
|
users have access to all databases by default, both ``Alpha`` and ``Gamma``
|
|
|
|
users need to be given access on a per database basis.
|
|
|
|
|
2017-03-27 20:51:41 -04:00
|
|
|
Public
|
|
|
|
""""""
|
|
|
|
It's possible to allow logged out users to access some Superset features.
|
|
|
|
|
|
|
|
By setting ``PUBLIC_ROLE_LIKE_GAMMA = True`` in your ``superset_config.py``,
|
|
|
|
you grant public role the same set of permissions as for the GAMMA role.
|
|
|
|
This is useful if one wants to enable anonymous users to view
|
|
|
|
dashboards. Explicit grant on specific datasets is still required, meaning
|
|
|
|
that you need to edit the ``Public`` role and add the Public data sources
|
|
|
|
to the role manually.
|
|
|
|
|
2016-06-03 14:33:11 -04:00
|
|
|
|
|
|
|
Managing Gamma per data source access
|
|
|
|
-------------------------------------
|
|
|
|
Here's how to provide users access to only specific datasets. First make
|
|
|
|
sure the users with limited access have [only] the Gamma role assigned to
|
|
|
|
them. Second, create a new role (``Menu -> Security -> List Roles``) and
|
|
|
|
click the ``+`` sign.
|
|
|
|
|
2020-02-09 20:53:56 -05:00
|
|
|
.. image:: _static/images/create_role.png
|
2016-06-03 14:33:11 -04:00
|
|
|
:scale: 50 %
|
|
|
|
|
|
|
|
This new window allows you to give this new role a name, attribute it to users
|
|
|
|
and select the tables in the ``Permissions`` dropdown. To select the data
|
2018-10-31 16:30:15 -04:00
|
|
|
sources you want to associate with this role, simply click on the dropdown
|
2016-06-03 14:33:11 -04:00
|
|
|
and use the typeahead to search for your table names.
|
|
|
|
|
|
|
|
You can then confirm with your Gamma users that they see the objects
|
|
|
|
(dashboards and slices) associated with the tables related to their roles.
|
|
|
|
|
|
|
|
|
|
|
|
Customizing
|
|
|
|
-----------
|
|
|
|
|
|
|
|
The permissions exposed by FAB are very granular and allow for a great level
|
|
|
|
of customization. FAB creates many permissions automagically for each model
|
2018-10-31 16:30:15 -04:00
|
|
|
that is created (can_add, can_delete, can_show, can_edit, ...) as well as for
|
2016-11-10 02:08:22 -05:00
|
|
|
each view. On top of that, Superset can expose more granular permissions like
|
2016-06-03 14:33:11 -04:00
|
|
|
``all_datasource_access``.
|
|
|
|
|
|
|
|
We do not recommend altering the 3 base roles as there
|
2018-10-31 16:30:15 -04:00
|
|
|
are a set of assumptions that Superset is built upon. It is possible though for
|
2016-06-03 14:33:11 -04:00
|
|
|
you to create your own roles, and union them to existing ones.
|
|
|
|
|
2016-09-23 16:22:56 -04:00
|
|
|
Permissions
|
|
|
|
"""""""""""
|
|
|
|
|
2016-11-10 02:08:22 -05:00
|
|
|
Roles are composed of a set of permissions, and Superset has many categories
|
2016-09-23 16:22:56 -04:00
|
|
|
of permissions. Here are the different categories of permissions:
|
|
|
|
|
|
|
|
- **Model & action**: models are entities like ``Dashboard``,
|
|
|
|
``Slice``, or ``User``. Each model has a fixed set of permissions, like
|
|
|
|
``can_edit``, ``can_show``, ``can_delete``, ``can_list``, ``can_add``, and
|
|
|
|
so on. By adding ``can_delete on Dashboard`` to a role, and granting that
|
|
|
|
role to a user, this user will be able to delete dashboards.
|
|
|
|
- **Views**: views are individual web pages, like the ``explore`` view or the
|
2018-10-31 16:30:15 -04:00
|
|
|
``SQL Lab`` view. When granted to a user, he/she will see that view in its menu items, and be able to load that page.
|
2016-09-23 16:22:56 -04:00
|
|
|
- **Data source**: For each data source, a permission is created. If the user
|
|
|
|
does not have the ``all_datasource_access`` permission granted, the user
|
|
|
|
will only be able to see Slices or explore the data sources that are granted
|
|
|
|
to them
|
|
|
|
- **Database**: Granting access to a database allows for the user to access
|
|
|
|
all data sources within that database, and will enable the user to query
|
|
|
|
that database in SQL Lab, provided that the SQL Lab specific permission
|
|
|
|
have been granted to the user
|
|
|
|
|
|
|
|
|
|
|
|
Restricting access to a subset of data sources
|
|
|
|
""""""""""""""""""""""""""""""""""""""""""""""
|
|
|
|
|
|
|
|
The best way to go is probably to give user ``Gamma`` plus one or many other
|
|
|
|
roles that would add access to specific data sources. We recommend that you
|
|
|
|
create individual roles for each access profile. Say people in your finance
|
|
|
|
department might have access to a set of databases and data sources, and
|
|
|
|
these permissions can be consolidated in a single role. Users with this
|
|
|
|
profile then need to be attributed ``Gamma`` as a foundation to the models
|
|
|
|
and views they can access, and that ``Finance`` role that is a collection
|
|
|
|
of permissions to data objects.
|
|
|
|
|
|
|
|
One user can have many roles, so a finance executive could be granted
|
|
|
|
``Gamma``, ``Finance``, and perhaps another ``Executive`` role that gather
|
|
|
|
a set of data sources that power dashboards only made available to executives.
|
|
|
|
When looking at its dashboard list, this user will only see the
|
|
|
|
list of dashboards it has access to, based on the roles and
|
|
|
|
permissions that were attributed.
|