Enterprises implementing containers and Kubernetes in either corporate datacenters or cloud environments typically employ Checkpoint Quantum to secure traffic between their datacenter networks and Checkpoint CloudGuard to safeguard their cloud resources. Often these network security perimeter focused solutions are also used to scrutinize traffic originating from Kubernetes clusters.

Firewall technology for network security has undergone considerable advancement with the introduction of cloud computing and the vanishing network perimeter with hybrid and multi-cloud environments. All along this transformation one thing that did not change is the way endpoints are identified – through the TCP/IP stack, specifically the IP address. This design principle needed a change for container-based applications. How did the NGFWs fare?

This is a follow up discussion of some advanced use case scenarios for Egress Gateways. In a previous blog post, Policy-based routing with Egress Gateways, I explained how to achieve connectivity to multiple destinations using policies based on the destination of the traffic. One of the use cases described was the ability of connecting to different services based on the destination, so we can use a different source IP that can be included in an allowlist for such services.

By default, traffic leaving a Kubernetes cluster lacks a meaningful network identity, making it challenging to associate it with its source workload. This is an issue because, in an on-premises infrastructure, companies rely on firewalls, for example Sophos Firewall, to inspect this traffic which loses its identity as soon as it leaves the cluster.

Security Information and Event Management (SIEM) is essential for enterprise organizations because it provides the tools and capabilities needed to effectively monitor, detect, respond to, and mitigate cybersecurity threats, while also supporting compliance and overall security strategy enhancement.

In this blog post I will be discussing how Egress Gateways can help in securing traffic by means of policy routing. If you are not familiar with Egress Gateways, take a look at our blog post, Using Calico egress gateway and access controls to secure traffic.

In today’s cloud-driven landscape, containerized workloads are at the heart of modern applications, driving agility, scalability, and innovation. However, as these workloads become increasingly distributed across multi-cluster, multi-cloud, and hybrid environments, the challenge of securing them grows exponentially. Traditional network security measures designed for static network boundaries are ill-suited for the dynamic nature of containerized applications.

Teams implementing the Azure Well-Architected Framework, and using the Hub and Spoke network topology often rely on the Azure Firewall to inspect traffic coming from Azure Kubernetes Service (AKS) clusters. However, they face challenges in precisely identifying the origin of that traffic as it traverses the Azure Firewall. By default, traffic leaving a Kubernetes cluster is not assigned a meaningful network identity that can be used to associate it with the application it came from.

This release, we’re really excited about major improvements to Calico’s workload-centric WAF. We’ve made it much easier for users to configure and deploy the WAF in just a few clicks and we’ve also made it much easier to review and manage WAF alerts through our new Security Events feature.