[all][ops][rbac] RBAC discussion summary from Vancouver summit
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
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.
This forum session started providing the current progress for RBAC work which you can find in Etherpad
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-rba... somehow or will this global reader role be considered as next "phase" after project-manager (phase 3) will be done?
-gmann
---- 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.
This forum session started providing the current progress for RBAC work which you can find in Etherpad
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-rba... 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
participants (2)
-
Ghanshyam Mann
-
Slawek Kaplonski