Network Nano-Segmentation for Container Security
Network segmentation is not a new concept in security. It’s been around for a while and is considered one of the most effective methods of limiting the “blast radius”, i.e., preventing extensive damage in case of an attack or a breach by limiting the attacker to a sealed-off segment of the network. In the era of APTs and socially-engineered attacks, many organizations work under the assumption that their network has been penetrated to some degree, and segmentation is there not to prevent attacks but to limit their damage.When physical, static-IP networks were all we had, segmenting them was relatively easy.
Then VMs came along, and everything became dynamic, and software-defined and a lot more complicated, giving rise to micro-segmentation. The big difference was that now you had to be aware of which VMs are running the application in order to provide adaptable segmentation.
Along Came Containers
Containers completely change networking once again. There are several significant differences:
- Containers can connect to each other inside the same host machine, making their communication invisible to traditional firewalls and networking tools.
- Containers can also connect across hosts, but looking from outside it will look as if the hosts are communicating and not the containers inside them - which limits the ability to understand and control traffic at a granular level.
- Containers might also need to communicate with other machines that are not containers, for example persistent storage, or databases, again requiring container-level granularity.
So how do you decide what are the legitimate network connections that a container should have? Ultimately, the application context is what should determine it. In the world of containers, orchestrators often define the application boundaries, e.g., Kubernetes pods.
Our Approach: Automated Nano-Segmentation
Aqua creates nano-segments automatically based on container metadata and activity. Each container invoked by an orchestrator is automatically assigned to a logical service.
To define a nano-segment Aqua simply monitors the network activities of the service in a runtime environment - this could be a testing, staging, or product environment. This monitoring identifies all the inbound and outbound network connections of the containers within the service, including to/from other containers, services, IP addresses and public Internet access.
Watch this brief demo to see it in action:
Once Aqua concludes that the network topology has been identified, with no new connections being formed, it automatically creates a security policy that captures all of those interactions, essentially whitelisting them as legitimate connections. This policy will follow the service where it goes, regardless of physical location, orchestration tools, or network overlays.
With nano-segmentation in place, containers will be prevented from accessing resources outside their respective nano-segments, and such attempts will also generate alerts and audit events.