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