Barbican key manager fails for encrypted volume created through Heat

[Johannes Grassler]

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.identity.v3.Token object[0]. This Token object is then used
to create a keystoneclient.session.Session object[1] which will attempt to
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.keymgr.barbican does not exist in master. I haven't taken a close
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-type-create encrypted nova.volume.encryptors.luks.LuksEncryptor

3) Save the following Heat template to volume.yaml and instantiate it
   using `heat stack-create -f volume.yaml`:

    heat_template_version: 2015-10-15

    resources:

      myvolume:
        type: OS::Cinder::Volume
        properties:
          name: myencryptedvolume
          size: 1
          volume_type: encrypted

This will result in the attached stack trace.

References:

[0] https://github.com/openstack/cinder/blob/stable/mitaka/cinder/keymgr/barbican.py#L104
[1] https://github.com/openstack/cinder/blob/stable/mitaka/cinder/keymgr/barbican.py#L108

[Johannes Grassler (jgr-launchpad)]

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.

[Kaitlin Farr (kaitlin-farr)]

It looks like this will affect Castellan as well [1] (Cinder stable/newton and master). The preliminary patch won't apply directly to Castellan, but the general concept of using the service catalog should be applicable. Will need to look more closely at the difference between using v2 or v3 -- the buggy code used v3 tokens, but it looks like the preliminary patch uses v2 objects?

1. https://github.com/openstack/castellan/blob/master/castellan/key_manager/barbican_key_manager.py#L164-L167

[Johannes Grassler (jgr-launchpad)]

Frankly I didn't take too close a look at the code I added to cinder.context. I just needed something that gave me the current user's authenticated session and nicked the _ContextAuthPlugin(plugin.BaseAuthPlugin) class from nova.context, found it did what I needed it to do and used it. But from a closer look at keystoneauth1.access.service_catalog I suspect ServiceCatalogV3 wouldn't work due to incompatible token formats:

https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/access/service_catalog.py#L240
https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/access/service_catalog.py#L279

For some reason we appear to be getting a V2 token from the current user's session, otherwise ServiceCatalogV2 would not work.