- Yaook - lists.alasca.cloud

Release v1.1.0 "solves" immutable must have randomly generated names" but will disconnect nova-compute from MQ
by Stefan Hoffmann Jan. 29, 2026

Jan. 29, 2026

Hi, regarding the immutable must have randomly generated names issue: The issue is "solved" in the latest release v1.1.0 BUT if a new compute- node with same name got created, the change will interrupt connectivity to MQ of the nova-compute POD.[1] As the nova-operator recreates the nova-compute-node, a new MQ user with the same username (but different resource name) get's created and than we have 2 MQ users one old "failing" one new. With rolling out [2] the old one can get deleted, but as the username at MQ is the same, the new one don't work for the nova-compute node anymore, till infra-operator recreates the user. So [2]will lead to an interruption of nova-compute MQ connectivity. One "solution" would be to delete the finalizer for all MQ users stuck in immutable-State before rolling out the release. Or you hope, no actions are done to our OpenStack, till the MQ user got updated. Feel free to discuss possible solutions at [1] Regards Stefan [1] https://gitlab.com/yaook/operator/-/issues/630 [2] https://gitlab.com/yaook/operator/-/merge_requests/3331 -- Stefan Hoffmann DevOps-Engineer Cloud&Heat Cloud&Heat Technologies GmbH Königsbrücker Straße 96 (Halle 15) | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. [1] Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann [1] Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/

1 0

OpenStack CVE-2026-22797 Privilege Escalation via Identity Headers in External OAuth2 Tokens
by Stefan Hoffmann Jan. 15, 2026

Jan. 15, 2026

Hi yaook users, today OpenStack published a CVE for a keystone middleware external_oauth2_token. As you can't activate this middleware with yaook currently, we are not affected. https://yaook.cloud/security-advisories-cve-2026-22797/ Best regards, Stefan -- Stefan Hoffmann DevOps-Engineer Cloud&Heat Cloud&Heat Technologies GmbH Königsbrücker Straße 96 (Halle 15) | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. [1] Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann [1] Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/

1 0

New Release Management - release-notes needed for all MRs
by Stefan Hoffmann Jan. 12, 2026

Jan. 12, 2026

Hi yaook-developers, we will merge soon the new release management to yaook[1]. It requires to create release notes for each MR. Temporary link to the docs how to create release notes (when the MR is merged, there will be a static one): [2] Related Issue: [3] [1] https://gitlab.com/yaook/operator/-/merge_requests/2825 [2] https://yaook.gitlab.io/-/operator/-/jobs/12682421941/artifacts/public/deve… [3] https://gitlab.com/yaook/operator/-/issues/490 Best regards Stefan -- Stefan Hoffmann DevOps-Engineer Cloud&Heat Cloud&Heat Technologies GmbH Königsbrücker Straße 96 (Halle 15) | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. [1] Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann [1] Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/

1 0

Broken rolling release 0.20251212.0-rolling.T112342.g9c644a7aea39
by Stefan Hoffmann Jan. 8, 2026

Jan. 8, 2026

Hi, the releases 0.20251212.0-rolling.T112342.g9c644a7aea39 and newer are broken with VM action fails due to service_token_roles_required=true at neutron (and other services). But neutron doesn't has the nova-compute role as allowed service-token-role in it's config[1]. So don't roll it out to your neutron and barbican operator. Currently there is no stable release with this bug. There is already a fix[2] in creation. Best regards Stefan [1] https://gitlab.com/yaook/operator/-/issues/643 [2] https://gitlab.com/yaook/operator/-/merge_requests/3318 -- Stefan Hoffmann DevOps-Engineer Cloud&Heat Cloud&Heat Technologies GmbH Königsbrücker Straße 96 (Halle 15) | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. [1] Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann [1] Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/

1 0

[Security Advisory] MariaDB replication traffic is send unencrypted between MariaDB instances when using IPv6
by Stefan Hoffmann Dec. 12, 2025

Dec. 12, 2025

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…

1 0

[yaook][infra-operator] Issue withAMQP custom images
by Stefan Hoffmann Dec. 8, 2025

Dec. 8, 2025

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

1 0