Zed Series Release Notes

14.0.0

Security Issues

  • Part of the fix for Story 2009664 required renaming the policy for Container Consumers from “consumers:get” to “container_consumers:get”, “consumers:post” to “container_consumers:post”, and “consumers:delete” to “container_consumers:delete”. If you are using custom policies to override the default policies you will need to update them to use the new names.

  • Fixed Story #2009791: Users with the “creator” role on a project can now delete secrets owned by the project even if the user is different than the user that originally created the secret. Previous to this fix a user with the “creator” role was only allowed to delete a secret owned by the project if they were also the same user that originally created it, which was inconsistent with the way that deletes are handled by other OpenStack projects that integrate with Barbican. This change does not affect private secrets (i.e. secrets with the “project-access” flag set to “false”).

Bug Fixes

  • Fixed Story #2009247 - Fixed the response for POST /v1/secrets/{secret-id}/metadata so it matches the documented behaviour.

  • Fixed Story 2009664 - Fixed the Consumer controller to be able to use the associated Container’s ownership information in policy checks.

  • Fixed Story #2009672 - Fixed validator for Container Consumers to prevent 500 errors.

13.0.0

New Features

  • The default maximum secret size has been increased from 10 kB to 20 kb, and the default maximum request size has been increased from 15 kB to 25 kB.

Bug Fixes

  • Fixed Story 2008335: Fixed a data encoding issue in the Hashicorp Vault backend that was causing errors when retrieving keys that were generated by the Vault Key Manager in Castellan.

12.0.0.0rc1

New Features

  • Added two options for the PKCS#11 Crypto Plugin: [p11_crypto_plugin]/token_serial_number and [p11_crypto_plugin]/token_label. Both are optional and can be used instead of [p11_crypto_plugin]/slot_id to identify the Token to be used by the PKCS#11 plugin. When either one of the new options is defined the plugin will search all slots on the PKCS#11 device for a token that matches the given value. token_serial_number has the highest precedence and other values will be ignored when this value is set. If token_serial_number is not set, then token_label has the next highest precedence and slot_id will be ignored. slot_id will be used when neither one of the new options is set.

  • Added a new boolean option to the PKCS#11 backend: os_locking_ok. When set to True, the flag CKF_OS_LOCKING_OK will be passed to the C_Initialize function. The new option defaults to False.

  • A new “token_labels” option has been added to the PKCS#11 driver which supersedes the previous “token_label” option. The new option is used to specify a list of tokens that can be used by Barbican. This is required for some HSM devices that use separate tokens for load balancing. For most use cases the new option will just have a single token. The old option is deprecated, but will still be used if present.

  • Implement secure-rbac policy for ACLs.

  • Implement secure-rbac for consumers resource.

  • Implement secure-rbac for containers resource.

  • Implement secure-rbac for orders resource.

  • Implement secure-rbac for quotas resource.

  • Implement secure-rbac for secretmeta resource.

  • Implement secure-rbac for secrets resource.

  • Implement secure-rbac for secretstores resource.

  • Implement secure-rbac for transportkeys resource.

  • The hsm subcommand for the barbican-manage command line tool no longer requires any parameters at run time. If any value used by the PKCS#11 value is needed it will be taken from /etc/barbican/barbican.conf. You may continue to specify any values on the command line, and those will take precedence over the values specified in barbican.conf, so any existing scripts that use barbican-manage should continue to work as expected.

Upgrade Notes

  • The default value of [oslo_policy] policy_file config option has been changed from policy.json to policy.yaml. Operators who are utilizing customized or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them in YAML format. Use the oslopolicy-convert-json-to-yaml tool to convert a JSON to YAML formatted policy file in backwards-compatible way.

Deprecation Notes

  • The “token_label” option in the PKCS#11 driver is deprecated. Th new “token_labels” option should be used instead. If present, “token_label” will still be used by appending it to “token_labels”.

  • Use of JSON policy files was deprecated by the oslo.policy library during the Victoria development cycle. As a result, this deprecation is being noted in the Wallaby cycle with an anticipated future removal of support by oslo.policy. As such operators will need to convert to YAML policy files. Please see the upgrade notes for details on migration of any custom policy files.

