Create OIDC configuration for AirFlow that allows GitLab to be used as an Identity Provider (IdP)
Until fairly recently AirFlow did not have an internal security model and required that authentication/authorization be applied using a load balancer (or some other type of security gateway). This changed with version 2.0 of AirFlow.
Previously, for Sonador, we utilized NGINX and a special configuration to secure AirFlow within the Sonador environment. This article, from the Oak-Tree blog, gives the particulars.
AirFlow 2.0 includes a large number of significant benefits, and will likely be important to users of Sonador. To that end, we need to create a configuration for the webserver that utilizes the native AirFlow components and package that into the AirFlow image we use for Sonador.
Background information on how security is handled within AirFlow 2.x:
- Access Control overview: https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html
- Flash AppBuilder authentication types: https://flask-appbuilder.readthedocs.io/en/latest/security.html
Development tasks:
-
Create a openID connect profile that allows for GitLab to be used as OpenID connect IdP (via Flask-OpenID) -
Configuration needs to support GitLab groups, so that is possible to control which users within GitLab are able to access AirFlow -
Configuration needs to allow for tuning of the access permissions and user roles based on what the user's role within GitLab is - Administrators in GitLab should also be administrators within AirFlow
-
-
Create a second blog post (similar to the one linked above) which describes how OpenID can be used within AirFlow as an identity provider