Containerized applications raise new, complex security challenges. One of the primary security tools that have evolved to address these challenges are specialized firewalls for container infrastructure.
Container firewalls are a type of firewall that secures both the internal and external traffic of containerized applications. By regulating and isolating network traffic to and from containers, this type of firewall can mitigate lateral movement of threats, reduce the risk of container compromise, and in general reduce the potential attack surface.
This is part of a series of articles about container security.
In this article:
This feature allows the firewall to inspect all incoming and outgoing network traffic based on predetermined security rules. By doing so, it can identify and block any potentially harmful data packets. It’s like having a security guard at the door of each container, ensuring only legitimate traffic is allowed to pass through.
Network segmentation isolates each container’s network traffic, reducing the risk of lateral movement of threats across containers. This allows a container firewall to contain any potential threats, preventing them from spreading to other parts of the network.
Allowlists and denylists allow administrators to explicitly define which network traffic is allowed and which is blocked. This provides an additional layer of control over network traffic. In general, allowlists are preferred for security purposes, because they ensure that only “known good” traffic enters or exits a container while all other traffic is blocked.
Deep Packet Inspection (DPI) allows the firewall to inspect the content of each data packet in detail, looking for any signs of malicious activity. DPI makes it possible to set filters that can block or reroute traffic from specific IP address ranges, detect known attack patterns, and intercept malware distributed via network packets.
Container firewalls are typically integrated with threat intelligence feeds. This feature helps the firewall stay up-to-date with the latest known threats and vulnerabilities, allowing it to detect and respond to them. Some firewalls can automatically update their rules, in accordance with threat intelligence data, to block new attack patterns as they are discovered.
Anomaly detection capabilities allow the firewall to monitor the behavior of each container and detect unusual activity. By learning the normal behavior of each container, the firewall can identify any deviations from this norm, which could potentially indicate a security threat. This can help a container firewall identify and block new and unknown attack patterns.
A container firewall is specifically designed to protect containerized applications. This means that it is highly specialized and can be very effective for the specific purpose it was designed for.
An NGFW has a broader scope. It is designed to protect an entire network and provides a wide range of functionalities including intrusion prevention, application control, and user identity management.
A container firewall is designed to integrate with container engines like Docker and container orchestration tools such as Kubernetes or OpenShift. The architecture of a container firewall is usually more lightweight compared to NGFW.
NGFW is typically a standalone device that is integrated into the network architecture. It provides a more traditional firewall solution with added functionalities for application control, intrusion prevention, and user identity management.
A container firewall provides highly granular control over the network traffic entering and leaving the container. This means that it can be configured to block or allow specific types of traffic based on various parameters such as source IP address, destination IP address, protocol, and port number.
NGFW provides less granular control over network traffic. In particular, NGFW may not have visibility over network traffic between containers. It is typically used to control traffic flowing into and out of a network or subnet.
A container firewall is highly flexible, as it can be easily deployed and configured to protect any number of containerized applications. Its lightweight architecture allows it to be easily scaled up or down based on the needs of the application it is protecting.
An NGFW is less flexible and scalable. While it can be configured to protect a wide range of applications and network assets, its standalone architecture makes it more difficult to scale up or down. It may also require more resources and time to deploy and configure, making it less suitable for rapidly changing environments.
Related content: Read our guide to container security tools
The Principle of Least Privilege (POLP) dictates that a user, system, or process should have the bare minimum privileges necessary to perform its function, and nothing more. This principle applies equally to the configuration of a container firewall.
By only allowing the necessary network connections, we can reduce the potential attack surface. This means limiting inbound and outbound connections to only those that are strictly necessary. This can be a complex task, particularly in microservices architectures where there can be many interconnections between containers.
When it comes to configuring your container firewall, it’s generally better to use allowlists rather than denylists. An allowlist is a list of entities that are allowed access, while a denylist is a list of entities that are denied access.
The problem with denylists is that they require you to know and specify all possible threats, which is practically impossible. On the other hand, an allowlist only needs to specify the known and trusted entities, which is a far more manageable task.
By using an allowlist, you create a default-deny posture. This means that everything is denied by default and only the entities on the allowlist are allowed. This is a more secure approach and aligns with the Principle of Least Privilege discussed earlier.
By integrating your firewall configuration into your CI/CD pipelines, you can ensure continuous security throughout the development and deployment process.
In a CI/CD pipeline, every code commit triggers a series of automated tests and builds. By including your firewall configuration in these processes, you can ensure that your security policies are enforced every time new containers are deployed.
This approach can catch potential security issues early in the development cycle, making them easier and cheaper to fix. It can also help maintain consistency across different environments, reducing the risk of configuration drift.
You should continuously observe the operation of your firewall to detect any anomalies or suspicious activity. This can help you identify potential attacks or breaches in real time, allowing you to respond by updating the firewall rules. This might be important to adapt to new security requirements, or to respond to user issues like blocked access to important destinations.
Auditing, on the other hand, involves reviewing your firewall configuration and log files to ensure compliance with your security policies. This can help you identify any misconfigurations or gaps in your security posture.
Learn more in our detailed guide to container security best practices
Calico Container Firewall improves the network security posture of containerized workloads across multi-cluster, hybrid and multi-cloud environments. The firewall platform provides deep visibility and granular security controls, workload-based intrusion detection, and prevention deployed as code.
Next steps:
Get updates on blog posts, workshops, certification programs, new releases, and more!
