“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.
