live-migrating of instances with crypted volume not possible

[maliblatt]

When trying to live-migrate an instance with crypted volume or when trying to empty a hypervisor with the migrate-host feature, it will fail with an error like this:

ERROR nova.compute.manager [instance: xxxx] oslo_messaging.rpc.client.RemoteError: Remote error: KeyManagerError Key manager error: Forbidden: Secret retrieval attempt not allowed - please review your user/project privileges

ERROR barbican.api.controllers [req-eb5f1867-630c-45a0-becb-478739609341 0b16e2645828414d86f094c2a7a693eb 66fcb198228e4d9d97f09dc7ce1d5130 - default default] Secret retrieval attempt not allowed - please review your user/project privileges: oslo_policy.policy.PolicyNotAuthorized: secret:get is disallowed by policy

INFO barbican.api.middleware.context [req-eb5f1867-630c-45a0-becb-478739609341 0b16e2645828414d86f094c2a7a693eb 
66fcb198228e4d9d97f09dc7ce1d5130 - default default] Processed request: 403 Forbidden - GET https://api-int.gx-scs.sovereignit.cloud:9311/v1/secrets/bd2ad84b-2232-4e92-a6bd-8b418451dddd

As a workaround, we have modified the barbican policy to allow admin to retrieve the secrets for migrating instances from other projects, so that live-migrating is now working for us. May be this should be integrated in OSISM?

$ cat environments/kolla/files/overlays/barbican/policy.yaml 
# metadata/: Lists a secrets user-defined metadata. || metadata/{key}:
# Retrieves a secrets user-added metadata.
# GET  /v1/secrets/{secret-id}/metadata
# GET  /v1/secrets/{secret-id}/metadata/{meta-key}
# Intended scope(s): project
"secret_meta:get": "rule:secret_non_private_read or rule:secret_project_creator or rule:secret_project_admin or rule:secret_acl_read or (role:member and project_id:%(target.secret.project_id)s and (user_id:%(target.secret.creator_id)s or True:%(target.secret.read_project_access)s)) or role:admin and project_id:%(target.secret.project_id)s or rule:operations_team"

# Retrieve a secrets payload.
# GET  /v1/secrets/{uuid}/payload
# Intended scope(s): project
"secret:decrypt": "rule:secret_decrypt_non_private_read or rule:secret_project_creator or rule:secret_project_admin or rule:secret_acl_read or (role:member and project_id:%(target.secret.project_id)s and (user_id:%(target.secret.creator_id)s or True:%(target.secret.read_project_access)s)) or role:admin and project_id:%(target.secret.project_id)s or rule:operations_team"

# Retrieves a secrets metadata.
# GET"  /v1/secrets/{secret-id}
# Intended scope(s): project
"secret:get": "rule:secret_non_private_read or rule:secret_project_creator or rule:secret_project_admin or rule:secret_acl_read or (role:member and project_id:%(target.secret.project_id)s and (user_id:%(target.secret.creator_id)s or True:%(target.secret.read_project_access)s)) or role:admin and project_id:%(target.secret.project_id)s or rule:operations_team"

# Lists a projects secrets.
# GET  /v1/secrets
# Intended scope(s): project
"secrets:get": "rule:all_but_audit or role:member or rule:operations_team"

# WARNING: Below rules are either deprecated rules
# or extra rules in policy file, it is strongly
# recommended to switch to new rules.
"operations_team": "role:admin"

[berendt]

@matfechner Are you looking at this as part of the Encryption topic? I think it makes sense as a 1st step in the testbed to activate the Barbican service. So far this is not yet the case.

[matfechner]

@berendt barbican is still active:

https://github.com/osism/testbed/blob/main/environments/kolla/configuration.yml ... enable_barbican: "yes" ...

[berendt]

• [ ] Document that live migrations with Barbican and encrypted volumes are not possible.
• [ ] Document how the policy can be adapted to enable a LIve migration (Potential security problem as the operator should not have access to the client's secret)

[berendt]

It's more of an enhancement than a bug. It is not possible by design.

[noonedeadpunk]

I totally agree here with @berendt that modifying policy in a way to allow admin read any secret of any user is totally a security issue and should not be considered as normal practise. Yes, that would ease operations, sure, but basically any user with specific role will be able to decrypt anything that was encrypted for $reason. So I'm not sure this path should be really documented except - you can do this at your own risk.