Open Stack

 ---- On Thu, 22 Jun 2023 04:02:23 -0700  Slawek Kaplonski  wrote --- 
 > 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?

I will say not to add this in phase-1. This can be good to do before the service/manager role, but we can discuss this
in the meeting (or next cycle PTG). For this cycle no change in plan; let's complete phase-1 (project personas) for every project. One thing
to note is that this new global reader will not add any backward incompatibility in the current ([phase-1) defaults because
it will be an additional role in logical OR to the existing defaults (so deprecation of current defaults).

-gmann

 > 
 > > 
 > > 
 > > -gmann
 > > 
 > >  
 > > 
 > > 
 > > 
 > 
 > 
 > -- 
 > Slawek Kaplonski
 > Principal Software Engineer
 > Red Hat
 >