Security at the network edge: Inside software-defined networking and Kubernetes

Security concerns remain prominent across all network environments, with some unique to the network edge, SDN, and other services. Get some tips from industry insiders.

Curios IT Engineer Standing in the Middle of a Working Data Center Server Room. Cloud and Internet Icon Visualization in the Foreground.

Image: gorodenkoff, Getty Images/iStockphoto

Network security is a challenge that involves complexity directly proportional to that of the environment. Securing subnets, switches, routers, and firewalls is a fairly traditional field, but security gets a lot tricker with such concepts as the network edge, software-defined networking (SDN) and other newfangled services. 

SEE: Network security policy (TechRepublic Premium)

I spoke about the concepts with Tom Nadeau, technical director, NFV at Red Hat Linux, and Bassam Khan, vice president of Product and Technical Marketing Engineering at Gigamon, a network analytics provider.

Scott Matteson: What security concerns are prevalent at the network edge, inside the SDN, and among services?

Tom Nadeau: Based on our deployment experience, the greatest security concerns seem to come from how the platform is configured, how the containerized workloads are constructed and executed, as well as auditing of the platform itself. In terms of the platform configuration, we made a big push for OpenShift 4.0 to focus on operations and management enhancements. In addition to this, we have progressed The Operator Framework, which essentially standardizes how container workloads are installed, launched, operated (i.e. events handled, auto-scaling, etc.), and shut down. 

We have also done a lot of work on the Universal Base Image (UBI) which is a well-structured and nicely automated way to create a well-known, secured base for containers that can be updated and patched in the future without any operator intervention, thus automatically keeping the latest patches, including those around security, available. Finally, we are also actively creating our Container Network Function Certification program internally, which will be a means to verify and certify all of these things I just described.

Bassam Khan: As public networks are brought closer to previously "east-west" data, network edge will experience threats and risks that most likely will propagate across networks, applications and systems causing more damage to organizations if compromised. In addition, much info can be compromised if switches, routers, and servers are not properly secured. While SDN brings many benefits to networks, it poses new threats like attack surface in virtualized and cloud environments.

Scott Matteson: What are the recommended remedies to address those concerns?

SEE: VPN: Picking a provider and troubleshooting tips (free PDF) (TechRepublic)

Bassam Khan: There are many recommended security measures to protect the network edge and SDN. These consist of encrypting the data, micro-segmenting the network to support the different types of applications, tunneling and access-control methods, and much more. Lastly, complete context-aware L3-7 visibility, delivering a multi-dimensional overview of applications: visualization, identification and filtering of applications running on the network, with rich attributes/metadata extraction and analysis that examines the behavior of network, app, and user is crucial.

Scott Matteson: How is Kubernetes changing the network?

Tom Nadeau: Kubernetes has changed the landscape of not only microservices and containers, but also changed the market's perception of what can be done with a containerized platform. Other competing platforms stuck with what turned out to be an over-simplified model for networking much like the initial model Kubernetes platform went to market with. That is specifically a single, virtualized interface that is presented to a container with little if any options on how it is configured. 

Worse still, that interface employs a localized network address translation mapping as it is all ultimately mapped to a single underlying physical interface. The single interface-per-container model also artificially limits other configurations, including multicast or virtualized network functions such as virtual routers, which rely on access to multiple interfaces in order to do the function they are designed to do. 

Bassam Khan: Kubernetes plays a key role in building a resilient and scalable distributed system for applications as organizations embrace containers. Kubernetes gives each pod in networking its own IP address, this allows for pods to communicate with one another without the use of NAT. In addition, Kubernetes allows for less complex networking as it shares machines between different applications and solves various problems throughout networking. 

SEE: Kubernetes security guide (free PDF) (TechRepublic)

Scott Matteson: What are the advantages involved?

Tom Nadeau: To address these deficiencies, we've worked with the upstream communities, our partners, and customers to create new technologies that address the deficiencies just mentioned. These include Multus which adds support for connecting multiple, full-speed network interfaces to containers. We have further created virtio/vDPA to go hand-in-hand with the trend to offload network forwarding/processing operations to network interface cards (NICs), but to also simplify and unify how containers are attached to those resources in a manner that requires a single point of configuration rather than many. 

We have also made numerous SR-IOV enhancements to also assist in this new functionality. Finally, we have also included operators within the Operator Framework, addressing operational feedback we have received around complexities of configuring and operating containers, the underlying system, and the networking that connects them all together.

Bassam Khan: The main advantage with Kubernetes is that each pod carries its own IP address. This allows for easy, smooth, and secure communication between pods, pods and services, and containers. Moreover, it gives way for a clean model, as there is no need for mapping between hosts and pods, as each pod is now viewed like a VM.

Scott Matteson: How will Kubernetes evolve in the future?

Tom Nadeau: We are working hard on a variety of areas including extending the reach of vDPA by working closely with just about every NIC vendor on the planet to enable support there and upstream. We are actively enhancing Multus as well for things like IPv6 support, additional multicast functions as other scaling features. We also continue to enhance operators. We are working on some exciting new enhancements around the possibilities of so-called smart NICs: NICs that have auxiliary CPU/NPU complexes for enhanced hardware offload processing use cases. Finally, we are doing a lot in the areas of virtualized radio area networks (vRAN) and mobile edge computing (MEC) in terms of real-time processing, timing and related enhancements to support these use cases. 

Bassam Khan: Even though Kubernetes is changing the networking world it still is new and has much room to evolve in the future. One of the main challenges is the complexity in adapting this system. The network requires a redesign of the previous users' infrastructure, hence requiring money and time from the customer, which makes the system slightly undesirable. With the evolution and new growing prevalence of the system there have also been security risks. In the future, Kubernetes will need to look for an easier way to adapt the system and add better security measures.

Also see