Migration and evacuation fails with encrypted volumes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Confirmed
|
Medium
|
Lee Yarwood |
Bug Description
# Description
Migration and evacuation fails with encrypted volumes, when the user is in a different project to the instance creator, even if they are admin. This is a common use case, since operators typically need to migrate around instances. It also occurs with masakari during failover events.
# Steps to reproduce
As user 1 in project X:
* Enable volume encryption via barbican (https:/
* Create an instance with an encrypted volume
As admin user in admin project:
* Migrate or evacuate instance created by user 1
# Expected results
Instance is migrated successfully.
# Actual results
Instance fails to migrate.
# Environment
CentOS 8
Kolla CentOS source containers
Train release
# Logs
We see the following in barbican API logs:
Secret retrieval attempt not allowed - please review your user/project privileges: oslo_policy.
This is because barbican secrets, in this case the volume encryption key, are scoped to a project.
# Workaround
I added the following policy.json:
{
"secret:get": "rule:secret_
"secret:
}
Then assigned the migrating user the key-manager:
tags: | added: barbican encryption volumes |
Just to be clear you're referring to live migration and not cold migration here right? AFAIK cold migration by an admin of an instance with encrypted volumes attached should work.
I don't think we can support any live move operations by admins of instances with encrypted volumes attached given the default policy within Barbican. As you've pointed out this blocks access to the secrets by anyone but the owner by default.
As for evacuation, this came up recently downstream and I think we should introduce support for cold evacuations of instances from down compute nodes in W. This would allow admins to move instances with attached encrypted volumes while leaving it up to the end users to restart them later.