April 2025 - openstack-discuss - lists.openstack.org

security auditing and compliance in OpenStack environments
by acc.bu.mo＠gmail.com 08 Apr '25

08 Apr '25

Hi everyone, I'm currently working on my end-of-studies project focused on security auditing and compliance in OpenStack environments. As part of this project, I'm exploring how OpenStack deployments can align with compliance frameworks, especially SecNumCloud (from the French cybersecurity agency ANSSI). However, I'm also very interested in hearing about any tools, methods, or practices used for other standards (ISO 27001, CIS, FedRAMP, etc.). I'm still new to OpenStack and cloud compliance in general, and I'm finding it challenging to identify practical tools or workflows that companies actually use to perform security audits or compliance checks in OpenStack. If you're using (or have used) any tools, scripts, checklists, middleware, SIEM integrations, etc. for auditing OpenStack security or compliance I would be incredibly grateful if you could share your experience or point me in the right direction 🙏 Thank you so much in advance! Best regards,

2 1

Debian OpenStack Epoxy packages are available
by Thomas Goirand 08 Apr '25

08 Apr '25

Hi, Just a quick mail to tell everyone that I have finished Tempest validation of OpenStack Epoxy for OpenStack Bookworm backports. Currently, 1468 tests are passing, and there's only 8 tests that I need to investigate, though looking at the logs, it doesn't seem anything important is ongoing. Also note that I have integrated all Designate tests, that are all passing ok. As always, packages are available through osbpo.debian.net unofficial backports, accessible using extrepo. Under Bookworm, simply do: apt-get install extrepo extrepo enable openstack_epoxy apt-get update I haven't started validation under Debian 13 (aka: Trixie). I'm am currently working on it. It's going to be a little bit more difficult as Trixie runs RabbitMQ 4.0.5, which doesn't support HA queues anymore, so I need to switch to quorum queues in my test bed. Also, Trixie is running Python 3.13, and I've heard Eventlet is still not 100% compatible with it. Having Epoxy in Trixie is nice, because this means Bookworm users will be able to skip Dalmatian, and we're now aligned with the SLURP thing. As always, bug reports are welcome. Cheers, Thomas Goirand (zigo)

1 0

[Kolla-ansible]Dalmatian- How fix this bug: 'Port' object has no attribute 'security_groups
by Franck VEDEL (UGA) 08 Apr '25

08 Apr '25

Hi, New installation with kolla-ansible, Dalmatian, Ubuntu 2204. Everything works… except « Edit port » in Horizon. This bug is known: https://bugs.launchpad.net/horizon/+bug/2089557 My problem is: How to apply the fix with kolla-ansible. Can you help me? This bug is really a problem for my students who use Horizon. Thanks a lot Franck

1 0

[publiccloud-sig] Sessions during PTG
by Felix Kronlage-Dammers 08 Apr '25

08 Apr '25

Hi, the publiccloud-sig will meet twice as part of the PTG. On Tuesday (today) there will be a session at 16 UTC. On Wednesday (tomorrow) we will meet in our usual summertime slot at 7 UTC. The sessions will be here: https://meetpad.opendev.org/apr2025-ptg-public-cloud-sig (check also https://ptg.opendev.org/ptg.html) Looking forward to lively participation :) cheers felix -- Felix Kronlage-Dammers Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[tacker] canceling weekly meeting
by Yasufumi Ogawa 08 Apr '25

08 Apr '25

Hi tacker team, Due to the vPTG, I'm canceling today's irc meeting. Yasufumi

1 0

[security-sig] Office hours during April 2025 PTG
by Jeremy Stanley 08 Apr '25

08 Apr '25

I've booked two PTG slots for OpenStack Security SIG office hours at times where hopefully at least one works no matter which timezone you live in. These days and times were also not heavily used by other teams, so should be fairly conflict-free: Tuesday (2025-04-08) at 13:00-14:00 UTC Thursday (2025-04-10) at 21:00-22:00 UTC There is no set agenda. I'll have the meetpad open for the full hour in case anyone wants to drop in with security-related topics on their mind. See you there! (Or hear you at least; I won't have a camera connected, you don't need one either.) -- Jeremy Stanley

1 0

[ironic] Call to action: Fix SNMP driver, or it may have to go
by Jay Faulkner 08 Apr '25

08 Apr '25

Hey all, So as many of you know, Ironic has had a driver for supporting SNMP-based PDUs (where you use an SNMP command to power on/off servers) for a while. This driver heavily uses pysnmp, a library created by a late Ironic contributor that was taken over by another company afterwards. This library is good, but is extremely fast moving and difficult for Ironic developers to keep up with. In fact, right now, both our SNMP-BMC emulator (virtualpdu) and Ironic are stuck using pysnmp-lexstudio, an old version of pysnmp which is now preventing other packages, e.g. pyasn1, from being upgraded. This is unsustainable in the long term, and it's been in this state for a while already. If you are an operator or organization that utilizes the SNMP driver, you need to rapidly find another method to manage power on your servers or help the Ironic developers maintain the SNMP driver -- at a minimum getting us onto the new pysnmp library (not a small undertaking; it's unexpectedly difficult). It's my intention to propose to the Ironic team that we mark this driver as unsupported and remove any remaining functional testing for it in anticipation of fully removing the driver in a future cycle. I do not want to take this action, but I'd rather have a driver removed from Ironic than one that's not going to work or hold the rest of the OpenStack requirements back. If you use this driver, please get in contact with the Ironic team if you have any resources to help with this migration. Feel free to use me-directly as a contact point if you're unsure where to start. Thanks, Jay Faulkner Ironic Security Liason

