apache
Simple auth manager
Description
The purpose of this task is to describe the auth manager that is intended to be the default auth manager in Airflow 3. For convenience, we'll call it simple auth manager. See auth manager documentation for more details about what is an auth manager.
Use case/motivation
As part of AIP-79, we want to remove FAB from Airflow 3. The current default auth manager in Airflow 2 is based on FAB (FabAuthManager). Therefore, to achieve this goal, we need to find a replacement of FabAuthManager as default auth manager in Airflow 3.
The intended usage of this new auth manager is only for development and testing purposes. It should not be used in production. It should only support some default set of Roles and no flexibility in defining roles or mapping them to capabilities (resource types it can access and whether they can be read or written). For production use cases, other auth managers will be implemented later/separately (e.g. KeyCloak auth manager, Casdoor auth manager, ...).
Simple auth manager is fully config-controlled, it will not use the database.
List of users
The idea is to have the list of users defined in config. The current config format used in Airflow (INI format) does not allow lists, therefore a workaround will need to be found to represent such list of users. This can be done during implementation. On the high level, the list of users will look like this. The format used here is JSON but this is just for the example, as mentioned before, the exact format will be defined during implementation.
users = [
{
username: "admin",
password: "admin"
role: "Admin"
},
{
username: "john",
password: "my-secret-password"
role: "Viewer"
}
]
If the Airflow config format changes in the future (say, TOML), we will consider leveraging this new format to represent the different users.
Roles
The roles will be defined as part of the simple auth manager. It will not be configurable neither extendable. It will not be possible by the user to configure/add/modify roles in the simple auth manager. The predefined roles in the simple auth manager are the roles coming out of the box in FabAuthManager as defined in the documentation. Here are the roles:
- Viewer
- User
- Op
- Admin
The permissions associated to each role will correspond to the permissions defined in the documentation .
Disable authentication
For development purposes, we might want to disable the authentication and give all permissions to anyone accessing the Airflow environment. The simple auth manager will have such option that can be set through configuration.
Related issues
No response
Are you willing to submit a PR?
- [X] Yes I am willing to submit a PR!
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
An easy place to put the config (in the meantime?) would be in the webserver_config. I imagine that will live on regardless of whether FAB is used or not.
An easy place to put the config (in the meantime?) would be in the webserver_config. I imagine that will live on regardless of whether FAB is used or not.
Nice, I did not think about that. That would work nicely indeed
An easy place to put the config (in the meantime?) would be in the webserver_config. I imagine that will live on regardless of whether FAB is used or not.
Nice, I did not think about that. That would work nicely indeed
Yes. Then it will make it python-configuration, not config file.
The idea is to have the list of users defined in config. The current config format used in Airflow (INI format) does not allow lists, therefore a workaround will need to be found to represent such list of users. This can be done during implementation. On the high level, the list of users will look like this. The format used here is JSON but this is just for the example, as mentioned before, the exact format will be defined during implementation.
And yes as the next step - part of the https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components was to change airflow config to use TOML (which is basically an extension of .ini) - we could start implementing it next and move configuration there - but webserver config is better to start with.
Other than that - yes - that sounds like a good description of the auth manager. Also I think it should have an easy way to disable authentication - (say via additional configuration) - then it could use "admin" user by default and could be set in whatever development environment we will have in Airflow 3.
Other than that - yes - that sounds like a good description of the auth manager. Also I think it should have an easy way to disable authentication - (say via additional configuration) - then it could use "admin" user by default and could be set in whatever development environment we will have in Airflow 3.
True, I forgot to mention this feature. Let me update the issue