Amphora or OVN for Kubernetes Services on OpenStack: protocols, algorithms, health checks, security groups, cost, and who OSSA-2026-039 affects.
If your team runs Kubernetes on an OpenStack cloud, the traffic to each app you expose passes through a load balancer that OpenStack builds for you. You create a Kubernetes Service of type LoadBalancer, and the OpenStack cloud controller manager asks Octavia, OpenStack's load balancing service, for a load balancer. Each Service gets its own, unless you tell Services to share one.
Octavia can build that load balancer in two ways, called providers. Amphora runs each load balancer on HAProxy virtual machines: one with Octavia's default SINGLE topology, two with ACTIVE_STANDBY. OVN programs the load balancer as flows in the OVN network your instances already use. You choose the provider once per cluster, and it decides which protocols, algorithms and health checks your Services can use.
On September 21, the OpenStack security advisory OSSA-2026-039 gave teams a reason to revisit that choice. It describes a flaw in the amphora provider: a user who owns an amphora load balancer could inject HAProxy configuration and run commands as root on the amphora. The OVN provider is not affected.
This post is for platform and DevOps teams running Kubernetes on OpenStack who now have to decide whether to patch and stay on amphora, or move some clusters to OVN. A wrong pick shows up quickly. Services never get an address, health checks can't be configured, or the cloud ends up hosting VMs nobody budgeted for. The sections below show how to tell whether you are affected, then compare the two providers on what your Services need from a load balancer, so you can pick one per cluster.
Is your OpenStack load balancer affected by OSSA-2026-039?
Only if its load balancers run on amphora. The advisory covers four fields: tls_ciphers on listeners and pools, and redirect_url and redirect_prefix on L7 policies. Octavia copied them into the amphora's HAProxy configuration without rejecting control characters.
The owner of a load balancer could use those fields to run commands as root on the amphora. From the amphora, they could read other tenants' TLS private keys and certificates, read the deployment's heartbeat key, and reach the control-plane network the amphora is attached to.
The affected Octavia versions are 0.8.0 and later releases below 16.1.0, plus 17.0.0 and 18.0.0. The advisory lists fixes for 2025.1 Epoxy through 2026.2 Hibiscus, with two changes per branch: one for the tls_ciphers fields and one for the redirect fields. OVN is not affected, because it never renders tenant input into an HAProxy configuration.
By default, Atmosphere enables only the amphora drivers in Octavia, with amphorav2 as the default provider. Clusters on a default deployment therefore use amphora.
We updated the Octavia image on all seven Atmosphere stable branches, zed through 2025.2, to a build with the tls_ciphers fix (CVE-2026-94572). The update merged on September 22 (UTC). The advisory also needs a second change for the redirect fields (CVE-2026-94571), so confirm that the Octavia build you run includes both.
Patching answers the advisory. Moving to OVN is a separate decision, and it depends on what your Services need from the load balancer.
OVN load balancer limits: protocols, TLS and algorithms
The OVN provider load balances TCP and UDP. It has no layer 7 support, so you get no HTTP, HTTPS or TERMINATED_HTTPS listeners and no L7 policies. Octavia's feature matrix marks these listener settings as amphora-only:
tls_ciphers, tls_versions and TLS certificate references- X-Forwarded-For and the other inserted headers
allowed_cidrs, connection limits and listener timeouts
OVN can carry Services that expose TCP or UDP ports and terminate TLS inside the cluster, in an ingress controller or in the application. If the certificate has to live on the load balancer, you need amphora.
OVN also offers fewer algorithms. Round robin and least connections are not available. Our magnum-cluster-api driver uses SOURCE_IP_PORT on OVN clusters and refuses any other value in the octavia_lb_algorithm label. We added that label after a user reported the "OVN provider does not support ROUND_ROBIN algorithm" error. Amphora clusters use ROUND_ROBIN by default.
Addressing has limits too. OVN does not support pools that mix IPv4 and IPv6 members, and Tempest does not test its IPv6 support.
Octavia health checks and failover on amphora and OVN
An amphora is a Nova instance. Octavia's health manager watches each amphora and runs a failover when one fails unexpectedly. Each load balancer has one amphora under the default SINGLE topology and two under ACTIVE_STANDBY.
OVN has no instance that can fail. The load balancer exists as flows on every node, so it is highly available by design. There is no failover step and no flavor to size.
Member health checks differ more. OVN supports TCP and UDP-CONNECT monitors. Amphora adds HTTP, HTTPS and TLS-HELLO monitors, so it can also probe a URL path and match the status code.
These are the monitor types Octavia offers. Your cloud controller manager picks the monitor it creates for a Kubernetes Service, so check what it creates before you rely on an HTTP check. In magnum-cluster-api, the octavia_lb_healthcheck label is on by default, and it has to stay on for Services that set externalTrafficPolicy: Local.
Does the OVN load balancer need different security group rules?
Yes. A user in magnum-cluster-api #479 reported no connectivity when using OVN as the load balancer. The OVN provider needs node port services to accept traffic from anywhere, and the Cluster API provider for OpenStack documents that requirement.
Our driver creates those rules for you. On every node of every magnum-cluster-api cluster, managed security group rules open TCP and UDP ports 30000 to 32767 to 0.0.0.0/0. Amphora clusters get the same rules.
Keep that exposure in mind. Those node ports accept traffic from any IPv4 address the network can deliver to the nodes. OVN load balancers also lack allowed CIDRs and VIP security groups, so the load balancer itself can't filter clients. On amphora, you can set allowed_cidrs on the listener.
Setting the Octavia provider for a Kubernetes cluster on OpenStack
In magnum-cluster-api, the octavia_provider label sets the provider for both the load balancer in front of the Kubernetes API servers and the Service load balancers that the cloud controller manager creates. Running OVN for Services and amphora for the API is an open request (#527).
When you update an existing cluster, its API load balancer keeps its provider. Set the provider in the cluster template before you create the cluster:
openstack coe cluster template create k8s-ovn --coe kubernetes \
--image <node-image> --external-network public --master-lb-enabled \
--labels octavia_provider=ovn
Octavia only builds load balancers for providers enabled in its configuration, so the cloud needs the OVN provider turned on first. Atmosphere enables only the amphora drivers by default, so turning on OVN means changing your deployment's Octavia configuration. If you are planning that change on an Atmosphere cloud, you can speak with one of our engineers about how it affects the clusters you already run.
Octavia amphora VM count and placement
Each amphora load balancer runs on one or two Nova instances, depending on topology. Each instance boots from a Glance image and is sized by a flavor. Take a cluster with 20 LoadBalancer Services, each with its own load balancer, plus the API load balancer. It runs 21 amphorae, or 42 with ACTIVE_STANDBY. The cloud has to host each one, and each waits for an instance boot before it serves traffic.
OVN creates no VMs, so it adds no instances, and its load balancers can be deployed faster.
Those instances buy you placement control. Amphora lets you pick a flavor and an availability zone per load balancer, and OVN supports neither. magnum-cluster-api has labels for the API load balancer's flavor, availability zone and floating IP. On a cloud with more than one availability zone, you can place the API load balancer in the zone you choose.
If you are still deciding whether Octavia should front your Services at all, our comparison of load balancers as a service and installable load balancers covers that step.
Amphora or OVN: choosing an OpenStack load balancer per cluster
Choose OVN when your Services use TCP or UDP, terminate TLS inside Kubernetes, work with source IP and port hashing, and use members of a single IP family. It suits clusters with many LoadBalancer Services, where an instance per load balancer adds up. You give up client filtering by CIDR at the load balancer, and health checks are limited to TCP and UDP-CONNECT.
Choose amphora when the load balancer has to hold certificates, route on HTTP, insert X-Forwarded-For, balance by round robin or least connections, filter by source CIDR, probe an HTTP path, or sit in a chosen availability zone. Check which of these your cloud controller manager exposes to a Service before you rely on them. On amphora, confirm your Octavia patch level for OSSA-2026-039 first.
Two changes would reopen the decision. If magnum-cluster-api separates the API and Service providers (#527), one cluster could keep its API load balancer on amphora and move Services to OVN. If the OVN provider gains layer 7 or more algorithms, it covers more Services. Until then, list the load balancer features your Services use today, and choose the provider that covers all of them.
The advisory leaves every team on amphora with two jobs. The first applies to all of them: confirm that your Octavia build includes both of the advisory's fixes. The second is a decision per cluster. Where every Service fits OVN's TCP and UDP limits, OVN removes the amphora VMs and puts the cluster outside OSSA-2026-039. Where even one Service needs certificates, HTTP routing or CIDR filtering at the load balancer, the cluster stays on amphora, patched. Once each cluster sits in one of those two groups, you are done with this advisory.
