2025.2 Series Release Notes

21.0.0-21

Upgrade Notes

  • The std.ssh_proxied action now refuses any proxy_command that is not listed in the new [action_std_ssh] allowed_proxy_commands config option (empty by default). If you use proxy_command, add its exact value to this option.

Security Issues

  • 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.

  • Fixed a cross-project isolation flaw when updating workbooks and environments. A regular (non-admin) project member could modify — and unpublish — a public workbook or environment belonging to another project, because the update looked the object up with a query that includes other projects’ public resources and performed no ownership check before writing. Updates now resolve the object within the caller’s own project and enforce check_db_obj_access(), consistently with workflow and action definitions.

  • The cluster maintenance endpoint is now guarded by policy. Reading the status (GET /maintenance) requires the new maintenance:get rule and changing it (PUT /maintenance) requires the new maintenance:update rule; both default to admin only (rule:admin_only). Previously the endpoint enforced no policy, so any authenticated token holder could read the status or switch the cluster to PAUSED - a cluster-wide operation that pauses running executions across all projects. Operators who need to grant these to non-admins can override the rules in policy.yaml.

  • Fixed a resource-sharing privilege escalation. Only the owner of a workflow may now share it (create a membership for it). Previously the share endpoint (POST /v2/workflows/<id>/members) only checked that the caller could see the workflow and that it was private. A project that had a workflow shared with it and accepted the share can read the definition through the shared-resource query, and could therefore re-share the owner’s private workflow with a third project without the owner’s consent. The derived membership was owned by the re-sharing project, so the real owner could neither see nor revoke it, while the third project could accept it and read and execute the owner’s private workflow. The share operation is now rejected with 403 unless the caller is the resource owner.

  • 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.

  • Fixed a remote code execution vulnerability in the std.ssh_proxied action. The action passed a caller-supplied proxy_command straight to paramiko.ProxyCommand, which runs it as a local subprocess on the executor host - before any SSH authentication and regardless of the SSH credentials or gateway supplied. Any authenticated, project-scoped user could therefore run arbitrary commands on every Mistral executor by submitting the action through the standard action-execution API.

    proxy_command is now rejected unless its exact value appears in the new [action_std_ssh] allowed_proxy_commands allow-list, which is empty by default. Existing deployments that rely on a proxy_command must add the exact command string to this option; otherwise the action fails with a clear error instead of executing it.

Bug Fixes

  • create_or_update_cron_trigger now resolves the existing trigger within the caller’s own project, so that when several projects have a cron trigger with the same name the caller’s own one is updated instead of another project’s (possibly public) trigger. The periodic scheduler’s update_cron_trigger bookkeeping is intentionally left unchanged, as it legitimately updates triggers across projects; the cron trigger REST API exposes no update operation.

  • Creating or updating a workflow or ad-hoc action definition (including implicitly through a workbook) no longer touches a definition of another project that happens to have the same name. Previously, when several projects had a definition with the same name, an admin request could pick an arbitrary one of them, move it into the admin’s project and fail with an unhandled duplicate entry error (HTTP 500). The existing definition to update is now looked up by its full unique key (name, namespace and project id).

  • Fixed a regression that caused the READ COMMITTED transaction isolation level to no longer be applied to database connections. The isolation level was set as a side effect of setup_db(), whose startup calls were removed. On MySQL/MariaDB servers using the default REPEATABLE READ isolation level, this broke the named lock synchronization between engines: with several engines running, concurrent completion of parallel branches could raise DBDuplicateEntry errors when creating a “join” task, leaving the workflow execution stuck in the RUNNING state. The isolation level is now set on the engine as soon as it is created, regardless of the code path that triggers the creation.

  • Updating an ad-hoc action definition now verifies that the caller is allowed to modify it, consistently with workflow definitions: a non-admin request can no longer modify a public action definition of another project, and system action definitions are protected from modification by non-admin users at the database layer. In addition, when several projects have an action definition with the same name, an update now always targets the definition of the caller’s project instead of an arbitrary one.

  • Updating a code source or a dynamic action definition no longer risks modifying an object of another project that happens to have the same name. The existing object is now resolved within the caller’s own project (by name, namespace and project id) before writing, and an ownership check is applied, consistently with the other definition types. These resources are admin-only by default policy, so this is a hardening / data-integrity fix rather than a cross-tenant escalation.

  • update_workbook now verifies ownership before writing. Previously it was only protected indirectly (a workbook update cascades into the workflow-definition update, which was guarded); making the workflow lookup project-scoped removed that incidental protection, so the guard is now applied to the workbook itself.

21.0.0

New Features

  • Added mutually exclusive config options [action_providers]/allowlist and [action_providers]/denylist that can be used to filter what action providers is loaded.

  • Added mutually exclusive config options [legacy_action_provider]/allowlist and [legacy_action_provider]/denylist that can be used to filter what actions is loaded by the legacy action provider.

Upgrade Notes

  • Support for Python 3.8 and 3.9 has been dropped.

  • The oslo_rpc_executor option is removed. If you were explicitly setting oslo_rpc_executor = threading in your configuration, you can safely remove this setting as threading is now the only supported executor type.

Deprecation Notes

  • Deprecate the api_workers option for mistral-api. This option was used to spawn multiple workers when using oslo.service wsgi server. Since we moved to cheroot, this is not possible anymore. If you want to use more than one process to handle Mistral API requests, you should consider using mistral-wsgi-api behind a wsgi server.

  • Kombu RPC driver is now deleted from mistral RPC drivers. Only oslo messaging driver is supported.

Bug Fixes

  • The Mistral API is now served by cheroot.wsgi.Server instead of the deprecated oslo_service.wsgi / eventlet stack. Behaviour and CLI commands are unchanged.

Other Notes

  • Adding a new wsgi entrypoint to allow using it within WSGI servers (like uWSGI) using mistral.wsgi:application.

    Note that this is the only way to start more than one mistral API worker.

    Also adding two environment variables MISTRAL_CONFIG_DIR and MISTRAL_CONFIG_FILE to allow setting config-dir and config-file when using the new wsgi entrypoint.

  • The /v2/services endpoint in mistral is now removed. This endpoint was using tooz.coordination which we decided to get rid of in the previous release. That endpoint was introduced in the past to help administrator know which services were running but we believe this is not widely used and can easily be replaced by external tooling.