New Features¶

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

Security Issues¶

• Part of the fix for Story 2009664 required renaming the policy forContainer 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 tooverride the default policies you will need to update them to use thenew names.

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

Bug Fixes¶

• Fixed Story #2009247 - Fixed the response forPOST /v1/secrets/{secret-id}/metadata so it matches the documentedbehavior.

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

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

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 usedinstead of[p11_crypto_plugin]/slot_id to identify the Token to beused by the PKCS#11 plugin. When either one of the new options is definedthe plugin will search all slots on the PKCS#11 device for a token thatmatches the given value.token_serial_number has the highest precendenceand other values will be ignored when this value is set. Iftoken_serial_number is not set, thentoken_label hasthe next highest precedence andslot_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. Whenset to True, the flag CKF_OS_LOCKING_OK will be passed to the C_Initializefunction. The new option defaults to False.

• A new “token_labels” option has been added to the PKCS#11 driver whichsupersedes the previous “token_label” option. The new option is used tospecify a list of tokens that can be used by Barbican. This is requiredfor some HSM devices that use separate tokens for load balancing. For mostuse cases the new option will just have a single token. The old optionis 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 longerrequires any parameters at run time. If any value used by the PKCS#11value is needed it will be taken from /etc/barbican/barbican.conf.You may continue to specify any values on the command line, and thosewill take precedence over the values specified in barbican.conf, so anyexisting scripts that use barbican-manage should continue to work asexpected.

Upgrade Notes¶

• The default value of[oslo_policy]policy_file config option hasbeen changed frompolicy.json topolicy.yaml.Operators who are utilizing customized or previously generatedstatic policy JSON files (which are not needed by default), shouldgenerate new policy files or convert them in YAML format. Use theoslopolicy-convert-json-to-yamltool to convert a JSON to YAML formatted policy file inbackward 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 theoslo.policy libraryduring the Victoria development cycle. As a result, this deprecation isbeing noted in the Wallaby cycle with an anticipated future removal of supportbyoslo.policy. As such operators will need to convert to YAML policyfiles. Please see the upgrade notes for details on migration of anycustom policy files.

Security Issues¶

• The new secure-rbac policy does not allow listing ACLs for private secretsor private containers. This is a change from the previous policy whichallowed listing ACLs of private secrets or private containers by users withsome 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 membersof a project. This is a change from the previous policy which only allowedthese operations by the project admin or the secret or container creators.

• The new secure-rbac policy allows consumers to be added and deleted bymembers. This is a change from the previous policy which only allowed thesecret’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 fromcontainers by members. This is a change from the previous policy whichonly 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 deletionby the creator or the project admin.

• The current policy allows all users except those with the audit role tolist orders or retrieve an orders metadata. The new desired policy willrestrict this to members. For backwards compatibility, the old policiesremain 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 isa change from the previous policy that only allowed deletion by theproject admin.

• The current policy only allows users with the key-manager:service-adminrole to list, get, add, update or delete project quotas. The newpolicy allows system readers to list quotas and get quotas for specificprojects 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 tolist a secrets metadata keys and get the metadata values. The newdesired policy will restrict this to members. For backwardscompatibility, the old policies remain in effect, but they aredeprecated and will be removed in future, leaving the more restrictivenew policy.

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

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

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

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

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

Bug Fixes¶

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

• Fixed Story #2008649: Correctly reinitialize PKCS11 object after secondaryfailures.