Is your Kubernetes network security strategy solid?

Following a security incident is the worst time to realize that your Kubernetes protections weren’t good enough. When comprehensive Kubernetes security measures are in place, potential threats are detected and remediated before they can hurt. Achieving this level of security requires a targeted strategy, calibrated to your unique Kubernetes environment and risk profile. It also requires knowing what questions to ask when building your container network security strategy.

There’s no watering it down: In the rush to modernize application deployment with Kubernetes, security continues to play a secondary role in ensuring the speed of development for many organizations. Look no further than what 1,200 development and DevOps professionals reported at the last KubeCon event. But safety and speed can’t be either, and they don’t need to be. Here are four critical questions that need to be asked to understand where vulnerabilities persist and where steps need to be taken to provide adequate protection within your container network.

Does inspecting your network provide complete visibility?

Complete traffic visibility at all The network layer is arguably the most crucial requirement for effective runtime container security. While something like a service mesh will provide observability of defined network activity, service meshes provide little information about anomalous network traffic most likely to represent nefarious activity or kill chains used by the escalation of threats.

A security strategy that includes Layer 7 network inspection provides a key benefit. By understanding how each specific application service communicates with others, you can get a clear differentiation between normal and abnormal traffic. Having complete visibility into network traffic then helps identify and stop attacks before they can infiltrate applications or workloads. Data breaches are also prevented since any anomalous network traffic from compromised applications is recognized and mitigated.

What is not protected by your security deployment or service mesh?

To avoid vulnerabilities, you must find and address the blind spots of your Kubernetes protections. If observability is only available for defined network elements, full security will require extending network visibility to view undefined elements as well. For example, if the load on particular services connecting to sensitive data increases for no discernible reason, greater visibility is essential to understand this event. An attacker or insider threat with a working password may gain access to the infrastructure without performing otherwise identifiable attack activities. Kubernetes backups must be able to observe undefined/unknown and detect anomalies within ostensibly legitimate activity. Specifically, communication within a pod and pod-to-pod communications in the Kubernetes network must be protected in scenarios where pod containers are compromised.

What are the firewall protection limits of your existing web application?

Web Application Firewalls (WAFs) protect against threats from external network traffic. However, they have no way of identifying or blocking malicious internal traffic within the container environment. Preventing attacks that escalate from internal traffic requires a container-specific firewall policy to monitor and inspect all container traffic in an application-aware context and automatically recognize and eliminate threats in real time.

Are you addressing the safety drift?

Some shortcomings are not apparent until a strategy is tested. As your environment evolves and increases the use of containers and microservices, security creep occurs and naturally introduces vulnerabilities. For example: an organization required to maintain PCI compliance may find that its legacy Data Loss Prevention (DLP) solution, which has always passed audits in the past, is no longer effective in the new enterprise container. and in the Kubernetes context.

Even in cases where you can identify safety drift, the ability to to prevent safety drift in the first place is much more beneficial. As is most often the case, Kubernetes’ proactive security protections are preferable to merely reactive processes. It means the difference between identifying new vulnerabilities after active threats have exploited them and recognizing abnormal network activity to prevent exploits of even unknown vulnerabilities.

How fast can your Kubernetes security mitigate threats?

If an attack were to happen, when would you know? How quickly would your existing security processes respond? If your organization’s response isn’t satisfactory, it’s probably time to revisit your approach. The right strategy will be able to immediately, automatically and decisively protect your environment as soon as an attack demonstrates suspicious behavior, and before it can cause any harm.


To learn more about cloud native topics, join the Cloud Native Computing Foundation and cloud native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021

Kevin M. Risinger