-
Notifications
You must be signed in to change notification settings - Fork 50
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
RBAC system with custom roles integrated with AWX #45
Conversation
4f3c75f
to
1c550f0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. I'd like to merge the resource registry and then update this to integrate with the resource registry system. I think once we do that, I'm happy to merge this PR.
4909e55
to
752e0c6
Compare
e94da3c
to
ba61e3b
Compare
74ad61a
to
858d130
Compare
3140eb5
to
8d36bee
Compare
5cf23f3
to
90381bb
Compare
3291b92
to
a71608f
Compare
743621b
to
2dd921c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've not combed over every file but wanted to get a start ont he comments. One general question is the layout of the files inside rbac. FIrst there is an api directory but there are some things not in there like caching and evaluations. The other thing is we have many classes in single views/serializers/modles files. I much prefer a directory with seperate files if possible. But those are kind of personal preferences.
If you want to stick with this layout for this PR I am ok with that but maybe we want to have a "standard" layout for apps in DAB in general?
I'm going to go ahead and approve this, though I do think we need to have more conversations around the permissions model. |
I wanted to do that before today, but workload from other rebasing and other fixes kept me from it. Described in #222 |
@john-westcott-iv AlanCoding#4 is ready, in that it is passing tests
I think it's a pretty clear practice that |
Key features are - support of resource tree permission inheritance - support for grouping users into teams - efficient generation of querysets - endpoints for RBAC models, permission classes Added feature for tracking roles with relationships Added feature to manage singleton permissions Add util for assigning permissions in migrations add util for creating permissions in custom model Use null content_type to identify system roles From review Use shared method for add permission determination Make the RBAC_checks command more pretty give non-zero exit code if issues are identified Use " instead of ' for block strings Add model to test parent names not matching model
Fix bug with stale org-obj evaluations from review Be more consistent with ContentType usage Fix test failure from rebase due to postgres and flake8
Avoid database .get for unsaved objects in pre_save discovered via eda-server testing
Fix RBAC_checks management command when the thing it is doing is disabled by settings addition: Add another setting for disabling custom system role creation
Add plus integration docs for this new feature Add tests for using unauthenticated client with some views
Assure that user viewset has minimal functionailty with generic permission class
* Initial add of permission model * Add an early exit for permission creation method
Adopt new created and modified fields in CommonModel after rebase - supporting changes
417b825
to
9516031
Compare
Quality Gate passedIssues Measures |
This rewrites the roles system inside of AWX and moves them here, to this library, so that ideally we can connect it to other apps. I want to be very clear that this is mainly an object-role system. I added functionality to handle system-wide permissions, but this is a different sub-system.
AWX patch to use this - ansible/awx#14735
The only reason this is possible at all is because most of the AWX gnarly permission logic exists on a layer of business logic fairly well-separated from the internals of the RBAC system. It's mainly the internals that this offers (although it tacked on a simple API), for object-roles - roles to things. Those things can be in a shallow hierarchy... which is just organizations right now. Inheritance of permissions from more than 1 parent resource has some basic tests, but isn't expected to be used yet.
Right now this is fully functional in AWX, with only 2-3 known integration test failures due to sacrifices that were knowingly made.
TODO:
content_type
toRoleDefinition
. This will be used for validation of permissions, because listing some permissions require listing other permissions, and most permissions are only valid for a certain model (or a parent of that model).members
relationship that already exists in Gateway compatible with this. The role system, today, handles this by putting users in a pre-created team member role. If the role is the source of truth, then we need to add some ORM shortcuts to more easily access it.Very large item - migrate galaxy_ng to this system like the AWX migration. This would have to go along with the introduction of an organization model, without organizations this entire system is useless. Ping @cutwaterAdd to the AWX migration - split the organization admin role into 2 with 1 dealing with orgs / teams / user management, and the other dealing with AWX objects alone. This role will then be migrated into Gateway itself (not ansible_base). Oh yeah, and also convert Gateway to this system... I don't think it has a permissions system right now.Not doing this