Skip to content
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

Default Airflow 2.0 RBAC unexpected behaviour #13511

Closed
davido912 opened this issue Jan 6, 2021 · 4 comments
Closed

Default Airflow 2.0 RBAC unexpected behaviour #13511

davido912 opened this issue Jan 6, 2021 · 4 comments
Labels
affected_version:2.0 Issues Reported for 2.0 kind:bug This is a clearly a bug priority:medium Bug that should be fixed before next release but would not block a release
Milestone

Comments

@davido912
Copy link
Contributor

davido912 commented Jan 6, 2021

After having transitioned to Airflow 2.0 from previous versions where RBAC functioned fine, facing a new behaviour which I don't know if is expected.

When creating a new role instead of using VIEWER permissions as base, Airflow enforces same permissions as role USER, this results in not being able to set granular access control for specific DAGs. I did notice that the behaviour is tied closely with update_fab_perms and whether it's on true or false.

Additional attempts were done editing the VIEWER role to grant it access to dag_edit on specific DAGs but it doesn't work as well. Any other permission is too permissive and grants full access to running DAGs to the role. Could not find anything in the documentation that would mean something is done wrong.

How to reproduce:
simply run the official helm chart on the repository, try creating a new role and after some time it will sync creating all the permissions similar to USER. Or, just try granting granular dag_edit permissions on a specific DAG and note that permission is still denied.

Moreover, not quite sure if this is an intended behaviour to enforce that all new roles have a similar set of permissions as USER (or closely similar) but I think the approach of least amount of access should be applied for new roles. Note, in previous versions of Airflow this behaviour didn't happen and for some reason on the latest one it does.

@davido912 davido912 added the kind:bug This is a clearly a bug label Jan 6, 2021
@davido912
Copy link
Contributor Author

@kaxil

@eladkal eladkal added the affected_version:2.0 Issues Reported for 2.0 label Jan 7, 2021
@kaxil
Copy link
Member

kaxil commented Jan 22, 2021

cc @jhtimmins -- Can you take a look at this please when you have time.

@kaxil kaxil added this to the Airflow 2.0.1 milestone Jan 22, 2021
@kaxil kaxil added the priority:medium Bug that should be fixed before next release but would not block a release label Jan 22, 2021
@jhtimmins
Copy link
Contributor

Yeah this should also be fixed by #13856, however the new behavior won't add any additional permissions to new roles except the ability to view the home page. Rather than replicating permissions from existing roles, you can assign multiple roles to a user.

@davido912
Copy link
Contributor Author

Closing this as the part where a role would be populated with USER permissions is fixed according to the above commit. However, one issue still persists and I opened a new issue for it.
#13891

kaxil pushed a commit that referenced this issue Jan 29, 2021
kaxil pushed a commit that referenced this issue Feb 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affected_version:2.0 Issues Reported for 2.0 kind:bug This is a clearly a bug priority:medium Bug that should be fixed before next release but would not block a release
Projects
None yet
Development

No branches or pull requests

4 participants