Draft: Roles Standard

[markus-hentsch]

Adds a standard to define all RBAC roles and permissions in the SCS IaaS layer.

Resolves SovereignCloudStack/issues#396

Supersedes #378

[berendt]

Does it makes sense not to only link the domain-manager role standard but also to list the domain-manager role inside this standard?

[markus-hentsch]

Does it makes sense not to only link the domain-manager role standard but also to list the domain-manager role inside this standard?

It is listed as "manager" under the core roles. It isn't called domain-manager anymore, see https://docs.scs.community/standards/scs-0302-v1-domain-manager-role/#change-the-naming-of-the-domain-manager-role-to-align-with-upstream

[markus-hentsch]

FTR, I considered replacing the "creator" role by "member" entirely. However, I decided against it for the following reasons:

• both DevStack and RedHat setups¹ seem to assign the "creator" role to a "cinder" user in the "service" project, which is registered in Cinder's [keystone_authtoken] config section
• mandating to switch Cinder's service user to "member" role here could open up permissions in other services' APIs potentially which otherwise wouldn't react to the "creator" role (which is Barbican-specific)
  • without enforce_scope (which this standard cannot use), the scoping would not protect us here

However, I'm not exactly sure in which workflow Cinder needs its own Barbican-enabled role, i.e. what the reasoning for this is. Usually, the user's auth token is passed around during requests so it would simply take the role permissions from there. However, it is most likely there for a reason, so I'm leaving it in because I don't know the context and don't want to break things.

Footnotes

1. https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/manage_secrets_with_openstack_key_manager/encrypting_cinder_volumes#overview_of_the_migration_steps ↩

[josephineSei]

I guess Cinder will need it in case of a deletion of an encrypted volume (to delete the key) or to create a backup or snapshot (to copy the key). Maybe there is an edge case, where e.g. a backup is not triggered by someone from the project (hence no chance to aquire the key) or a deletion of a key is done so late, that the user conetxt is already omitted, so cinder does not have the token of the user anymore.

[markus-hentsch]

Does it makes sense not to only link the domain-manager role standard but also to list the domain-manager role inside this standard?

It is listed as "manager" under the core roles. It isn't called domain-manager anymore, see https://docs.scs.community/standards/scs-0302-v1-domain-manager-role/#change-the-naming-of-the-domain-manager-role-to-align-with-upstream

FTR, I have now moved the role from core roles to service-specific roles after some more research. For the rationale see the new 'Classification of the "manager" role' section under the Design Considerations.

[josephineSei]

Overall this is a very unfortunate time to write a role standard.

So maybe we should discuss this in a bigger group, if we somehow can make it easier for you. (E.g. kick heat from the supported list?)

[josephineSei]

I guess Cinder will need it in case of a deletion of an encrypted volume (to delete the key) or to create a backup or snapshot (to copy the key). Maybe there is an edge case, where e.g. a backup is not triggered by someone from the project (hence no chance to aquire the key) or a deletion of a key is done so late, that the user conetxt is already omitted, so cinder does not have the token of the user anymore.

[josephineSei]

I think this is going into a good direction.

[josephineSei]

Maybe this is more kind of an implementation note?
Because policy adjustments might occur more often than a change of the role model itself.

And the policy I am thinking about is the network rbac - which might be changed in the external network standard to only allow admin role to use it: #572

[markus-hentsch]

This is the last part I need to figure out for the standard: what to put here.

We will definitely need to make sure that CSPs apply the special policy templates offered by Octavia¹ so that the LBaaS API will be aligned with the reader, member, admin model.

Other than that, we're pretty much in line with the in-code defaults now that we can use Secure RBAC. I need to double check but I think there won't be much more needed to be added here in terms of strict guidelines.

Footnotes

1. https://docs.openstack.org/octavia/2024.1/configuration/policy.html#openstack-default-roles-policy-override-file ↩

[markus-hentsch]

I added Octavia there now plus some general do's and dont's. It's pretty brief and I don't think it justifies an implementation note split currently.

And the policy I am thinking about is the network rbac - which might be changed in the external network standard to only allow admin role to use it: #572

@josephineSei I'm wondering whether this should be part of the corresponding network standard or this role standard. I think it's more a detail of how the networking stuff works and is to be used, not a general role model or scoping thing. So I'm leaning more towards addressing this in the network standards if there is a network standard that would fit.

[markus-hentsch]

Needs to be replaced by a genuine link once #587 is merged.

[markus-hentsch]

FTR, I removed the part about the role adjustment for Barbican and linked the corresponding implementation notes of the Key Manager standard in the related documents section instead, since this is part of that standard now.

[markus-hentsch]

FTR, I think this PR will need to stay in draft state as long as upstream has remaining incompatibilities with enforce_new_defaults in any of the SCS-mandatory/supported services (esp. Cinder and Barbican), see SovereignCloudStack/issues#396 (comment)

This standard must be able to rely fully on the newer SRBAC model (reader, member, admin) without any service-specific exceptions, in my opinion.