This patch addresses a specific use case, where a user has encrypted
volumes based on the fixed_key used by Cinder's and Nova's
ConfKeyManager. The user wishes to switch to Barbican, but existing
volumes must continue to function during the migration period.
The code conditionally adds a shim around the backend KeyManager when
both of these conditions are met:
1) The configuration contains a fixed_key value. This essentially
signals the ConfKeyManager has been in use at one time
2) The current backend is *not* the ConfKeyManager
When the shim is active, a MigrationKeyManager class is dynamically
created that extends the backend's KeyManager class. The
MigrationKeyManager exists solely to override two functions:
o The KeyManager.get() function detects requests for the secret
associated with the fixed_key, which is identified by an all-zeros
key ID.
- Requests for the all-zeros key ID are handled by mimicing the
ConfKeyManager's response, which is a secret derived from the
fixed_key.
- Requests for any other key ID are passed on to the real backend.
o The KeyManager.delete() function is similar:
- Requests to delete the all-zeros key ID are essentially ignored,
just as is done by the ConfKeyManager.
- Requests to delete any other key ID are passed on to the real
backend.
All other KeyManager functions are not overridden, and will therefore be
handled directly by the real backend.
SecurityImpact
Change-Id: Ia5316490201c33e23a4206838d5a4fb3dd00f527
* Uses https://www.vaultproject.io/ to store/fetch secrets
* All we need is the URL and a Token to talk to the vault server
* tox target "functional-vault" sets up a server in development mode
and runs functional tests
* Supports both http:// and https:// url(s)
* the https support was tested by setting up a vault server by hand
(https://gist.github.com/dims/47674cf2c3b0a953df69246c2ea1ff78)
* create_key_pair is the only API that is not implemented
Change-Id: I6436e5841c8e77a7262b4d5aa39201b40a985255
Since all Oslo library drivers are discoverable via
stevedore, we should use stevedore in Castellan as well.
This will make it easier for folks to write their own
custom drivers. Stevedore uses setuptools entry points
for implementing the common patterns for dynamically
loading extensions.
We add [key_manager]/backend as the new option to set
the custom driver. For a while, we should support the
older values that used to be specified using
[key_manager]/apiclass.
Change-Id: I2610459839806a5591da1efa314dfa52bcfb7cda
Allows a user to be able to set logging defaults if they have not
created a configuration for logging.
Change-Id: I7e7ce2f7904aefa30db63264d9e0702f0db57513
Co-Authored-By: Michael McCune <msm@redhat.com>
Closes-Bug: #1521265
This change adds a module for listing configuration options and setting
their defaults. It also changes the key manager base class to
incorporate a configuration during creation. By default, the key manager
will continue to use the global CONF object from the oslo.config
package.
For the most part, this change will be backwards compatible. The one
exception is the creation of sample configuration files. Previously,
importing castellan was sufficient to add these options to the global
configuration object. Now, these options will need to be applied by
using the castellan.options.list_opts function, or adding them through
other means, to create sample configuration files. Similar applies for
setting configuration before instantiating a key manager.
changes
* adding castellan.options with list_opts and set_defaults functions
* changing KeyManager abc to include a configuration option to __init__
* changing barbican and not_implemented key managers to accept
configuration parameters
* adding tests for set_defaults function
* fixing barbican tests to accomodate new configuration parameter
* adding documentation about configuration usage
* adding castellan configs to oslo entry point in setup.cfg
* adding a genconfig target to tox for producing a sample castellan
configuration file
* adding the sample configuration file to the git ignore
* renaming barbican option api_version to barbican_api_version
Change-Id: I86d6d7d49a893beaae6f311060ec593e0482d889
Implements: blueprint improved-configuration-options
Adds the first usable key manager plugin to Castellan. While there is an
implementation of a mock key manager in the test directories, it is used
only for testing.
This code is based on the barbican key manager code in Nova written by
Brianna Poulos. See: https://review.openstack.org/#/c/104001/
The Barbican API version info will be read from a config option until
the Barbican Version API is fixed. See fix-version-api blueprint.
Implements: blueprint add-barbican-key-manager
Co-authored-by: Brianna Poulos <brianna.poulos@jhuapl.edu>
Change-Id: Ia27cd831f42c6b027778240b3396b1c4149dc689
Castellan was using both key_mgr and keymgr for module names, leading to
inconsistent namespaces such as:
castellan.keymgr.key_mgr.KeyManager
This CR renames both instances to key_manager to be consistent with the
program name.
Change-Id: Ie07a70c14939b6c797e812c441d29218c2940ade
Zuul