potiuk commented on issue #57966: URL: https://github.com/apache/airflow/issues/57966#issuecomment-3577317770
I also like the endpoint that @pierrejeambrun proposed - it is exactly how Auth Manager has been designed. In Auth Manager design we made a DELIBERATE decision that we delegate roles, groups and other decision making to the Auth Manager. Aiflow just wants to do very simple Auth mechanism: * I am user X, Can i do that ? or Can I do this group of things ? (for performance). > I like the idea of having role-based authorization available in addition to the permissions based as a convenience With Auth Manager change in Airflow 3, Airflow has **NO** Role notion. Airflow has no RBAC at all. The "Role" part does not exist in Airflow. Nill. Zippo, Instead: * FAB provider has it's own RBAC (FAB also has Groups that map to Roles but we do not use that feature and do not plan to). * Keycloack has far more sophisticated mechanims that you can define as you like. It implements: User-Based, Scope-Based, Role-Based, Time-based, Javascript-Based, Group-Based access control, and you can even combine all those in Aggregated policies. For example it might mean that you as a user have access to trigger specific Dag only between 9 and 17 in weekdays. Regardless of your Role. And there is no way this can be simply mapped to "Role". No way. You can read more here https://www.keycloak.org/docs/latest/authorization_services/#configuration Again - the decision to move away from RBAC "built-in" in Airflow 2 (where FAB was the only way you could configure access) was absolutely deliberate. Airflow does not need to define roles or access control models - this is something that is delegated out, we absolutely do not want to know what model was used, we want to know if certain operation is allowed by the user. That's all we need and want to know. This makes deployment manager more involved and responsible for properly defining and understanding the permissions - and we provide some templates for that, and FAB can still be used by those who want to have UI and options to configure it there with some Admin, Viewer etc. roles defined as convenience and easy way to transit from Airflow 2. And I think we even have more and similar keycloak configuration to start with https://airflow.apache.org/docs/apache-airflow-providers-keycloak/stable/auth-manager/manage/permissions.html . We are not likely to ever want to have "Role" defined in Airflow itself - that would be a huge step back. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
