-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Config-as-code for roles and access controls #34718
Comments
We do this in add_roles = ["abc", "def", "ghi"]
AirflowSecurityManager.ROLE_CONFIGS.extend(
[
{"role": role, "perms": AirflowSecurityManager.VIEWER_PERMISSIONS + AirflowSecurityManager.USER_PERMISSIONS}
for role in add_roles
]
) This is supported as much as we're using these primitives available to us. FYI we use a custom SecurityManager (parent is of course Hope this helps. |
Thanks a lot @troxil, this solution is a good step in the right direction.
Example: RolePermission = tuple[str, str]
def mutate_role_configs(original_role_configs: list[dict[str, str | list[RolePermission]]],
rolename: str,
*,
adds: list[RolePermission],
removes: list[RolePermission]):
new_role_configs = copy.deepcopy(original_role_configs)
for rc in new_role_configs:
if rc["role"] != rolename:
continue
for r in removes:
rc["perms"].remove(r)
rc["perms"].extend(adds)
return new_role_configs
raise Exception(f"Did not find role matching name {rolename}")
class MySecurityManager(AirflowSecurityManager):
# USER_PERMISSIONS = ..... can not be set because ROLE_CONFIGS in parent class already created
ROLE_CONFIGS = mutate_role_configs(AirflowSecurityManager.ROLE_CONFIGS,
"User",
adds=[],
removes=[
(permissions.ACTION_CAN_DELETE, permissions.RESOURCE_DAG)
])
SECURITY_MANAGER_CLASS = MySecurityManager |
To be honest - I think instead of making this as a code, you should look at the AIP-56 implementation that is well in progress. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management. We are moving away eventually from FAB authentication and replacing it with Auth Managers. It will require to upgrade to future versions of Airflow (2.8 possibly 2.9). but this is much more future-proof approach eventually. Once this is implemented what you are trying to do is lilkely you should manage authentication outside of Airflow and rather than syncing it to FAB User/Roles you should write your own custom Auth Manager that will implement whatever access scheme you want there. It will be overall way simpler and will allow you to also manage more complex schemes - depending on your needs. My advise would be that instead of trying to see how you can fit-in FAB syncing and having it done with FAB you should look (once we release it @hterik / @troxil ) into writing a custom Auth Manager and possibly being the first ones to try it out (and possibly let us improve what we will come up with). Of course it's much more "future" and maybe you will choose to implement and contribute something to the current FAB manager (we will keep it around and you will still be able to use it and contribute to it), but once we release AIP-56 and prove that it works, I doubt any maintainer focus will be on doing something in FAB as it will be on its way out eventually. cc: @vincbeck -> Vinc is looking for people who would like to (when ready) make use of the Auth Manager new APIs and provide feedback, so I think it would be a good idea you consider it and talk. |
Strongly on this one, sticking with FAB manager works for the short term but eventually, on the long run, we want to get rid of it. Happy to discuss and give you more details if needed |
This issue has been automatically marked as stale because it has been open for 14 days with no response from the author. It will be closed in next 7 days if no further activity occurs from the issue author. |
This issue has been closed because it has not received response from the issue author. |
Description
We want to create custom roles in airflow that inherit the standard roles described on https://airflow.apache.org/docs/apache-airflow/2.7.1/security/access-control.html,
More specifically, we want a derivative of
User
that can not delete dags and that has access to cluster activity dashboard. Otherwise all the permissions fromUser
+Viewer
should be inherited. (Recommendation from page above is to not alter the existing roles, instead create new ones)Creating new roles using the web ui is very tedious and error prone, without good review-process or git log history.
Moreover, our entire Airflow installation is based on config-as-code so nobody has the admin role in Airflow and can create new roles easily, without having to login as root under the hood.
Using configuration as code to create the roles would make this process a lot easier.
Proposal is a new python-function in
airflow_local_settings.py
, where one can read theAirflowSecurityManager.USER_PERMISSIONS
programmatically to add/exclude permissions from the new returned role. These would take effect on next webserver restart.I don't know if there is any requirements on history for removed permissions/roles that could cause problem if one simply adds/removes roles there?
As workaround i'm now considering a combo of
airflow roles list -p -o json
+ processing +airflow roles import
.Is it possible to maybe just call the internal functions
patch_role
post_role
? In that case when should one do that? Just once and then it will be persisted in DB?Use case/motivation
No response
Related issues
No response
Are you willing to submit a PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: