May 2026 - openstack-discuss - lists.openstack.org

[OSSA-2026-007] OpenStack Keystone: LDAP identity backend does not convert enabled attribute to boolean (CVE PENDING)
by Goutham Pacha Ravi 05 Aug '26

05 Aug '26

================================================================================== OSSA-2026-007: LDAP identity backend does not convert enabled attribute to boolean ================================================================================== :Date: April 14, 2026 :CVE: CVE-2026-pending Affects ~~~~~~~ - Keystone: >=8.0.0 <25.0.1, >=26.0.0 <26.1.1, >=27.0.0 <27.0.1, >=28.0.0 <28.0.1 Description ~~~~~~~~~~~ Benedikt Trefzer and Andrew Bogott independently reported a vulnerability in the Keystone LDAP identity backend. When the user_enabled_invert configuration option was False (the default), Keystone did not correctly interpret the LDAP enabled attribute, causing users disabled in LDAP to be treated as enabled and allowed to authenticate. Deployments using the LDAP identity backend without user_enabled_invert=True or user_enabled_emulation are affected. Patches ~~~~~~~ -https://review.opendev.org/982409 (2024.2/dalmatian) -https://review.opendev.org/982408 (2025.1/epoxy) -https://review.opendev.org/982407 (2025.2/flamingo) -https://review.opendev.org/958205 (2026.1/gazpacho) Credits ~~~~~~~ - Benedikt Trefzer from Cirrax GmbH (CVE-2026-pending) - Andrew Bogott from Wikimedia Foundation (CVE-2026-pending) - Grzegorz Grasza from Red Hat (CVE-2026-pending) References ~~~~~~~~~~ -https://launchpad.net/bugs/2121152 -https://launchpad.net/bugs/2141713 Notes ~~~~~ - To work around this vulnerability, set user_enabled_invert=True and use an LDAP attribute with inverted semantics such as nsAccountLock, or use user_enabled_emulation with group-based enabled status. - A CVE request was filed with MITRE on 2026-04-10. - The fix was merged on the master branch before the stable/2026.1 branch was cut, so no specific stable/2026.1 patch exists. The fix is included in the gazpacho (29.0.0) release. -- Goutham Pacha Ravi (gouthamr) OpenStack Vulnerability Management Team

1 1

[policy] Removing the enforce_scope config option
by Ghanshyam Maan 17 Jul '26

17 Jul '26

