Контроль доступа к DAG в Apache AirFlow: роли, ресурсы, разрешения

Добавляя в наши курсы для дата-инженеров по Apache Airflow полезные примеры, сегодня рассмотрим тонкости контроля доступа к DAG в этой платформе. Читайте далее, какие роли есть в Apache Airflow, каковы разрешения для них и как Flask AppBuilder осуществляет управление доступом к пользовательскому интерфейсу веб-сервера.

Безопасность DAG’ов в Apache AirFlow: роли и разрешения

Проблема разграничения доступа к DAG’ам в Apache AirFlow актуальна для больших компаний с разными командами дата-инженеров. Управление доступом к пользовательскому интерфейсу веб-сервера Airflow осуществляется с помощью Flask AppBuilder – быстрой среды разработки приложений на базе Python-фреймворка Flask. Начиная с версии Airflow 1.10 авторизация на основе ролей (RBAC) поддерживается с использованием FlaskAppBuilder.

Вообще FlaskAppBuilder поддерживает 5 методов аутентификации:

Database, когда имя пользователя и пароль сравниваются с хранящимися в базе данных (пароли хранятся в хэшированном виде);
Open ID – по идентификатору электронной почты пользователя в Gmail, Yahoo и пр.;
LDAP — аутентификация на сервере LDAP, например, Microsoft Active Directory. Для этого потребуется установить python-ldap – объектно-ориентированный API для доступа к серверам каталогов LDAP из программ Python.
REMOTE_USER – проверка соответствия переменной среды веб-сервера REMOTE_USER данным в таблице пользователей платформы. Ответственность за аутентификацию пользователя лежит на веб-сервере. Это подходит для внутренних сетей, когда сервер (Apache, Nginx) настроен на использование защищенного протокола Kerberos, и пользователю не нужно входить в систему с именем пользователя и паролем на FlaskAppBuilder.
OAUTH — открытый протокол авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей логин и пароль. Для этого потребуется установить Python-библиотеку AuthLib. Используя этот метод, можно использовать API-интерфейсы провайдера OAUTH, запрашивая у пользователя разрешение на управление его учетной записью пользователя.

Можно настроить, какой пользовательский интерфейс будет использоваться, установив rbac = True. Для поддержки представлений и ссылок подключаемых модулей для обеих версий пользовательского интерфейса и обеспечения обратной совместимости в класс AirflowTestPlugin были добавлены поля appbuilder_views и appbuilder_menu_items. Поле appbuilder_views поддерживает представления с меню (views-with-menu) и без меню (views-without-menu). Чтобы добавить меню в представление, следует внести ключ «name» в словарь его пакета. Иначе представление будет добавлено во Flask appbuilder без пункта меню.

По умолчанию Airflow поставляется с набором ролей по умолчанию (Default Roles):

Admin (Администратор), который имеет все возможные разрешения, включая предоставление или отзыв разрешений для других пользователей;
Viewer (Зритель) — имеет ограниченные права просмотра без возможности изменения DAG’а;
User (Пользователь) — имеет разрешения Viewer и дополнительные пользовательские разрешения в веб-представлениях пользователя, которые аналогичны веб-представлениям зрителя;
Op (Оператор) – имеет права пользователя и дополнительные разрешения в веб-представлениях пользователя;
Public (Анонимный пользователь) – не имеет разрешений.

Только администраторы могут настраивать или изменять разрешения для других ролей. Не рекомендуется, чтобы пользователи с правами администратора каким-либо образом изменяли эти роли по умолчанию, удаляя или добавляя разрешения для этих ролей. Все роли по умолчанию могут иметь доступ к представлению DAG (Directed Acyclic Graph).

Например, можно задать по умолчанию всем пользователям роль Viewer, чтобы предупредить опасность изменения чужих DAG’ов. Разработчик Data Flow указывает в коде DAG роли для членов своей команды, чтобы администратор AirFlow назначил их конкретным пользователям.

Data Pipeline на Apache Airflow

Код курса

AIRF

Ближайшая дата курса

27 ноября, 2024

Продолжительность

24 ак.часов

Стоимость обучения

72 000 руб.

Также Apache AirFlow позволяет поддерживает настраиваемые роли (Custom Roles) на уровне DAG. В частности, администратор может создать набор ролей, которым разрешено просматривать только определенный набор DAG’ов. Каждый Directed Acyclic Graph, определенный в таблице модели DAG, рассматривается как представление (View), у которого есть два связанных с ним разрешения: на чтение (can_read) и на редактирование (can_edit). Ранее были разрешения can_dag_read и can_dag_edit, но в последней версии фреймворка 2.0, о новинках которой мы писали здесь, разрешения can_dag_read и can_dag_edit устарели. В текущей версии Apache AirFlow существует специальное представление, называемое DAGs, которое позволяет роли получать доступ ко всем DAG’ам. Ранее оно называлось all_dags. К примеру, ранее в коде DAG можно было настроить атрибут access_control с указанием роли и права на конкретный Directed Acyclic Graph:

access_control={

«dataplatform»: {«can_dag_edit»},

}

Разрешения на основе ресурсов

Начиная с версии 2.0, в Apache AirFlow разрешения основаны на отдельных ресурсах и небольшом подмножестве действий с ними. Ресурсы соответствуют ключевым концепциям Airflow: DAG, DAGRun, Task и Connection. Действия включают возможности создания (can_create), чтения (can_read), редактирования (can_edit) и удаления (can_delete). Разрешения определяются парой «ресурс» + «действие» и добавляются к роли. Поскольку AirFlow предоставляет RESTful API, то для доступа к конечной точке пользователю необходимы все назначенные ей разрешения. Для каждой конечной точки определена минимальная роль с набором разрешений, чтобы обеспечить выполнение методов REST-протокола (GET, POST, DELETE, PATCH).

Для разрешений на уровне DAG доступ можно контролировать для всех его объектов: DAGs.can_create, DAGs.can_read, DAGs.can_edit и DAGs.can_delete. Когда эти разрешения указаны в списке, доступ предоставляется пользователям, которым оно назначено или которые имеют аналогичное разрешение для конкретного DAG. Для отдельных DAG’ов имя ресурса соответствует названию DAG’а + его идентификатор (ID).

Например, если пользователь пытается просмотреть информацию о DAG с названием example_dag_id, а конечной точке требуется разрешение DAGs.can_read, доступ будет предоставлен, если у пользователя есть разрешение DAGs.can_read или DAG: example_dag_id.can_read.

Airflow Flask AppBuilder, обучение Airflow курсы, обучение дата-инженер курсы, Школа Больших Данных Учебный Центр Коммерсант — Добавление настраиваемой роли и определение разрешений для нее в Apache AirFlow

Больше подробностей про администрирование и эксплуатацию Apache AirFlow для построения ETL/ELT-процессов и разработки сложных конвейеров аналитики больших данных с Hadoop и Spark вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Смотреть расписание

Записаться на курс

Источники