StarlingX cranks open-source cloud network infrastructure to 11.
The open-source StarlingX cloud infrastructure project is out with its second major update of 2025, bringing with it new edge security and usability improvements.
StarlingX is part of the Open Infrastructure Foundation, which this year became part of the Linux Foundation. The StarlingX 11.0 release builds on the 10.0 update that came out in February. StarlingX is an open-source cloud infrastructure platform that combines the Linux kernel, Kubernetes and OpenStack for edge computing deployments. Verizon, Vodafone, T-Systems and KDDI are among the big operators that use StarlingX in production for 5G and O-RAN infrastructure.
Key features in StarlingX 11.0 include:
- IPsec pod-to-pod encryption: Inter-host pod communications are protected using IPsec in tunnel mode with per-service policy controls.
- Platform network address optimization: Subclouds now require only a single IP address instead of multiple addresses for management and cluster-host interfaces.
- Enhanced access control roles: New roles provide more granular access control.
- Extended rollback support: More options for easier rollbacks across configurations.
“Security at the edge is difficult, as there is really no physical security that can be assumed,” Greg Waines, a StarlingX Technical Steering Committee member, told Network World. “This means there is no such thing as internal networks where you can run unprotected traffic. All traffic, both internal and external, must be protected against attacks from different levels of attackers.”
IPsec encryption protects pod traffic
StarlingX 11.0 uses IPsec in tunnel mode to encrypt inter-host pod-to-pod communication over the cluster host network. A new Kubernetes system application called ipsec-policy-operator manages the configurations through IPsec policies.
Operators can protect specific application traffic on a per-service basis rather than encrypting all traffic. SR-IOV virtual function interface traffic is excluded to avoid IPsec overhead.
“We are seeing increasing concern over security at the edge, where physical security is nowhere near as good as in a central office environment,” Waines said. “We are especially seeing this concern from StarlingX users in Europe.”
Third-party security testing now assumes physical access to equipment. “It is standard for them to do tests where they have physical access to the equipment and can access used or unused switch ports to passively or actively access servers from inside the remote edge deployment,” Waines explained.
The release also adds “configurator” and “operator” access control roles to the existing admin role. Combined with the Harbor container registry security features from StarlingX 10.0, these changes address security requirements where physical access cannot be guaranteed.
IPv4 address optimization enables massive edge deployments
Following up on the dual-stack IPv4/IPv6 support introduced in 10.0, the 11.0 release includes platform network address reduction for subclouds.
The new feature requires only a single IP address per subcloud instead of multiple unit-specific addresses. The previous architecture allocated separate addresses for operations, administration and management (OAM) as well as Kubernetes cluster-host interfaces.
Platform network addresses are now assigned from a shared subnet in both IPv4 and IPv6 environments. Multiple subclouds can use the same network address range. The single-IP architecture works with the dual-stack networking capabilities from StarlingX 10.0, giving operators flexibility in their IPv4-to-IPv6 migration strategies. For operators with available IPv6 address space, the dual-stack support provides a migration path while maintaining IPv4 compatibility. The reduced IPv4 requirements in StarlingX 11.0 extend the viability of IPv4-only deployments where IPv6 adoption faces organizational or equipment limitations.
While the overall market direction is moving to IPv6, the reality is that many operators still rely on IPv4 due to existing infrastructure constraints.
“This feature was primarily implemented for users of StarlingX that are still using IPv4 addressing with smaller address spaces for their infrastructure,” Waines said.
Some of those IPv4 users have a large scale where the address optimization will have real impact for operations.
“Operators are deploying StarlingX on a large scale, which, for later releases of the platform, means up to 5,000 AIO-SX subclouds in a single data center deployment,” Waines explained. “On that scale even small reductions in the number of required IP addresses per subcloud makes a big difference.”
Unified software management framework continues to evolve
Ease of updates is another area where StarlingX is looking to help cloud operators.
Ildikó Váncsa, director of community at the Open Infrastructure Foundation, explained that the StarlingX community introduced the Unified Software Management (USM) framework in the 10.0 release to provide one interface and a unified set of commands for users to perform updates and upgrades throughout a deployed system. She noted that contributors keep optimizing the framework along with making it more feature rich.
“As networks keep going through a digital transformation and starting to follow cloud-native principles, it is becoming increasingly important to be able to roll out upgrades and keep up with newer versions of the system’s building blocks,” Váncsa told Network World. “By enhancing USM, the StarlingX platform is targeted to address this emerging need.”
