Evaluating container firewalls for Kubernetes network security

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?

The container firewall landscape

Security, platform, and DevOps teams have three choices to protect their modern cloud-native applications.

• NGFW solutions in a container form factor (Palo Alto CN-series, Juniper cSRX, Fortinet CNF etc)
• Native firewall capability from public cloud vendors (AKS network firewall, Azure firewall)
• A true Kubernetes-native distributed container firewall (Calico Enterprise, Calico Cloud)

Next-Generation FireWalls (NGFWs) as a container firewall

When NGFWs morphed into a container firewall for containerized deployments, these solutions focussed on the form factor of the firewall rather than the architecture of containerized applications. The basic architecture behind the NGFW container firewall was to bring the same traditional firewall principles to the containerized workloads rather than deploying a firewall in Kubernetes-native manner and adapt Kubernetes distributed infrastructure principles.

Fig 1: NGFW sample architecture

Take the above architecture as an example. This is a typical architecture that NGFWs use to create a ‘container firewall’. All this architecture has achieved is providing the users a firewall in a container form but not providing them with the simplicity, scalability and agility of a declarative, Kubernetes-native container firewall. The mis-alignment of the NGFW container firewall with cloud-native applications is described with some of the disadvantages below:

• An NGFW container firewall needs an integration with their existing firewall platform – hardware or virtual. This central firewall acts as the main policy engine. It makes the architecture a hybrid of centralized policy engine and a distributed container firewall. A true container firewall must be decentralized in all aspects.
• Non-declarative style of writing policies. Existing methods to write firewall rules do not scale well in containerized applications, resulting in operational inefficiency and complexity. If you have to isolate workloads for compliance needs based on a microsegmentation strategy, you will be left clueless on how to do this using the NGFW container firewall.
• Teams will either perform manual updates every time a new cluster or node is created for the same application. Unable to keep up with the dynamic nature of Kubernetes workloads, they ultimately end up putting out fires when a security breach happens.
• Architecture such as one shown above is not designed to write Kubernetes-native network policies and instead use an existing vendor-specific policy and rule style.
• Not designed for a multi-cluster environment where service discovery is crucial. Problems with this approach will manifest when scaling up and expanding to multi-cluster and multi-cloud deployments of cloud-native.
• The need to manage additional components like the Kubernetes plugin which is needed to send Kubernetes context (such as Pod IP) to the controller NGFW and manage licenses for the CN-NGFW pods.
• Licensing of the firewalls can be an arduous task.

Native firewall capability from public cloud vendors

Security is, and always will be a ‘shared responsibility’ model on the public cloud. Which is why organizations use cloud firewalls in these environments. With regular cloud instances, basic security is available with native tools such as security groups, IAM policies and so on. For EKS and AKS managed Kubernetes services, cloud firewalls started offering more controls but mostly for ingress traffic with some integration with ingress controllers.

When it comes to end-to-end workload protection including the ability to protect container workloads residing on a different cloud, on-prem or on a different cluster, the native tools are insufficient. One obvious reason is the limited visibility it has on a distributed cloud-native application. Beyond the boundaries of the public cloud, all that is available to the tool is IP addresses. We described the problem with IP-address based firewalling in the previous sections. The mis-alignment of the public cloud vendor container firewall with cloud-native applications is described with some of the disadvantages below:

• Limited visibility beyond the public cloud network. In a real-world scenario, most organizations need to communicate to non-Kubernetes applications running outside the Kubernetes cluster. In a truly distributed environment, the context of workload labels and granular pod-level IP addresses are unavailable.
• Primarily host/VM based protection and not workload-based. With that limitation, the cloud firewall cannot detect lateral movement of threats within a Kubernetes cluster nor can they restrict workload to workload communication as part of microsegmentation.
• Any kind of threat detection capabilities will only apply at the host-level giving the security team an incomplete picture of the attack. As part of mitigation and remediation, the firewall solution should be able to pinpoint to the exact pod and the namespace associated with the attack.
• Non-declarative policies – unless your container firewall can write policies based on YAML and can align with the dynamic nature of container workloads it is not scalable beyond a certain number of pods.
• Limited granular access control inside a cluster. The cloud firewalls are designed to only protect the cluster from north-south traffic. Any protection between pods within the cluster or to a pod outside the cluster but part of the same application environment becomes a challenge.

The best approach to design a container firewall

A round peg for a round hole. Trying to fit a traditional firewall architecture to work with modern cloud-native applications is setting yourself up for failure. Technically it might work on a concept level but with scale and in a production environment it will result in a huge resource drain. This is why a solution like Calico which is host-agnostic, cloud-agnostic and application-agnostic and built on the same architecture principles as the Kubernetes platform is a viable choice. To make it truly distributed for scale and granularity purposes, the firewall has to have a tight integration with the Kubernetes components.

Why Calico container firewall is architecturally superior

Calico works on the lower layers of the application workload and this combined with the fact that Calico has a pluggable data-plane model (eBPF, iptables, or Windows HNS) makes it ideal for granular controls for any data-plane. Calico is natively integrated with Kubernetes at the platform level. It helps operationalizing security controls easier compared to traditional firewalls. Any time there is a pod restart, a new pod is added to the node, Calico can instantly pick up this change and apply policies in real-time. With the pod-level context that Calico has, it is also able to carry this information to perimeter security solutions that need a stable static IP address to communicate with non-Kubernetes workloads.

The declarative policy also means that Calico’s policy rules are written the same way as other Kubernetes configuration making it easier to scale and minimize human errors through misconfigurations. The alignment of Calico with cloud-native applications for security and observability is described with few more advantages below:

• Calico is also powered with an array of threat intelligence and threat detection capabilities, all of which are designed with a cloud-native approach.
• No clunky custom plugins to translate Kubernetes data to non-Kubernetes context so that it works in a custom firewall operating system (PanOS, JunOS, FortiOS etc).
• A Kubernetes-native policy model which has been leveraged to create policy tiers and policy recommendations for newer and cross-functional teams.
• This makes the entire experience of deploying the Calico container firewall as a plug-and-play solution.

Fig 2: Calico container firewall architecture

Comparison highlights

Conclusion

This article is primarily an architecture analysis of the container firewall solution landscape. In the next part, we will look at basic installation and deployment options. In the meantime, you can get started on our self-paced workshops for free.

Ready to get started? Try Calico Cloud for free.