Security Issues

  • The new secure-rbac policy does not allow listing ACLs for private secrets or private containers. This is a change from the previous policy which allowed listing ACLs of private secrets or private containers by users with some role assignments on the project. The previous policy is deprecated, but it will continue to be used until it is removed in a future release.

  • The new secure-rbac policy allows ACLs to be modified or deleted by members of a project. This is a change from the previous policy which only allowed these operations by the project admin or the secret or container creators.

  • The new secure-rbac policy allows consumers to be added and deleted by members. This is a change from the previous policy which only allowed the secret’s creator or admins or those that had a read ACL on the secret.

  • The new secure-rbac policy allows secrets to be added and removed from containers by members. This is a change from the previous policy which only allowed admins to add and remove secrets.

  • The new secure-rbac policy allows for container deletion by members. This is a change from the previous policy that only allowed deletion by the creator or the project admin.

  • The current policy allows all users except those with the audit role to list orders or retrieve an orders metadata. The new desired policy will restrict this to members. For backwards compatibility, the old policies remain in effect, but they are deprecated and will be removed in future, leaving the more restrictive new policy.

  • The new secure-rbac policy allows for secret deletion by members. This is a change from the previous policy that only allowed deletion by the project admin.

  • The current policy only allows users with the key-manager:service-admin role to list, get, add, update or delete project quotas. The new policy allows system readers to list quotas and get quotas for specific projects and system admins (role:admin and system_scope:all) to add, update and delete project quotas.

  • The current policy allows all users except those with the audit role to list a secrets metadata keys and get the metadata values. The new desired policy will restrict this to members. For backwards compatibility, the old policies remain in effect, but they are deprecated and will be removed in future, leaving the more restrictive new policy.

  • The new secure-rbac policy allows for secret metadata addition, modification and deletion by members. This is a change from the previous policy that only allowed deletion by the project admin or the secret creator.

  • The new secure-rbac policy allows for two-step secret creation to be done by any member. This is a change from the previous policy that only allowed step two to be performed by the creator.

  • The new secure-rbac policy allows for secret deletion by members. This is a change from the previous policy that only allowed deletion by the creator or the project admin.

  • The current policy only allows users with the admin role to list and get secretstore resources. The new policy allows all users to perform these operations.

  • The current policy allows users with the admin role to add or delete transport keys. This interface was only ever intended to be used by system admins, and so it has been restricted using the new policy to the system admin only (admins with system_scope:all).

Bug Fixes

  • Fixed Story #2006978: An admin user now can delete other users secrets by adjust the policy file.

  • Fixed Story #2008649: Correctly reinitialise PKCS11 object after secondary failures.

11.0.0

Upgrade Notes

  • Default for auto_db_create has been changed to False (was True). This is a change compared to the previous behaviour, but required to protect production deployments from performing upgrades without control. If you wish to keep the auto db creation/upgrade behaviour, change this to True in your configuration.

Bug Fixes

  • Fixed Story # 2007732: Migrations broken on MySQL 8.x.

10.0.0

New Features

  • It is now possible for barbican-keystone-listener to listen on the same standard notification topic without interfering with other services by using the notification listener pools feature of oslo.messaging. To use it, set the new [keystone_notifications]pool_name option to some unique value (but the same for all instances of barbican-keystone-listener service). This feature is available only for those messaging transports of oslo.messaging that support it. At the moment those are RabbitMQ and Kafka. For more details see oslo.messagind docs

Upgrade Notes

  • Python 2.7 support has been dropped. Last release of Barbican to support python 2.7 is OpenStack Train. The minimum version of Python now supported by Barbican is Python 3.6.

8.0.0

Prelude

Added new tool barbican-status upgrade check.

New Features

  • Added two new subcommands to barbican-manage hsm that can query the HSM to check if a MKEK or HMAC key with the given label already exists. See barbican-manage hsm check_mkek –help and barbican-manage hsm check_hmac –help for details.

  • New framework for barbican-status upgrade check command is added. This framework allows adding various checks which can be run before a Barbican upgrade to ensure if the upgrade can be performed safely.

  • Port existing policy RuleDefault objects to the newer, more verbose DocumentedRuleDefaults.

Upgrade Notes

  • Operator can now use new CLI tool barbican-status upgrade check to check if Barbican deployment can be safely upgraded from N-1 to N release.

Deprecation Notes

  • Deprecated the generate_iv option name. It has been renamed to aes_gcm_generate_iv to reflect the fact that it only applies to the CKM_AES_GCM mechanism.

Bug Fixes

  • Fixed Story #2004734: Added a new option always_set_cka_sensitive to fix a regression that affected Safenet HSMs. The option defaults to True as required by Safenet HSMs. Other HSMs may require it be set to False.

  • Fixed Story #2004734: Added a new option ‘hmac_keywrap_mechanism’ to make the mechanism used to calculate a HMAC from an wrapped PKEK configurable. This was introduced because of an problem with Utimaco HSMs which throw an ‘CKR_MECHANISM_INVALID’ error, e.g. when a new PKEK is generated. For Utimaco HSMs, ‘hmac_keywrap_mechanism’ should be set to ‘CKM_AES_MAC’ in barbican.conf.

