SovereignCloudStack
Key-Manager Standard
If we decide to move Barbican from Supported to Mandatory in the lists of mandatory and supported openstack services, we may not need an extra test script here, but should move it into the other test-file.
@gtema could you please review this standard again and check, whether all your points were addressed?
Testing whether a user with the member role is allowed to interact with Barbican (That is, that either new SRBAC is used or the policy is changed to integrate the member role) is quite difficult: In old deployments, or deployments where all services are using the old RBAC policies it is possible to reconnect only with the member role and check if the user is allowed to list secrets. In nowadays and future deployments, this will not work anymore. OpenStack does not offer any API to see what roles a user itself has, nor does it allow to only interact as having one specific role.
So we need to put the burden of a correct configuration into the CSPs hand: We need a user who only has the member role in the project, that is specified when executing the test.
If a CSP also gives out a reader role or a creator role, this will lead to a false positive: The test will succeed, but the standard may not be fulfilled.
We should document this behavior. But when the user-role-project triple is configured correctly, we can test the policy.
Testing whether a user with the member role is allowed to interact with Barbican (That is, that either new SRBAC is used or the policy is changed to integrate the member role) is quite difficult: In old deployments, or deployments where all services are using the old RBAC policies it is possible to reconnect only with the member role and check if the user is allowed to list secrets. In nowadays and future deployments, this will not work anymore. OpenStack does not offer any API to see what roles a user itself has, nor does it allow to only interact as having one specific role. [...]
can't we simply test this by e.g. calling a known admin only api endpoint and expecting it to fail? this isn't sufficient of course (this API could be disabled even for admins via a special crafted policy I guess). But for "normal" deployments, we should receive a HTTP 403 forbidden error code.
It's not bulletproof, but maybe better than nothing?
Testing whether a user with the member role is allowed to interact with Barbican (That is, that either new SRBAC is used or the policy is changed to integrate the member role) is quite difficult: In old deployments, or deployments where all services are using the old RBAC policies it is possible to reconnect only with the member role and check if the user is allowed to list secrets. In nowadays and future deployments, this will not work anymore. OpenStack does not offer any API to see what roles a user itself has, nor does it allow to only interact as having one specific role.
??? I do not get it. When you authorize you get back a token response. It contains all roles user have in the current scope (and for that you do not need to do any other call). In addition to that there is https://docs.openstack.org/api-ref/identity/v3/index.html#id627 but that requires you to have privileges for that (admin)
In the sdk documentation I found this:
validate_user_has_project_role(project, user, role)
Validates that a user has a role on a project
Parameters:
project – Either the ID of a project or a [Project](https://docs.openstack.org/openstacksdk/latest/user/resources/identity/v3/project.html#openstack.identity.v3.project.Project) instance.
user – Either the ID of a user or a [User](https://docs.openstack.org/openstacksdk/latest/user/resources/identity/v3/user.html#openstack.identity.v3.user.User) instance.
role – Either the ID of a role or a [Role](https://docs.openstack.org/openstacksdk/latest/user/resources/identity/v3/role.html#openstack.identity.v3.role.Role) instance.
Which would be really nice to use. But I need a role id (which does not seem to work - I have the member role but get a "False" from this method, when providing the id of the member role). Even if it would work, as a simple user without the admin role I am not able to list roles and their ids.
Additionally in the OpenStackSDK, the connection has the properties: current_project_id and current_user_id - but nothing about the roles, that are inherited.
Additionally in the OpenStackSDK, the connection has the properties:
current_project_idandcurrent_user_id- but nothing about the roles, that are inherited.
The token contains list of all roles (inherited roles are resolved and thus explicitly included). But there is a bug in Keystone (https://bugs.launchpad.net/keystone/+bug/2030061) for which fix was finally decided and merged on Friday where application credentials created with/without explicit specifying the AppCred roles are having this resolving not working properly (AppCreds created with i.e. requesting "member" role were not getting "reader" role included). This is not relevant here directly, but may be important to know when you use AppCreds for checks.
I looked of the standard today and adjusted some spelling mistakes left. @gtema and @artificial-intelligence could you please check if there are still open points from your side? Thank you
I asked today in the IaaS call for reviews from CSPs - because they are encouraged to integrate a key-manager sooner or later. I will leave this PR open until the end of this week, so feedback can still be written here.