Microsegmenting container networks with Aqua Security isn’t just about isolating pods; it’s about enforcing granular, identity-based security policies that shift left and integrate directly into your CI/CD pipeline.
Let’s see Aqua in action. Imagine a simple web application deployed across multiple Kubernetes pods. We want to ensure that only the frontend pods can communicate with the backend pods on a specific port, and that no other traffic is allowed.
First, we deploy Aqua’s trivy-operator for vulnerability scanning and kube-hunter for network reconnaissance (though for pure network segmentation, Aqua’s enforcer is the core component). The Aqua Enforcer runs as a DaemonSet, ensuring it’s present on every Kubernetes node.
Here’s a snippet of a Kubernetes NetworkPolicy that Aqua can manage and enforce, though Aqua’s strength is in its higher-level abstractions and integrations:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: webapp-segmentation
namespace: default
spec:
podSelector:
matchLabels:
app: frontend
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
egress:
- to:
- podSelector:
matchLabels:
app: backend
ports:
- protocol: TCP
port: 80
Aqua Security’s platform, however, doesn’t just manage Kubernetes NetworkPolicy objects. It provides a unified dashboard to define and visualize these policies. You can select pods based on labels, service accounts, or even runtime behavior, and define very specific ingress and egress rules.
When you define a policy in Aqua’s UI or via its API, it translates these high-level rules into low-level eBPF (extended Berkeley Packet Filter) programs that are dynamically loaded onto the host kernel by the Aqua Enforcer. This means the filtering happens directly at the network interface, before traffic even reaches the Kubernetes network stack. This bypasses traditional CNI (Container Network Interface) limitations and provides superior performance and isolation.
The core problem Aqua solves is the dynamic and ephemeral nature of containers. Traditional firewalls and security groups struggle to keep up with pods that are constantly being created, destroyed, and rescheduled. Aqua’s identity-based approach, where policies are tied to the identity of the workload (e.g., its Kubernetes labels, service account), rather than its IP address, makes it resilient to these changes.
Here’s how it works internally: The Aqua Enforcer on each node monitors Kubernetes events. When a new pod starts, the Enforcer queries the Aqua Security platform for relevant policies. It then compiles and loads the necessary eBPF programs to enforce those policies for that specific pod. If a pod is terminated, the eBPF program is automatically unloaded.
When you define a policy in Aqua, say, "Allow frontend pods to talk to backend pods on port 8080," Aqua translates this into specific eBPF rules. For ingress to a backend pod, it might look like this: "If the packet’s source IP and port map to a pod with label app: frontend and the destination port is 8080, allow. Otherwise, drop." For egress from a frontend pod, it’s similar: "If the packet’s destination IP and port map to a pod with label app: backend and the destination port is 80, allow. Otherwise, drop." The actual eBPF code is highly optimized and operates at the kernel level.
The most surprising thing most people don’t realize is that Aqua’s eBPF enforcement can operate completely independently of the Kubernetes CNI. While it integrates deeply with Kubernetes, the actual network filtering is done by the Enforcer on the host, making it agnostic to the underlying CNI (Calico, Flannel, Cilium, etc.). This means you can achieve microsegmentation even in environments where your CNI might not support advanced network policies or where you have mixed CNIs.
The next concept you’ll likely explore is how Aqua integrates runtime threat detection with these network policies, allowing you to dynamically block traffic from a pod that exhibits malicious behavior.