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, withcredentials 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 inthe multi-region deployment which has a different Barbican endpoint ineach region.

3.5.0

Bug Fixes

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

3.4.0

New Features

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

3.2.0

Bug Fixes

  • In some situations, vault will not provide KV API version in the optionsstructure. Vault documentation [1] doesn’t cover cases when KV API versionis not provided. A new configuration option, with default value equivalentto the latest KV API version available (kv_version=2) was added to allowprecise 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 toconfigure the path to CA certs when verifying requests toBarbican.

3.0.0

New Features

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

Other Notes

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

2.0.0

Upgrade Notes

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

1.2.1

Bug Fixes

  • Fixed VaultKeyManager.create_key() to consider thelength param as bitsinstead of bytes for the key length. This was causing a discrepancy betweenkeys generated by the HashiCorp Vault backend and the OpenStack Barbicanbackend. Consideringkm as an instance of a key manager, the followingcodekm.create_key(ctx, “AES”, 256) was generating a 256 bit AES key whenBarbican is configured as the backend, but generating a 2048 bit AES keywhen Vault was configured as the backend.

1.2.0

New Features

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

0.16.0

New Features

  • Enhance the key manager to handle requests containing the special (allzeros) managed object ID associated with Cinder’s and Nova’s legacyConfKeyManager. The purpose of this feature is to help users migrate fromthe ConfKeyManager to a modern key manager such as Barbican. The featureworks by ensuring the ConfKeyManager’s all-zeros key ID continues tofunction 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 infavor of the more standard key_manager/auth_url.