Vladimir Kozhukalov 9d891d3e67 Use mTLS and a shared client certificate for RabbitMQ
Configure RabbitMQ to require mutual TLS (ssl_options.fail_if_no_peer_cert
= true) so every service must present a client certificate, the messaging
analog of the MariaDB REQUIRE X509 change.

Instead of rendering separate MariaDB and RabbitMQ client certificates, each
chart now renders a single per-chart client certificate (<chart>-client) used
for all mTLS backend connections. The MariaDB client certificate secret is
renamed from <chart>-mariadb-client to <chart>-client and the
secrets.tls.oslo_db.<chart> value moves to secrets.tls.client.<chart>.

The RabbitMQ client certificate mount is gated on tls.oslo_messaging so
messaging TLS can be toggled independently of API and DB TLS, and uses the
shared client certificate. A distinct pod volume name (rabbitmq-certs) lets
the same secret be mounted alongside the MariaDB certificate without a
duplicate volume.

The helm-toolkit rabbit-init job manifest gates its client certificate mount
and the REQUIRE X509 environment on the presence of a TLS secret instead of
manifests.certificates.

Add values_overrides/<chart>/messaging-tls.yaml, the server-side
values_overrides/rabbitmq/messaging-tls.yaml with mTLS enforced, and
tools/deployment/common/verify-rabbitmq-tls.sh wired into the compute-kit-tls
gate.

Applied to keystone, nova, neutron, glance, cinder, heat, barbican, manila and
blazar (messaging) and freezer, horizon, placement and zaqar (cert rename).

Signed-off-by: Vladimir Kozhukalov <[email protected]>
Change-Id: I8067412384008d27345763c11c8c011594d8f718
2026-06-12 22:19:53 +00:00
2026-04-15 12:01:06 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-05-06 14:22:06 -05:00
2026-05-06 14:22:06 -05:00
2026-05-06 14:22:06 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2026-05-06 14:22:06 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2025-03-12 22:59:57 -05:00
2019-04-19 19:45:14 +00:00
2025-06-16 13:23:04 -05:00
2016-11-12 14:26:57 -05:00
2026-04-14 11:12:36 -05:00
2026-04-14 11:12:36 -05:00
2021-04-06 18:44:59 +00:00
2025-03-12 22:59:57 -05:00
2025-03-12 22:59:57 -05:00

OpenStack-Helm

Mission

The goal of OpenStack-Helm is to provide a collection of Helm charts that simply, resiliently, and flexibly deploy OpenStack and related services on Kubernetes.

Versions supported

The table below shows the combinations of the Openstack/Platform/Kubernetes versions that are tested and proved to work.

Openstack version Host OS Image OS Kubernetes version
2025.1 (Epoxy) Ubuntu Jammy Ubuntu Jammy >=1.33,<=1.35
2025.1 (Epoxy) Ubuntu Noble Ubuntu Noble >=1.33,<=1.35
2025.2 (Dalmatian) Ubuntu Noble Ubuntu Noble >=1.33,<=1.35
2026.1 (Gazpacho) Ubuntu Noble Ubuntu Noble >=1.33,<=1.35

Communication

  • Join us on IRC: #openstack-helm on oftc
  • Join us on Slack (this is preferable way of communication): #openstack-helm
  • Join us on Openstack-discuss mailing list (use subject prefix [openstack-helm])

The list of Openstack-Helm core team members is available here openstack-helm-core.

Storyboard

You found an issue and want to make sure we are aware of it? You can do so on our Storyboard.

Bugs should be filed as stories in Storyboard, not GitHub.

Please be as much specific as possible while describing an issue. Usually having more context in the bug description means less efforts for a developer to reproduce the bug and understand how to fix it.

Also before filing a bug to the Openstack-Helm Storyboard please try to identify if the issue is indeed related to the deployment process and not to the deployable software.

Our documentation is available here.

This project is under active development. We encourage anyone interested in OpenStack-Helm to review the code changes

Our repositories:

We welcome contributions in any form: code review, code changes, usage feedback, updating documentation.

Release notes

We use reno for managing release notes. If you update a chart, please add a release note using the following command:

reno new <chart_name>

This will create a new release note file releasenotes/notes/<chart_name>-<sha>.yaml. Fill in the necessary information and commit the release note file.

If you update multiple charts in a single commit use the following command:

reno new common

This will create a new release note file releasenotes/notes/common-<sha>.yaml. In this case you can add multiple chart specific sections in this release note file.

When building tarballs, we will use the reno features to combine release notes from all files and generate <chart_name>/CHANGELOG.md files.

S
Description
Helm charts for deploying OpenStack on Kubernetes
Readme 138 MiB
Languages
Shell 57.3%
Go Template 31.5%
Python 9.8%
Jinja 1.2%
Makefile 0.2%