7.0.0

New Features

  • Added new options to the PKCS#11 Cryptographic Plugin configuration to enable the use of different encryption and HMAC mechanisms. Added support for CKM_AES_CBC encryption in the PKCS#11 Cryptographic Plugin.

  • Remap the order:put to orders:put to align with language in the orders controller.

Upgrade Notes

  • (For deployments overriding default policies) After upgrading, please review Barbican policy files and ensure that you port any rules tied to order:put are remapped to orders:put.

Deprecation Notes

  • Deprecated the p11_crypto_plugin:algoritm option. Users should update their configuration to use p11_crypto_plugin:encryption_mechanism instead.

Bug Fixes

  • By default Barbican checks only the algorithm and the bit_length when creating a new secret. The xts-mode cuts the key in half for AES, so for using AES-256 with xts, you have to use a 512 bit key, but barbican allows only a maximum of 256 bit. A check for the mode within the _is_algorithm_supported method of the class SimpleCryptoPlugin was added to allow 512 bit keys for AES-XTS in this plugin.

  • Fixed the response code for invalid subroutes for individual secrets. The API was previously responding with the incorrect code “405 - Method not allowed”, but now responds correctly with “404 - Not Found”.

Other Notes

  • default value of ‘control_exchange’ in ‘barbican.conf’ has been changed to ‘keystone’.

6.0.0

Prelude

This release notify that we will remove Certificate Orders and CAs from the API.

Deprecation Notes

  • Certificate Orders

  • CAs

Other Notes

  • Why are we deprecating Certificate Issuance? There are a few reasons that were considered for this decision. First, there does not seem to be a lot of interest in the community to fully develop the Certificate Authority integration with Barbican. We have a few outstanding blueprints that are needed to make Certificate Issuance fully functional, but so far no one has committed to getting the work done. Additionally, we’ve had very little buy-in from public Certificate Authorities. Both Symantec and Digicert were interested in integration in the past, but that interest didn’t materialise into robust CA plugins like we hoped it would. Secondly, there have been new developments in the space of Certificate Authorities since we started Barbican. The most significant of these was the launch of the Let’s Encrypt public CA along with the definition of the ACME protocol for certificate issuance. We believe that future certificate authority services would do good to implement the ACME standard, which is quite different than the API the Barbican team had developed. Lastly, deprecating Certificate Issuance within Barbican will simplify both the architecture and deployment of Barbican. This will allow us to focus on the features that Barbican does well – the secure storage of secret material.

  • Will Barbican still be able to store Certificates? Yes, absolutely! The only thing we’re deprecating is the plugin interface that talks to Certificate Authorities and associated APIs. While you will not be able to use Barbican to issue a new certificate, you will always be able to securely store any certificates in Barbican, including those issued by public CAs or internal CAs.

5.0.0

New Features

  • Maintain the policy rules in code and add an oslo.policy CLI script in tox to generate policy sample file. The script can be called like “oslopolicy-sample-generator –config-file=etc/oslo-config-generator/policy.conf” and will generate a policy.yaml.sample file with the effective policy.

Deprecation Notes

  • Removed application/pkix media type because Barbican will not be using media types for format conversion.

Other Notes

  • oslo-config-generator is now used to generate a barbican.conf.sample file

4.0.0

Prelude

This release adds http_proxy_to_wsgi middleware to the pipeline.

New Features

  • The ‘http_proxy_to_wsgi’ middleware can be used to help Barbican respond with the correct URL refs when it’s put behind a TLS proxy (such as HAProxy). This middleware is disabled by default, but can be enabled via a configuration option in the oslo_middleware group.

Upgrade Notes

  • The barbican-api-paste.ini configuration file for the paste pipeline was updated to add the http_proxy_to_wsgi middleware.

3.0.0

Prelude

Now within a single deployment, multiple secret store plugin backends can be configured and used. With this change, a project administrator can pre-define a preferred plugin backend for storing their secrets. New APIs are added to manage this project level secret store preference.

New Features

  • New feature to support multiple secret store plugin backends. This feature is not enabled by default. To use this feature, the relevant feature flag needs to be enabled and supporting configuration needs to be added in the service configuration. Once enabled, a project administrator will be able to specify one of the available secret store backends as a preferred secret store for their project secrets. This secret store preference applies only to new secrets (key material) created or stored within that project. Existing secrets are not impacted. See http://docs.openstack.org/developer/barbican/setup/plugin_backends.html for instructions on how to setup Barbican multiple backends, and the API documentation for further details.