Xena Series Release Notes

3.9.0

New Features

  • Adds support for using a service user with the Barbican key manager. This is enabled via [barbican] send_service_user_token, with credentials for the service user configured via keystoneauth options in the [barbican_service_user] group.

3.8.0

New Features

  • The new [barbican] barbican_region_name option has been added. This parameter is used to determine the proper Barbican endpoint in the multi-region deployment which has a different Barbican endpoint in each region.

3.5.0

Bug Fixes

  • barbican_endpoint_type is now used to retrieve Barbican endpoint URL from service catalog. This config option is set to ‘public’ by default so it will not change the current behaviour.

3.4.0

New Features

  • Historically, the vault key manager backend converts its managed objects to dictionaries in order to send them as a json object. To promote cross-backend compatibility, suck feature should be migrated to managed objects. Methods from_dict() and to_dict() added to class ManagedObject. The Method from_dict() is a class method to create instances based on a dictionary while the method to_dict() is an instance method to translate an instance to a dictionary.

3.2.0

Bug Fixes

  • In some situations, vault will not provide KV API version in the options structure. Vault documentation [1] doesn’t cover cases when KV API version is not provided. A new configuration option, with default value equivalent to the latest KV API version available (kv_version=2) was added to allow precise configuration of the KV API being used.

    [1] https://learn.hashicorp.com/vault/secrets-management/sm-versioned-kv

3.1.0

Bug Fixes

  • Add a new parameter, verify_ssl_path, that can be used to configure the path to CA certs when verifying requests to Barbican.

3.0.0

New Features

  • Enhance the global option listing to discover available key managers and their options. The purpose of this feature is to have a correct listing of the supported key managers, now each key manager is responsible for advertising the oslo.config groups/options they consume.

Other Notes

  • The visibility of module variables and constants related to oslo.config options changed to private in both barbican and vault key managers. The key managers are only responsible for overloading the method list_options_for_discovery() in order to advertise their own options. This way, the global options doesn’t need to know which variables to look for.

2.0.0

Upgrade Notes

  • Python 2.7 support has been dropped. The minimum version of Python now supported by castellan is Python 3.6.

1.2.1

Bug Fixes

  • Fixed VaultKeyManager.create_key() to consider the length param as bits instead of bytes for the key length. This was causing a discrepancy between keys generated by the HashiCorp Vault backend and the OpenStack Barbican backend. Considering km as an instance of a key manager, the following code km.create_key(ctx, “AES”, 256) was generating a 256 bit AES key when Barbican is configured as the backend, but generating a 2048 bit AES key when Vault was configured as the backend.

1.2.0

New Features

  • Added configuration option to the Vault key manager to allow the KV store mountpoint in Vault to be specified; the existing default of ‘secret’ is maintained.

0.16.0

New Features

  • Enhance the key manager to handle requests containing the special (all zeros) managed object ID associated with Cinder’s and Nova’s legacy ConfKeyManager. The purpose of this feature is to help users migrate from the ConfKeyManager to a modern key manager such as Barbican. The feature works by ensuring the ConfKeyManager’s all-zeros key ID continues to function when Barbican or Vault is the key manager.

0.15.0

New Features

0.13.0

Deprecation Notes

  • Config option barbican/auth_endpoint is unnecessary and deprecated in favor of the more standard key_manager/auth_url.