Hi,


Dnia środa, 21 czerwca 2023 20:11:56 CEST Ghanshyam Mann pisze:

> 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.


Will this impact existing phases in https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html somehow or will this global reader role be considered as next "phase" after project-manager (phase 3) will be done?


>

>

> -gmann

>

>

>

>



--

Slawek Kaplonski

Principal Software Engineer

Red Hat