Kunal8954 commented on issue #72465: URL: https://github.com/apache/airflow/issues/72465#issuecomment-5519790928
I'd like to take a shot at this. Here's a concrete design, mirroring the existing operators-and-hooks-ref/CLI-ref generators (devel-common/src/sphinx_exts/operators_and_hooks_ref.py) so it fits how this repo already auto-generates reference docs, rather than adding a new bespoke mechanism. What to introspect The full RBAC surface is already centralized on BaseAuthManager (airflow-core/src/airflow/api_fastapi/auth/managers/base_auth_manager.py): Each is_authorized_* method (configuration, connection, dag, asset, asset_alias, pool, team, variable, view, custom_view) is one resource. Its method: ResourceMethod (GET/POST/PUT/DELETE, plus MENU for is_authorized_view) is the action. DagAccessEntity and AccessView (.../auth/managers/models/resource_details.py) further scope is_authorized_dag / is_authorized_view into sub-resources (task logs, XCom, audit log, cluster activity, docs, plugins, …). The *Details dataclasses (ConnectionDetails, DagDetails, PoolDetails, TeamDetails, VariableDetails, …) describe what further narrows a check, e.g. team_name. Since every auth manager only overrides these same method signatures, a new Sphinx extension can walk BaseAuthManager with inspect (methods, their docstrings, type hints) plus the two enums, and render one reference table — resource → allowed methods → sub-entities → docstring — the same way operators_and_hooks_ref.py walks provider YAMLs into a jinja2-rendered RST table. Where it'd live A new page under airflow-core/docs/core-concepts/auth-manager/ (e.g. rbac-ref.rst), registered as a custom directive in airflow-core/docs/conf.py alongside the other custom directives. That way it rebuilds automatically whenever is_authorized_* signatures or docstrings change — no hand-maintained spec to drift out of sync, which is exactly the maintenance burden this issue describes. Happy to send a first draft PR along these lines — unless the intent is closer to a machine-readable spec (JSON/OpenAPI-shaped) that KeycloakAuthManager and similar providers could import programmatically, rather than only a human-readable RST page. Let me know if that's the direction and I'll adjust before implementing. -- 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]
