Wallaby Series Release Notes¶
12.0.1¶
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.
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, 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 behavior.
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.
12.0.0¶
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 precendence 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_fileconfig option has been changed frompolicy.jsontopolicy.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 backward 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.policylibrary during the Victoria development cycle. As a result, this deprecation is being noted in the Wallaby cycle with an anticipated future removal of support byoslo.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 reinitialize PKCS11 object after secondary failures.
