Aqua Security’s deployment on EKS involves several moving parts, but the core idea is to run Aqua’s security components as Kubernetes workloads.
Let’s see Aqua in action. Imagine you’ve just deployed a new container image to your EKS cluster. Aqua’s agents, running alongside your applications, will automatically scan this image for vulnerabilities and misconfigurations. If a critical vulnerability is found in, say, a common library like openssl, Aqua will flag it.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: your-dockerhub-username/vulnerable-app:latest # Example image
ports:
- containerPort: 8080
This Deployment resource tells Kubernetes to run three replicas of your application. Aqua’s Node Scanner (running as a DaemonSet on each EKS node) will inspect the actual image layers pulled onto that node. Its Image Scanner (often run as a separate Deployment or integrated into CI/CD) performs deeper analysis.
The problem Aqua solves is the blind spot in cloud-native security: you can’t secure what you can’t see. Traditional security tools are often network-centric or host-centric, failing to understand the ephemeral, distributed nature of containers. Aqua provides visibility and control across the entire container lifecycle, from build to runtime.
Internally, Aqua uses a combination of agents and controllers. The Gateway (often deployed as a LoadBalancer service) acts as the central communication hub. Enforcers (running as DaemonSets or Deployments) enforce policies on nodes and pods. The Scanner components perform static analysis of images and runtime behavior. The Controller (the main Aqua Server) orchestrates these components and provides the user interface.
The exact levers you control are primarily through Aqua’s Admission Controller and Policy configurations. The Admission Controller, a Kubernetes MutatingAdmissionWebhook, intercepts resource creation requests. You can configure it to block deployments of images with critical vulnerabilities, or to inject Aqua’s Runtime Enforcer sidecar into compliant pods. Policies define what constitutes a "compliant" deployment.
One thing that trips people up is the interaction between Aqua’s network segmentation policies and Kubernetes network policies. While both can control traffic, Aqua’s Network Segmentation feature operates at a lower level, often inspecting L3/L4 traffic directly via its Enforcers, and can provide finer-grained control than standard Kubernetes NetworkPolicies, especially when dealing with inter-node communication or traffic that bypasses kube-proxy. Understanding when to use one versus the other, or how they can complement each other, is key. For instance, you might use Kubernetes NetworkPolicies for broad namespace-level isolation and Aqua’s segmentation for specific application-to-application communication rules within those namespaces.
The next concept you’ll grapple with is integrating Aqua’s runtime security features with your EKS cluster’s logging and monitoring infrastructure.