1 0

[neutron] PTG schedule created
by Brian Haley 08 Apr '25

08 Apr '25

Hello Neutrinos: I updated the Neutron Etherpad for the PTG to include day/time information for all proposed topics for the week [0]. Please make sure to check if I made any mistakes, or if you think we need more time for discussions. If necessary we can add time on Friday if we need it. Thanks, -Brian [0] https://etherpad.opendev.org/p/apr2025-ptg-neutron

1 0

[neutron] Neutron sriov vf-lag port binding
by Serhat Rıfat Demircan 07 Apr '25

07 Apr '25

Hello everyone, I have tested sriov with Connectx-5 cards, it works well but I also want to try ovs with hardware offload feature. I believe I have properly configured pf, vfs and bonding :). PF’s are working in switchdev mode (I have followed stackhpcs article[1]). Unfortunately, I see port binding errors when creating instances. I have created a vlan provider network and a port with vnic_type=direct under that network. I am trying to create instance with that port. nova-compute.log > 2025-04-04 17:37:28.014 7 ERROR nova.compute.manager [instance: > bf8408e8-20a9-4963-9e50-033e54aba9fe] nova.exception.PortBindingFailed: > Binding failed for port 6cbd8181-5707-4349-9fa0-c35e7370bfcd, please check > neutron logs for more information. neutron-server.log > 025-04-04 17:37:27.000 25 DEBUG > neutron.plugins.ml2.drivers.mech_sriov.mech_driver.mech_driver > [req-ff074be0-e410-4df8-8938-7e2b59a84bfd > req-d9bffb08-7e74-4976-b3ae-8cb544ec71f5 fbbdf9e30cad498180c3b637d1bba6d9 > 3e7a1867f1c24a158b4bb2d2f3f68b9c - - default default] Refusing to bind due > to unsupported vnic_type: direct with switchdev capability bind_port > /var/lib/kolla/venv/lib/python3.10/site-packages/neutron/plugins/ml2/drivers/mech_sriov/mech_driver/mech_driver.py:130 neutron/plugins/ml2/drivers/mech_sriov/mech_driver/mech_driver.py > if (vnic_type == portbindings.VNIC_DIRECT and > 'switchdev' in capabilities): > LOG.debug("Refusing to bind due to unsupported vnic_type: %s " > "with switchdev capability", > portbindings.VNIC_DIRECT) nova.conf > [pci] > passthrough_whitelist = [{"physical_network": "physnet5", "devname": > "ens10f0"},{"physical_network": "physnet6", "devname": "ens10f1"}] [sriov_nic] physical_device_mappings = physnet5:ens10f0,physnet6:ens10f1 Is vnic_type=direct wrong if switchdev in capabilities or is this a configuration issue? Environment: Openstack version: Caracal Operating System: Ubuntu 22.04 Thanks, Serhat [1] - https://www.stackhpc.com/vflag-kayobe.html

3 3

[Octavia][Load Balancer][2023.1] Amphora Fails Health Check – “No Route to Host” & Timeout Errors
by Thamanna Farhath 07 Apr '25

07 Apr '25

Hi OpenStack Community, I am currently facing an issue with the Load Balancer (Octavia) service in my OpenStack deployment and would appreciate your guidance or suggestions on how to troubleshoot and resolve it. Environment Details: OpenStack Version: 2023.1 (Antelope) Operating System: Ubuntu 22.04 Octavia Backend: Amphora Network Type: VXLAN Deployment Tool: Kolla Ansible Issue Summary: After creating a Load Balancer, the Amphora instance is successfully launched. However, approximately 18 minutes later, the Load Balancer transitions to an ERROR state. Error Observed: octavia.common.exceptions.ComputeWaitTimeoutException: Waiting for compute id a222527f-8336-4fb1-8e9e-0e3ac6e8d580 to go active timeout. octavia.amphorae.driver_exceptions.exceptions.AmpConnectionRetry: Could not connect to amphora, exception caught: HTTPSConnectionPool(host='192.168.200.247', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError: Failed to establish a new connection: [Errno 113] No route to host) What I’ve Tried: Created a VXLAN-based internal network: openstack subnet create --network octavia-mgmt-net --subnet-range 192.168.200.0/24 octavia-mgmt-subnet openstack router create octavia-router openstack router add subnet octavia-router octavia-mgmt-subnet openstack router set octavia-router --external-gateway <public-network-id> Manually configured OVS interface: ovs-vsctl add-port br-int octavia-mgmt -- set interface octavia-mgmt type=internal ip addr add 192.168.200.1/24 dev octavia-mgmt ip link set octavia-mgmt up Security groups are open (allowing all ingress and egress). Verified OVS bridge setup – interface appears correctly on br-int. Behavior Noticed: Amphora instance gets created but fails to communicate with the controller after a while,so health checks fails. The controller cannot reach the Amphora management IP (192.168.200.x). Logs show heartbeat/connection issues (No route to host, timeouts). Request for Help: I would appreciate any of the following: Suggestions to verify if the management network is properly routed from controller to Amphora. Best practices for setting up the Octavia management network using VXLAN. Troubleshooting steps for verifying health manager connectivity to Amphora. Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

2 1