Контроль доступа к 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

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

2 июня, 2025

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

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 в Москве:

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

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

Источники