блог о bi, №1 в рунете
Создание юзеров с ограниченными правами
в Apache Superset
Разработка аналитических систем относительно конечного пользователя предполагает отсутствие лишней информации не касающейся итогового продукта. В Apache Superset это обеспечивается созданием ролевых моделей.
Платформа поставляется со стандартным набором ролей:
- Admin – администраторы, имеют все возможные права, включая предоставление или отзыв прав других пользователей и изменение чужих фрагментов и информационных панелей;
- Alfa - пользователи имеют доступ ко всем источникам данных, могут их добавлять и изменять, но не могут предоставлять или отзывать доступ другим пользователям, ограничены в изменении объектов, которыми не владеют;
- Gamma - пользователи могут потреблять данные, поступающие из источников данных, к которым им предоставлен доступ через другую дополнительную роль.
У них есть доступ только для просмотра срезов и информационных панелей, созданных из источников данных, к которым у них есть доступ;
- Роль sql_lab предоставляет доступ к SQL Lab.
Перечисленные роли хороши с точки зрения разработки, однако, ни одна из них не может подойти для конечного пользователя. Мы нашли два пути для решения проблем доступа к данным в зависимости от поставленной задачи:
1. Создание роли с ограниченными правами, которая будет включать в себя:
- доступ к опубликованным дашбордам;
- доступ к итоговым данным, но не их источникам;
- доступ к просмотру ссылок и отправке их по электронной почте;
- скрытие инструментов разработки и областей просмотра запросов.
2. Ограничение доступа к данным на уровне датасета.
Инструкция по ограничению доступа к данным приведена ниже.
1. Создание роли с ограниченными правами.
1.1 В правом верхнем углу нажимаем «Settings» => «List Roles». Откроется таблица со всеми имеющимися ролями.
- Admin – администраторы, имеют все возможные права, включая предоставление или отзыв прав других пользователей и изменение чужих фрагментов и информационных панелей;
- Alfa - пользователи имеют доступ ко всем источникам данных, могут их добавлять и изменять, но не могут предоставлять или отзывать доступ другим пользователям, ограничены в изменении объектов, которыми не владеют;
- Gamma - пользователи могут потреблять данные, поступающие из источников данных, к которым им предоставлен доступ через другую дополнительную роль.
У них есть доступ только для просмотра срезов и информационных панелей, созданных из источников данных, к которым у них есть доступ;
- Роль sql_lab предоставляет доступ к SQL Lab.
Перечисленные роли хороши с точки зрения разработки, однако, ни одна из них не может подойти для конечного пользователя. Мы нашли два пути для решения проблем доступа к данным в зависимости от поставленной задачи:
1. Создание роли с ограниченными правами, которая будет включать в себя:
- доступ к опубликованным дашбордам;
- доступ к итоговым данным, но не их источникам;
- доступ к просмотру ссылок и отправке их по электронной почте;
- скрытие инструментов разработки и областей просмотра запросов.
2. Ограничение доступа к данным на уровне датасета.
Инструкция по ограничению доступа к данным приведена ниже.
1. Создание роли с ограниченными правами.
1.1 В правом верхнем углу нажимаем «Settings» => «List Roles». Откроется таблица со всеми имеющимися ролями.
1.2 В правом верхнем углу над таблицей нажимаю «+» для создания новой роли.
Откроется меню, в котором необходимо ввести имя роли и в выпадающем списке выбрать необходимые разрешения для нее.
1.3 Список разрешений достаточных для пользовательского доступа к опубликованным дашбордам в нашей версии SuperSet (v2.0):
• can read on Chart,
• can read on Dashboard,
• can fave dashboards on Superset,
• can fave dashboards by username on Superset,
• can favstar on Superset,
• can dashboard on Superset,
• can profile on Superset,
• can recent activity on Superset,
• menu access on Dashboards,
• all datasource access on all_datasource_access,
• can get on Datasource
Если необходимо предоставить доступ к ссылкам и передаче параметров фильтров:
• can write on DashboardFilterStateRestApi,
• can read on DashboardFilterStateRestApi,
• can write on DashboardPermalinkRestApi,
• can read on DashboardPermalinkRestApi,
• can write on ExplorePermalinkRestApi,
• can read on ExplorePermalinkRestApi,
• can share dashboard on Superset,
• can share chart on Superset,
• can explore json on Superset
• can read on Chart,
• can read on Dashboard,
• can fave dashboards on Superset,
• can fave dashboards by username on Superset,
• can favstar on Superset,
• can dashboard on Superset,
• can profile on Superset,
• can recent activity on Superset,
• menu access on Dashboards,
• all datasource access on all_datasource_access,
• can get on Datasource
Если необходимо предоставить доступ к ссылкам и передаче параметров фильтров:
• can write on DashboardFilterStateRestApi,
• can read on DashboardFilterStateRestApi,
• can write on DashboardPermalinkRestApi,
• can read on DashboardPermalinkRestApi,
• can write on ExplorePermalinkRestApi,
• can read on ExplorePermalinkRestApi,
• can share dashboard on Superset,
• can share chart on Superset,
• can explore json on Superset
Нажимаем на кнопку «Save» в левом нижнем углу.
1.4 Переходим к созданию пользователя. В правом верхнем углу, по аналогии с ролями, нажимаем «Setting» => «List Users». Откроется список пользователей. Нажимаем на «+» для создания нового. В открывшемся окне необходимо заполнить следующие поля:
• First Name
• Last Name
• User Name
• Is Active? (поставить галку)
• Email
• Role (выбрать в выпадающем списке необходимую)
Задать пароль и повторить его.
1.4 Переходим к созданию пользователя. В правом верхнем углу, по аналогии с ролями, нажимаем «Setting» => «List Users». Откроется список пользователей. Нажимаем на «+» для создания нового. В открывшемся окне необходимо заполнить следующие поля:
• First Name
• Last Name
• User Name
• Is Active? (поставить галку)
• Role (выбрать в выпадающем списке необходимую)
Задать пароль и повторить его.
Нажимаем на кнопку «Save». Можно зайти под новым пользователем для проверки результата.
2. Ограничение доступа к данным на уровне датасета. Для работы этого метода необходимо обеспечить работу шаблонов Jinja. Подробно можно прочитать в статье по ссылке:
Предварительная фильтрация данных во вложенном запросе по значениям фильтров в Apache Superset
2.1 Для демонстрации решения создадим тестовый датесет и таблицу:
select 'user1' as user_name, 1 as val
union all select 'user2' as user_name, 1 as val
2. Ограничение доступа к данным на уровне датасета. Для работы этого метода необходимо обеспечить работу шаблонов Jinja. Подробно можно прочитать в статье по ссылке:
Предварительная фильтрация данных во вложенном запросе по значениям фильтров в Apache Superset
2.1 Для демонстрации решения создадим тестовый датесет и таблицу:
select 'user1' as user_name, 1 as val
union all select 'user2' as user_name, 1 as val
2.2 Заходим в «Setting» => «Row Level Security», Нажимаем «+» для создания нового фильтра. В открывшемся окне вводим имя фильтра, выбираем таблицу, которую необходимо фильтровать, роль и в последнем окне вводим условие, которое в нашем случае будет иметь вид:
user_name = '{{ current_username() }}'
где user_name – поле для фильтрации, {{ current_username() }} – запрос имени пользователя, используя шаблоны Jinja.
user_name = '{{ current_username() }}'
где user_name – поле для фильтрации, {{ current_username() }} – запрос имени пользователя, используя шаблоны Jinja.
Нажимаем кнопку «Save». Заходим под пользователем user1 для проверки результата. Тестовая таблица отображает только одну строку.
Если посмотреть запрос, то в конце таблицы мы увидим условие, который дописывается автоматически.
2.3 Если необходимо обеспечить предварительную фильтрацию данных, то условие можно добавить на уровне датасета. Преобразуем тестовый запрос для демонстрации решения
Сохраняем датасет и заходим под пользователем user1 для проверки решения. Таблица отфильтровалась именем пользователя аналогично п.2.1.
Но запрос при этом выглядит следующим образом.
