[all][ops][rbac] RBAC discussion summary from Vancouver summit

Ghanshyam Mann gmann at ghanshyammann.com
Wed Jun 21 18:11:56 UTC 2023


Hello Everyone,

Most of you know we had the RBAC discussion at the Vancouver summit on Tuesday.
- https://etherpad.opendev.org/p/rbac-operator-feedback-vancouver2023

This forum session started providing the current progress for RBAC work which you can
find in Etherpad
- https://etherpad.opendev.org/p/rbac-operator-feedback-vancouver2023#L46

After the progress updates, we started the feedback from operators. I am writing the summary
and feel free to add anything I missed to capture here:

Admin Access:
===========
* Keep current Admin (legacy admin means admin in any project) untouched.
* There is a need for second-level support along with the current admin, and this can be done with the project manager
* Public Cloud use case:
----------------------------
** Currently defined RBAC goal does not solve the public cloud use case of having a domain admin manage the specific
domain's user/project/role.
** If the domain admin can assign an admin role to any user under their domain, then that user gets admin
access across all the projects on the service side (even projects are in different domains as the service side does not have
domain boundaries)
** We do not have any better solution for now, but one idea is to have the Domain manager allow managing the user/project/
role in their domain except 'Admin' role assignment. Current legacy admin (admin across all domains) can handle the 'Admin'
role assignment. I mean, domain manager behaves as domain-level admin and legacy admin as a global admin.
Feel free to write other solutions if you have?

Member Access:
============
* Project Member is a good fix and useful to enforce 'member' roles actually 

Reader Access:
============
* Project Reader is one of the most useful roles in this change.

* There is an ask for a global reader, which was nothing but a system reader in past. This can
be useful for performing the audit of the complete cloud.  One idea is to do this with a special role
_role in Keystone. I will write the spec for it, and we can talk about it there.


-gmann

 




More information about the openstack-discuss mailing list