Hello everyone, As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag. What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered. Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure. 2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3]. How to test your project: I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475) oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479 Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies. - https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(statu… I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope. [1] https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.en… [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a… -gmaan

3 13

[policy][cinder][tacker][aetos][aodh][barbican] Removal of enforce_scope impact
by Ghanshyam Maan 26 Jun '26

26 Jun '26

Hi All, I am tagging the 5 projects explicitly that have enforce_scope disabled. As you might have seen in the other email[1], in this cycle, we will remove the enforce_scope flag, meaning scope enforcement will always be enabled with no way to disable it. These 5 projects need to fix their policy/code/tests to be green with scope enforcement. I have pushed the changes to test the same: cinder: https://review.opendev.org/c/openstack/cinder/+/986472 tacker: https://review.opendev.org/c/openstack/tacker/+/986469 aetos: https://review.opendev.org/c/openstack/aetos/+/986470 aodh: https://review.opendev.org/c/openstack/aodh/+/986471 barbican: https://review.opendev.org/c/openstack/barbican/+/984422 I am targeting milestone-2 (July 3rd) to remove the flag; more details about the flag removal plan is in another email. [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… -gmaan

1 1

[Cinder] NFS backend and storage design with multiple storage hosts
by holywine＠outlook.com 24 Jun '26

24 Jun '26

Dear All, I am trying to build a minimum usable production-level openstack cloud with Openstack-ansible 2025.1 with 5 servers (3 x controller + 2 x compute). Trying to make good use of hard drive capacity each server reserves a dedicated partition for storage, say /dev/sda3, mounted on /nfs_volume. The idea is to use NFS as cinder backend. With enormous trials the deployment is finished finally but with problem on cinder volume service. The cinder-scheduler service is ok but the cinder volume service is down from time to time. With a lot of web browsing still no clear view on what happening. It makes me thinking to look back to the foundamentals. As a total rookie for cinder and openstack storage design highly appreciate if anybody please provide some clue on below questions. What is the best storage design for this scenario? Would it be good or possible to set all 5 servers as storage host? What is the storage host BTW? It seems not to match any concept in cinder? What is the shares for each storage host? Shall it be pointing to local or remote storage？ Shall all storage hosts have the same or different shares settings? What is the critical part in cinder.conf and nfs_shares to substantialize the design ideas above? Thanks! BR, Frank

3 5

[zun] Service is broken for 2026.1 with constrained oslo_db
by Dmitriy Rabotyagov 16 Jun '26

16 Jun '26

Hey there, I wanted to let the community know, that Zun service has been released in a broken state for the 2026.1 and is not passing CI tests with constrained version of oslo.db [1], due to reliance on the legacy engine facade, which has been removed from the oslo.db for 2026.1 With that, patch fixing Zun for 2026.1 was published around a month ago, with no reviews from the Zun Core Reviewers group. It would be really appreciated if somebody from the Zun team could have a look at the state of the gates, and merge/backport required patches to ensure working state of the service. Thanks in advance. [1] https://opendev.org/openstack/requirements/src/commit/7e07cb254ee7786723be7… [2] https://review.opendev.org/c/openstack/zun/+/982362

1 1

[cinder][os-brick] Avoiding redundant rescans on target-driven-rescan arrays
by brian＠purestorage.com 05 Jun '26

05 Jun '26

Hi all, I'd like to float an idea before writing any code or a spec, to see whether it's a direction the os-brick maintainers would be open to. I work at Pure Storage, and a growing number of arrays (Pure FlashArray included, but the underlying mechanisms are standards-based and others can/do use them) implement what I call "target-driven rescan": the array tells the initiator when LUNs appear or disappear, using primitives that have been in the SCSI/iSCSI/FC specs for a long time -- - REPORTED LUNS DATA HAS CHANGED (UA 3Fh/0Eh) on attach, - LOGICAL UNIT NOT SUPPORTED (25h/00h) plus multipath-tools >= 0.14.0's purge_disconnected on detach, - for FC, the array briefly logging the initiator out so it re-logins and rescans on its own to discover the first volume, - and for iSCSI, the array keeping the session alive even with zero mapped LUNs so the same UA 3Fh/0Eh (delivered as an iSCSI Async Event) drives discovery of the first volume too. On a host that's correctly configured, the kernel and multipathd discover and clean up devices without anyone writing to /sys/.../scan or /sys/.../delete. os-brick today doesn't know any of this is happening. On every attach it sleeps a few seconds and then forces several host/scan writes per path; on every detach it force-removes the SCSI devices itself and (for iSCSI) tears the session down when the last LUN is gone -- which on a target that supports it actively undoes the array's ability to fast-path the *next* first-volume attach. The end result is that attaches are noticeably slower than they need to be, detaches race with multipathd, and the logs are full of "rescan & retry" lines on what are really successful operations. What I'd like to explore is opt-in behavior, driven by a hint in connection_properties (e.g. target_driven_rescan: True) that the Cinder volume driver sets. When the hint is present, os-brick would: 1. On attach, poll for the device first and only fall back to forced host/scan if the kernel hasn't surfaced it within a short window. 2. On detach, let multipathd handle the cleanup when purge_disconnected is in effect, and leave the iSCSI session up when the last LUN goes away. Defaults for every existing backend stay exactly as they are today, so this should be a no-op for anything that hasn't opted in. Before I write this up properly (spec, patches, tests), I'd like to know: - Does this direction sound reasonable in principle? - Any obvious objections, prior art, or constraints I should be aware of? - Is a connection_properties hint the right knob, or would you rather see this driven from somewhere else (e.g. a connector subclass, a capability the driver advertises elsewhere)? Happy to write a longer problem statement with code references if that would help the discussion. Thanks, Brian

3 4

[kolla-ansible] How to properly add Ansible inventory information (i.e. host-specific information)?
by Johannes Kastl 03 Jun '26

03 Jun '26

Dear all, I hope it is fine to ask kolla-ansible related questions on this list (as I saw some other mails tagged kolla-ansible). This might be worth a documentation bug report, but I wanted to ask first. I am a little confused by the kolla-ansible documentation on adding host-specific information (think SSH settings etc.). I did not find this mentioned in the Ansible tuning section (which is fine, as this is not "tuning") The documentation I found is here: https://docs.openstack.org/kolla-ansible/2026.1/user/multinode.html It talks about editing the inventory file: ``` Edit the inventory file in the Kolla Ansible directory ansible/inventory/multinode. If Kolla Ansible was installed with pip, it can be found in /usr/share/kolla-ansible. ``` In contrast, the quick start guide explicitly copies the inventory file to a new directory and specifies it with the `-i ...` CLI option. What is the preferred way? Why two different ways in the documentation? (Also, when I installed kolla-ansible with Pip, the path is not `/usr/share/kolla-ansible`, but `path_to_virtualenv/usr/share/kolla-ansible`.) I found no hints on what happens if the kolla-ansible version is being updated using PIP, whether those files will stay intact or will be overwritten? The multinode documentation mentions using group_vars and host_vars, but adds them in the kolla-ansible ansible/inventory/ directory (I think). I have not yet tested this (my deployment is currently running), but when I organize the files in a directory (including an multinode or all-in-one inventory file and group_vars or host_vars directories) I would need to specify the path to the **directory** in the `kolla-ansible XXX -i ...` command, not the path to the inventory **file**. Right? If so, this should be mentioned in the documentation. Using the same set of instructions for both the quick start and other parts of the documentation would make this easier for the readers. I think the documentation could be improved and clarified in this regard, it is confusing to say the least. And I have been using Ansible for a long time... :-) Kind Regards, Johannes

3 7

[kolla-ansible] Handling TLS certificates and their rotation?
by Johannes Kastl 03 Jun '26

03 Jun '26

Dear all, I am currently playing around with kolla-ansible and am setting up a small 3-node OpenStack instance (if I get it working on the poor hardware I have) in my homelab. One thing I normally do is get TLS certificates from Let's Encrypt, as this means I do not have to run my own CA and import the CA certificate on every browser or machine. As my domain registrar supports a DNS API, I can get certificates even without the services being publicly available. But those are rather short-lived with the lifetime being reduced even further in the future. Thankfully, we have automation... I was wondering how people are handling TLS certificates for kolla-ansible, especially their rotation. As the external VIP can move between machines, I take it a renewed certificate needs to be distributed from one of the machines to the others somehow? And the keepalived and haproxy containers need a restart (possibly other containers, too)? What would be the easiest way to do that? Running kolla-ansible from within a renew hook sounds kind of overkill. Scripting this or writing a ansible playbook sounds hacky. I noticed some references to Let's encrypt and ACME with kolla-ansible, but have not found a thorough explanation. It looked like HTTP-01 challenge only from what I saw. Or is using the kolla-ansible managed CA the "easiest" way, as the certificate has a much longer lifetime? What are people out there doing? Kind Regards, Johannes

5 8

[kolla-ansible] External ceph: Do I need to create the ceph.client.nova.keyring if there is no separate nova user?
by Johannes Kastl 03 Jun '26

03 Jun '26

Dear all, I am preparing everything I need to deploy kolla-ansible with an external ceph. https://docs.openstack.org/kolla-ansible/2026.1/reference/storage/external-… ``` Copy Ceph keyring file(s) to: /etc/kolla/config/nova/ceph.client.nova.keyring Note If you are using a Ceph deployment tool that generates separate Ceph keys for Cinder and Nova, you will need to override ceph_nova_user to match. ``` This paragraph confuses me. Do I need to create the ceph.client.nova.keyring file even if - the ceph.client.cinder.keyring file in the nova directory already exists - I only have one cinder user and no separate nova user in Ceph - ceph_nova_user is set to "cinder" ? Kind Regards, Johannes

2 2

[OpenStack][Deployment] Provider network troubleshooting
by holywine＠outlook.com 03 Jun '26

03 Jun '26

Dear All, I am trying to deploy a private openstack cloud with openstack ansible 2025.1. The installation is completed successfully and most functions are working, such as create network, router, VM etc. While there is still something wrong with the provider network. With a small experient below to explain what happened: - Create a provider network 'public' subnetwork: 10.2.46.0/24, vlan 46, gateway: 10.2.46.1 - Create a virtual router the port to provider network (router-ext): 10.2.46.77 the port to tenent network: (router-int): 192.168.1.1 - Create a VM on tenent network with IP 192.168.1.10 - from VM ping 192.168.1.10, OK ping 192.168.1.1, OK ping 10.2.46.77, OK ping 10.2.46.1, NOK The cloud is composed of 5 hosts (3 x infra, 2 x compute): host IP: 10.2.46.71-10.2.46.75 Neutron is configured as OVN L2+ DVR. In each host, 2 network ports are bonded, VLAN 46 is assigned for external (Internet) connection. For example bonds: bond0: interfaces: - enp11s0f0 - enp11s0f1 mtu: 1500 parameters: lacp-rate: fast mii-monitor-interval: 100 mode: 802.3ad transmit-hash-policy: layer3+4 br-host: addresses: - 10.2.46.71/24 interfaces: - bond0.46 routes: - to: default via: 10.2.46.1 nameservers: addresses: - 10.1.1.9 - 8.8.8.8 The provider network setting in user_variables.yml: # Ensure the openvswitch kernel module is loaded openstack_host_specific_kernel_modules: - name: "openvswitch" pattern: "CONFIG_OPENVSWITCH" group: "network_hosts" neutron_plugin_type: ml2.ovn neutron_plugin_base: - ovn-router # DVR/Distributed L3 routing support neutron_ovn_distributed_fip: True neutron_ml2_drivers_type: "vlan,local,geneve,flat" neutron_provider_networks: network_types: "geneve,vlan" network_geneve_ranges: "1:1000" network_vlan_ranges: "public:46:46" network_mappings: "public:br-ex" network_interface_mappings: "br-ex:bond0" BTW if ping router-ext port of router from the host in external network (e.g. 10.2.46.100) there is no response either. Can anybody please give some clue what the problem could be and what I should do for troubleshooting? Thanks a lot in advance! Frank

2 2