Open Stack

On Tue, 2023-05-23 at 14:15 +0000, Jeremy Stanley wrote:
> On 2023-05-23 13:31:29 +0100 (+0100), Sean Mooney wrote:
> > On Tue, 2023-05-23 at 13:19 +0100, wodel youchi wrote:
> > > Does Openstack have the notion of tenant admin?
> > 
> > no it does not.
> > 
> > there is global admin or you can use member.
> > 
> > > If not, can a role be created to simulate such notion?
> > 
> > not really
> > 
> > you could use custom policy to simulate it but the real qustion
> > you have to ask/answer is what woudl a teant admin be able to do
> > that a project member cant.
> [...]
> 
> Developers have been working recently on adding a read-only "reader"
> role to their respective services as an initial phase of the
> Consistent and Secure Default RBAC goal[*], so you might think of it
> as people who need to be able to make changes to project resources
> (project members) are conceptually akin to your tenant admin idea
> while people who only need to be able to look at status and settings
> for project resources (project readers) are limited to just those
> capabilities and cannot make changes.
> 
> In phase 3, the plan (as it stands now) is to add a project
> "manager" role which will gain exclusive control of lower level
> resource API methods, further limiting the current project member
> role.
not nessisarly. limiting the scope of project member was not the intent of adding project manager.
the orginal intent was to allow proejct-manger to do more pivladge oepration that would normally requrie admin.

At least for nova i dont think we plan to remove any permissions form user with project
member today. we were considering allow project manager to have addtional capablity however.

a project member can lock an instance but an admin can overriede that.
a project member cannot unlock an instance that an admin has locked.

we could add the ablity for proejct managers to unlock an instance that a project member has locked
or to lock the instance such that a project member cannot unlock it.

an admin would still be able to override a project manager as it can with project memeber today.


i would consier the removal of permisisons to do thing form proejct member and requireign project manager
to be a breaking api change. there might be specific cases where we may decided its justifed
but unless we are plannign to do a new major version fo the nova api im expectign project manager
to be a purly additive cahnge.

adding new capablitys that woudl previously have been admin only be default.
for exampel the ablity to cold migrate a vm or live migrate it perhaps.

but i do not expect use to restict what project member can do.

live migration is the example usecase although there have been other discussed in the past
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#implement-support-for-project-manager-personas

any changes in this regard will likely require per project specs to detail exactly what will and will not change.

for example keystone might desire to allow project managers to delegate any of the roles they have to other users in a project
or give a project manager the ability to add or remove a user form the project.

if that was a change that was desirable i woudl expect to see a keystone spec that would detail exactly how that
will be done.

similarly i expect any usage of project manager in nova  to be accompanied by a spec to describe that.
while we have examples we do not have any detailed proposals for nova at this time.



> 
> [*] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
>