[all][ops][rbac] RBAC discussion summary from Vancouver summit
Slawek Kaplonski
skaplons at redhat.com
Thu Jun 22 11:02:23 UTC 2023
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230622/77c998a7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230622/77c998a7/attachment-0001.sig>
More information about the openstack-discuss
mailing list