Current Series Release Notes¶

22.0.0-24¶

Added a new cron_triggers:publicize policy (admin_only) and enforcement on create when scope is public. Previously, the cron trigger POST endpoint hardcoded the scope to private and ignored the scope field from the request body, so cron triggers could never be created as public. The scope field is now properly passed through to the database.

Added a new dynamic_actions:publicize policy (admin_only) and enforcement on both create and update operations when scope is public. Previously, the dynamic actions POST endpoint did not persist the scope field and neither POST nor PUT enforced a publicize policy, allowing any user with create or update access to make dynamic actions public.

Added a new environments:publicize policy (admin_only) and enforcement on both create and update operations when scope is public. Previously, the environment POST endpoint did not accept the scope field in the request body and neither POST nor PUT enforced a publicize policy, allowing any user with update access to make environments public.

Added a new workbooks:publicize policy (admin_only) and enforcement on both create and update operations when scope is public. Previously, any project owner could make workbooks public as there was no publicize policy check on the workbook endpoints.

All code_sources and dynamic_actions API policies are now restricted to admin users only (admin_only). Previously, these policies defaulted to admin_or_owner, allowing any project owner to create, read, update, and delete code sources and dynamic actions. Operators who need to restore the previous behavior can override the relevant policies in their policy.yaml.

The publicize policy for workflows, actions, and event triggers is now restricted to admin users only (admin_only). Previously, any project owner could make these resources public. A new code_sources:publicize policy has also been added with the same admin_only default, and publicize checks are now enforced on both create and update operations for code sources and event triggers where they were previously missing.

The Keystone auth_token and service_catalog are now masked in the workflow execution context (replaced with ***). Previously, their real values were persisted in the database and accessible to workflow authors via $.openstack.auth_token and $.openstack.service_catalog YAQL expressions, which could allow token exfiltration. Actions are not affected as they receive their authentication token through the RPC context.

Fixed a keystone authentication failure when a workflow running under a trust-scoped token triggers another keystone call (for example, creating a cron trigger from within a workflow). The previous implementation passed the user’s token to keystoneclient.Client directly, which internally issues POST /v3/auth/tokens to re-authenticate. Keystone rejects this for trust-scoped tokens. The client now uses the admin_token keystoneauth1 plugin, which consumes the existing token without re-authenticating. See LP#2048851.