Written by Anthony Webb, EMEA Vice President at A10 Networks
Four out of five enterprises are now running containers, and 83% are running them in production. Given that only 67% were doing so in 2017, it’s clear that containers are more than a fad.
With containers’ newfound popularity, some companies are struggling to establish an efficient traffic flow and effectively implement security policies within Kubernetes, one of the most popular container-orchestration platforms.
As a container orchestrator and cluster manager, Kubernetes focuses on providing fantastic infrastructure, and has been adopted by countless companies as a result. Companies that use a microservices architecture (MSA) for developing applications, tend to find that Kubernetes offers a number of advantages when it comes time to deploy those applications.
For all those reasons, it’s essential that organisations understand the unique traffic flow and security requirements that Kubernetes entails.
What Is Kubernetes?
Kubernetes is an open-source container-orchestration system. It’s a portable and extensible program for managing containerised workloads and services and provides a container-centric management environment.
Kubernetes has one master node and two worker nodes. The master node functions by telling the worker nodes what to do, and the worker nodes function to carry out the instructions provided to them. Additional Kubernetes worker nodes can be added to scale out the infrastructure.
Another primary function of Kubernetes is to package up information into what are known as “pods,” multiples of which can run inside the same node. This way, if an application consists of several containers, those containers can be grouped into one pod that starts and stops as one.
Challenges in Kubernetes Environment
Like all other container-orchestration systems, Kubernetes comes with its own set of obstacles.
The networking of Kubernetes is unconventional in that, despite the use of an overlay network, the internal and external networks are distinct from one another.
Plus, Kubernetes intentionally isolates malfunctioning or failing nodes or pods in order to keep them from bringing down the entire application. This can result in frequently changing IP addresses between nodes. Services that rely on knowing a pod or container’s IP address then have to figure out what the new IP addresses are.
When it comes to access control between microservices, it’s important for companies to realise that traffic flowing between Kubernetes nodes are also capable of flowing to an external physical box or VM. This can both eat up resources and weaken security.
Kubernetes and Cloud Security Requirements
There are many requirements of Kubernetes and cloud security:
- Advanced Application Delivery Controller
Companies already use advanced Application Delivery Controller for other areas of their infrastructure, it’s necessary to deploy one for Kubernetes as well. This allows administrators to do more advanced load balancing than what’s available with Kubernetes by default.
Kubernetes is equipped with a network proxy called kube-proxy. It’s designed to provide simple usage and works by adjusting iptables rules in Layer Three. However, it’s very basic and is different than what most enterprises are used to.
Many people will place an ADC or load balancer above their cloud. This provides the ability to create a virtual IP that’s static and available to everyone and configure everything dynamically.
As pods and containers start up, the ADCs can be dynamically configured to provide access to the new application, while implementing network security policies and, enforcing business data rules. This is usually accomplished through the use of an “Ingress controller” that sees the new pods and containers start up, and either configures an ADC to provide access to the new application or informs another “Kubernetes controller” node about the change.
- Keep the Load Balancer Configuration in Sync With the Infrastructure
Since everything can be constantly shifting within the Kubernetes cloud, there is no practical way for the box that’s sitting above it to keep track of everything. Unless, however, you have something like the purple box, generally referred to as an Ingress controller. When a container starts or stops, that creates an event within Kubernetes. The Ingress controller identifies that event and responds to it accordingly.
This takes a great burden off of administrators and is significantly more efficient than manual management.
- Security for North-South Traffic
North-south and east-west are both general terms to describe the direction of traffic flow. In the case of north-south traffic, traffic is flowing in and out of the Kubernetes cloud.
As mentioned before, companies need traffic management above the Kubernetes cloud to watch and catch malicious traffic.
If there’s traffic that needs to go to specific places, this is the ideal place to do that. If enterprises can automate this kind of functionality with a unified solution, they can achieve simplified operations, better application performance, point-of-control, back-end changes without front-end disruption and automated security policies.
- Central Controller for Large Deployments
Scaling out is something else that enterprises need to take into account, especially in terms of security.
The Ingress controller is still there, but this time it’s handling multiple Kubernetes nodes and is observing the entire Kubernetes cluster. Above the Ingress controller would be the A10 Networks Harmony Controller. Such a controller allows for efficient load distribution and can quickly send information to the appropriate location.
With a central controller like this, it’s imperative to choose one that can handle scaling in and scaling out with little to no additional configuration on existing solutions.
- Access Control Between Microservices
East-west traffic flows between Kubernetes nodes. When traffic flows between Kubernetes nodes, this traffic can be sent over physical networks, virtual or overlay networks, or both. Keeping tabs on how traffic flows from one pod or container to another can become quite complex without some way of monitoring those east-west traffic flows.
Plus, it can also present a serious security risk: attackers who gain access to one container can gain access to the entire internal network.
Luckily, companies can implement something called a “service mesh” like the A10 Secure Service Mesh. This can secure east-west traffic by acting as a proxy between containers to implement security rules, and is also able to help with scaling, load balancing and service monitoring.
With this type of solution, companies like financial institutions can easily keep information where it should be without compromising security.
- Encryption for East-West Traffic
Without proper encryption, unencrypted information can flow from one physical Kubernetes node to another. This presents a serious problem, especially for enterprises that handle particularly sensitive information.
When evaluating a cloud security product, it’s important for enterprises to select one that encrypts traffic when it leaves a node and unencrypts it when it enters.
- Application Traffic Analytics
Lastly, it’s of vital importance that enterprises understand the details of traffic at the application layer.
With controllers in place to monitor both directions of traffic, there are already two ideal points to collect traffic information.
Doing so can aid in both application optimisation and security and allows for several different functions. Organised from the simplest to the most advanced, those functions can allow for:
- Performance monitoring via descriptive analytics. Most vendors provide this.
- Faster troubleshooting via diagnostic analytics. A smaller number of vendors provide this.
- Insights via predictive analytics generated by machine learning systems. Even fewer vendors provide this.
- Adaptive controls via prescriptive analytics generated by truly intuitive AI. Only the best and most advanced vendors provide this.
So, when companies are talking to vendors, it’s essential that they determine which of those benefits their products can offer.
Additional Considerations for Dev and Ops Simplicity
Companies should be looking for a simple architecture with a unified solution, central management and control for easy analytics and troubleshooting, common configuration formats, no change in application code or configuration to implement security and gather analytic information and automated application of security policies. If companies prioritise those items, enterprises can enjoy streamlined, automated and secure traffic flow within Kubernetes.
