Add addendum to Castellan integration specification
The original Nova specification for integrating Castellan for key management has merged, but it was suggested that alternate implementations to the original one may be preferred. This addendum opens up other options for discussion. Original specification change id: I025995584e74c0b2df00841697714c10d1afb674 Change-Id: Ie9c686d9f1ee2e99d3c0b45f3b9b83e1f7ccb00b
This commit is contained in:
parent
504c10b2b6
commit
ebf04e087d
|
@ -54,9 +54,103 @@ agrees that it provides a valuable test fixture.
|
|||
Alternatives
|
||||
------------
|
||||
|
||||
The alternative is to leave the key manager interface as it is, but this means
|
||||
that Nova's key manager will not benefit from the updates, new features, and
|
||||
future additional back ends available in Castellan.
|
||||
Castellan was integrated into Nova, but ConfKeyManager still remains in the
|
||||
Nova source code. There are a few options for improving the integration.
|
||||
The goals in determining a path forward are the following:
|
||||
|
||||
* Keep Castellan a key manager interface for production-ready back ends
|
||||
* Deprecate class-based loading
|
||||
* Find a back end to serve as a test fixture for encryption features
|
||||
|
||||
However, class-based loading is a Castellan feature, and so the spec for
|
||||
deprecating class-based loading should live in the Castellan/Barbican specs.
|
||||
The followng are possible alternatives, which solve one or more of the goals:
|
||||
|
||||
* Remove and replace ConfKeyManager
|
||||
|
||||
One strategy for a path forward is to deprecate and remove ConfKeyManager
|
||||
and find an alternative back end suitable for testing. The ConfKeyManager
|
||||
back end reads a single, fixed key from a configuration file. It does not
|
||||
live in Castellan because ConfKeyManager is very insecure and is only
|
||||
suitable for testing. It is only useful for basic testing of encryption
|
||||
features using one key, such as Cinder volume encryption. If any
|
||||
administrators decided to use ConfKeyManager in their production
|
||||
deployment, they will be able to store the fixed key in the new back end as
|
||||
part of the migration necessary after deprecation. Other security features
|
||||
such as Glance image signing and verification use certificates and cannot
|
||||
be tested with ConfKeyManager. A back end closer to what is used in
|
||||
production would provide better testing. The following are options for
|
||||
replacing ConfKeyManager:
|
||||
|
||||
* Option 1: KMIP Castellan back end
|
||||
|
||||
The Key Manager Interoperability Protocol (KMIP) is a standardized
|
||||
protocol for interacting with a key manager. The PyKMIP library [6]
|
||||
includes not only client code necessary for interacting with a KMIP
|
||||
hardware device but also a KMIP software server with Keystone
|
||||
authentication that is useful for functional testing where a hardware
|
||||
device is not an option. Work on a KMIP Castellan back end has already
|
||||
started [7], but would need to be completed for this option. The PyKMIP
|
||||
software server is already used in the Barbican functional gate. New
|
||||
DevStack gate checks could be configured to use the PyKMIP server for the
|
||||
encryption Tempest tests, or the existing ones could be modified. This
|
||||
option satisfies all three of the goals listed above.
|
||||
|
||||
* Option 2: Barbican Castellan back end
|
||||
|
||||
A Barbican back end already exists for Castellan. This option entails
|
||||
editing DevStack gate jobs and/or DevStack itself to configure and launch
|
||||
Barbican. This option is beneficial because it would test encryption
|
||||
features as they should be used in production, as Barbican is the
|
||||
recommended back end. However, just 2% of production deployments use
|
||||
Barbican [4] so it may not make sense to include it in all of the gates.
|
||||
This option would satisfy all three of the goals listed above.
|
||||
|
||||
* Option 3: New database back end
|
||||
|
||||
This option is to create a new Castellan test fixture back end that can
|
||||
store multiple objects in a database. While this option will not provide
|
||||
a deployment-ready back end, it will be better than ConfKeyManager and
|
||||
will be able to support functional testing of features such as signed
|
||||
image verification that need to retrieve certificates. This is an
|
||||
improvement from using ConfKeyManager because this will allow the key
|
||||
manager testing code to be closer to what a deployment configuration
|
||||
would look like. However, this back end does not exist yet, and would
|
||||
require work to implement the database interactions. Option 1 or Option 2
|
||||
would require less Castellan development work. Once completed, this
|
||||
option would satisfy two of the three goals.
|
||||
|
||||
* Move ConfKeyManager elsewhere
|
||||
|
||||
The community has expressed concern about ConfKeyManager living in the
|
||||
Nova code base, but moving ConfKeyManager into Castellan is not preferred.
|
||||
The following are options for if ConfKeyManager cannot be deprecated:
|
||||
|
||||
* Option 4: Move ConfKeyManager to Tempest
|
||||
|
||||
The Tempest tests are the only place where ConfKeyManager should be used,
|
||||
so the back end could be moved to Tempest. As long as Castellan provides
|
||||
an option to register back ends if class-based loading is deprecated,
|
||||
this option could satisfy all three of the goals above.
|
||||
|
||||
* Option 5: Move ConfKeyManager to Castellan
|
||||
|
||||
This is not a recommended option. The ConfKeyManager does not support
|
||||
testing of features such as signed image verification [8], which uses
|
||||
certificates, not keys. Moving ConfKeyManager to Castellan will push
|
||||
the problem of not having an adequate testing back end down the road.
|
||||
|
||||
* Revert the Castellan integration patch
|
||||
|
||||
* Option 6: Revert to nova/keymgr
|
||||
|
||||
This is not a recommended option. The key manager interface will be left
|
||||
as it is in nova/keymgr, but this means that Nova's key manager will not
|
||||
benefit from the updates, new features, and future additional back ends
|
||||
available in Castellan. The key manager interface will not be unified
|
||||
across Nova, as the volume encryption feature and encrypted ephemeral
|
||||
storage feature will use nova/keymgr, but the image signature
|
||||
verification feature already uses Castellan.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
@ -156,22 +250,34 @@ Documentation Impact
|
|||
====================
|
||||
|
||||
These changes will be documented. Nova documentation for disk encryption will
|
||||
be updated to reference Castellan [4].
|
||||
be updated to reference Castellan [5].
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] Castellan source code:
|
||||
[1] Castellan source code
|
||||
https://github.com/openstack/castellan
|
||||
|
||||
[2] Castellan in OpenStack's global requirements:
|
||||
[2] Castellan in OpenStack's global requirements
|
||||
https://github.com/openstack/requirements/blob/master/global-requirements.txt
|
||||
|
||||
[3] Current Nova key manager implementation
|
||||
https://github.com/openstack/nova/tree/master/nova/keymgr
|
||||
|
||||
[4] Disk encryption configuration reference
|
||||
http://docs.openstack.org/liberty/config-reference/content/section_volume-encryption.html
|
||||
[4] April 2016 OpenStack User Survey
|
||||
http://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf
|
||||
|
||||
[5] Disk encryption configuration reference
|
||||
http://docs.openstack.org/liberty/config-reference/content/section_volume-encryption.html
|
||||
|
||||
[6] PyKMIP source code
|
||||
https://github.com/openkmip/pykmip
|
||||
|
||||
[7] KMIP backend for Castellan
|
||||
https://review.openstack.org/#/c/298991/
|
||||
|
||||
[8] Glance image signing and verification specification
|
||||
https://specs.openstack.org/openstack/glance-specs/specs/liberty/image-signing-and-verification-support.html
|
||||
|
||||
History
|
||||
=======
|
||||
|
@ -183,3 +289,5 @@ History
|
|||
- Description
|
||||
* - Mitaka
|
||||
- Introduced
|
||||
* - Newton
|
||||
- Amended
|
||||
|
|
Loading…
Reference in New Issue