Yaook

By thread

yaook@lists.alasca.cloud

December 2025

1 participants
2 messages

[Security Advisory] MariaDB replication traffic is send unencrypted between MariaDB instances when using IPv6

by Stefan Hoffmann

Hi, we got informed about a security issue and released a fix for it now. A CVE ID is requested and will be added later. The link to the advisory will change due to that. Temporary link: https://yaook.cloud/security-advisories-cve-2025-xxxxx/ YAOOK Security Advisory for CVE-2025-XXXXX * Date: 2025-12-12 * Affected versions: >=0.20240809.0 <0.20251211.0 * Fixed versions: 0.20251211.0 * Bug report: https://gitlab.com/yaook/operator/-/issues/631 * Patch: https://gitlab.com/-/project/21574229/uploads/6a4f06d3ae63f8ed4657825f864f9… What is CVE-2025-XXXXX and how does it affect YAOOK?CVE-2025-XXXXX describes the issue that MariaDB replication traffic is sent unencrypted between MariaDB instances managed by YAOOK’s infra-operator if the cluster is IPv6-enabled. In 2024, YAOOK gained official support for running inside IPv6-only and dual-stack Kubernetes clusters. For this, various services had to be updated to allow listening on IPv6 sockets in addition to (or instead of) IPv4 sockets. For MariaDB, there exist three communication channels: The normal client/server traffic with MariaDB-compatible clients (such as the OpenStack APIs), the incremental state transfer and online replication traffic (WSREP) and the SST channel (used if, after a restart, the incremental state transfer is not sufficient to bring a replica up-to-date). The WSREP transfer channel is configured through a single MariaDB configuration option called `wsrep-provider-options`. Before the addition of IPv6 support, this option was set up by YAOOK exclusively through the MariaDB configuration file. As value to that single option, one provides the path to the TLS certificates and the listening address of the WSREP channel, formatted as string into in a MariaDB-specific format. When IPv6 support was implemented, the listening address of the WSREP socket had to be changed to `[::]` in order to be able to accept connections from other instances via IPv6. This was implemented by passing an additional `–wsrep-provider-options` command line argument to the MariaDB process [1]. Unfortunately, that overrode the TLS-related options from the configuration file, effectively disabling TLS for the WSREP channel whenever that code path is hit. Is my cluster vulnerable?The affected code path is executed whenever the `status.podIP` field of the MariaDB pod is an IPv6 address. This is the case in IPv6-only clusters and may be the case in dual-stack clusters. If that is the case, TLS encryption of the WSREP channel is disabled, which causes almost all MariaDB contents to be transferred without encryption in transit. Mitigating factors * This vulnerability only affects IPv6-only clusters. * The unencrypted traffic never leaves the Kubernetes service network, which may or may not already be a trusted domain in your security model. UpgradingA new stable release with version 0.20251211.0 has been published. Affected clusters will face a downtime during upgrades, because TLS encryption on the WSREP channel cannot be enabled online. During the upgrade, the highest replica of all databases managed by the infra-operator will enter a Error / CrashLoopBackOff state. At that point, you have to execute the following steps for each separate database instance: 1. `yaookctl pause mysqlservices $name` 2. `kubectl -n yaook scale sts $name-db –replicas=0` 3. Wait for the last database replica to terminate. 4. Optional: `kubectl -n yaook scale sts $name-db –replicas=$n`, where `$n` is the number of replicas you usually have. This may be slightly faster than waiting for the infra-operator to reset the replica count after the next command. 5. `yaookctl unpause mysqlservices $name` During the time the last replica of a database is shut down, the database can, obviously, not serve requests. This will cause HTTP 500 responses from affected API services and may have downstream adverse effects on workloads (such as Kubernetes Cinder CSI providers running inside the cluster). CreditsThis vulnerability was found by Martin Morgenstern and Maximilian Brandt, CLOUD&HEAT Technologies GmbH. [1] implemented by passing an additional `–wsrep-provider-options` command line argument to the MariaDB process https://gitlab.com/yaook/operator/-/commit/21ceaa1375bfd08d5706adfcd74f630f…

Dec. 12, 2025

[yaook][infra-operator] Issue withAMQP custom images

by Stefan Hoffmann

Hi, since the release 0.20251127.0-rolling.T101903.g92875879628b (there is no stable release with this yet, it may be 0.20251204.0 or 0.20251208.0) it's not possible anymore to set custom images for AMQP services. For the most yaook users this is no issue, as all AMQPs are created by other operators. Also normal version overrides still work. But if you want to define a different rabbitmq image (different path than the other yaook images) currently don't work. There is an issue[1] to fix that. [1] https://gitlab.com/yaook/operator/-/issues/633

Dec. 8, 2025