Barbican key manager fails for encrypted volume created through Heat
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
New
|
Undecided
|
Unassigned |
Bug Description
Problem description
===================
Heat delegates a Keystone trust from a stack's creating user
to its service user. This Keystone trust is then used to
acquire a trust scoped token for authenticating against the
APIs Heat talks to, such as the Cinder API.
Cinder's Barbican key manager in turn uses this trust scoped token from
Cinder's authentication context to create a
keystoneclient.
to create a keystoneclient.
use the existing token to issue a new one.
This will fail if the token is trust scoped, as the token Heat uses to
access the Cinder API is. I attached a detailed stack trace (excerpt
from cinder-api.log to this bug.
Impact
======
As far as I can tell this problem only affects stable/mitaka as
cinder.
look at how Castellan based key management works, so it may in fact be
affected as well.
Steps to reproduce
==================
1) Create a volume type for encrypted volumes:
cinder type-create encrypted
2) Create an encryption type for this volume type:
cinder encryption-
3) Save the following Heat template to volume.yaml and instantiate it
using `heat stack-create -f volume.yaml`:
heat_
resources:
myvolume:
type: OS::Cinder::Volume
properties:
name: myencryptedvolume
size: 1
This will result in the attached stack trace.
References:
[0] https:/
[1] https:/
Since I don't know when I'll get around to polishing up the patch for a proper review, here's a preliminary version. It works, but it fails a bunch of flake tests and the unit tests do not account for the changes in cinder. keymgr. barbican tests, yet.