Я думаю, что здесь есть две разные проблемы:
Во-первых, аутентификация LDAP. Airflow обеспечивает поддержку аутентификации LDAP на базе ldap3 . Пример в связанном документе показывает, как связать роли Airflow с группами LDAP (например, часть data_profiler_filter).
Во-вторых, ограничение доступа DAG по группе. На момент написания этой статьи текущая версия Airflow (1.9) не поддерживает ограничение видимости групп доступности баз данных по группам. Недавняя работа над управлением доступом на основе ролей (RBAC) меняет это. Я перечислил 3 различных варианта решения этой проблемы ниже.
Вариант 1 - RBAC (большая часть управления доступна в Airflow ≥ 1.10)
Новые функции RBAC добавляют поддержку для таких разрешений и являются лучшими для детального контроля. Он использует систему разрешений, построенную на Flask App Builder. Он был создан компанией с очень похожим сценарием использования, о котором вы упомянули, что более подробно обсуждается в проблеме Jira.
Более подробную информацию можно найти в:
Пользовательский интерфейс веб-сервера RBAC теперь доступен на главном сервере в airflow / www_rbac . Другие функции, относящиеся к RBAC, также активно разрабатываются для дальнейшего повышения безопасности в многопользовательской среде.
Примечание. Также ведется работа над новой функцией контроля доступа на уровне DAG (DLAC) в AIRFLOW-2267 , которая основана на работе RBAC для введения еще более детального управления. Более подробную информацию можно найти в дизайн документа и PR # 3197 .
Вариант 2 - Многопользовательский режим с владельцами (самый простой, доступен в Airflow <1.10) </h2>
Второй вариант, который можно рассмотреть для среднезернистого управления, - это многопользовательская настройка с использованием webserver.filter_by_owner и установка одного явного owner (пользователь, а не группа) для каждой группы доступности базы данных. «При этом пользователь будет видеть только те ярлыки, владельцем которых он является, если только он не является суперпользователем».
В сторону: Связанная функция, которая может вас заинтересовать в запуске задач от имени пользователя с олицетворением с использованием run_as_user или core.default_impersonation.
Вариант 3 - Запуск нескольких отдельных экземпляров воздушного потока (максимальная изоляция)
Третий вариант грубого контроля, который выбирают некоторые компании, - запуск нескольких отдельных экземпляров Airflow, по одному на команду. Это, пожалуй, наиболее практичный вариант для тех, кто сегодня хочет использовать группы DAG для нескольких команд в изоляции. Если вы используете Astronomer Enterprise , мы поддерживаем раскручивание нескольких экземпляров Airflow.