Aqua Security has a surprisingly simple approach to securing your cloud-native applications on Azure Kubernetes Service (AKS), despite its complex capabilities.
Let’s see it in action. Imagine you’ve got a standard web application running on AKS, something like a Node.js app exposed via a LoadBalancer service.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-web-app
spec:
replicas: 3
selector:
matchLabels:
app: my-web-app
template:
metadata:
labels:
app: my-web-app
spec:
containers:
- name: web
image: nginx:latest # Replace with your actual application image
ports:
- containerPort: 80
apiVersion: v1
kind: Service
metadata:
name: my-web-app-service
spec:
selector:
app: my-web-app
ports:
- protocol: TCP
port: 80
targetPort: 80
type: LoadBalancer
Now, you want to secure this. Aqua integrates by deploying its own components into your AKS cluster. The core of this is the aqua-admission-controller, which intercepts Kubernetes API requests. When you try to deploy a new pod or update an existing one, this controller checks if the image meets your defined security policies. If not, it blocks the deployment. This is done before the pod ever gets a chance to run.
The "enforcer" is another key piece. It runs as a DaemonSet on your AKS nodes, ensuring that even if a pod somehow bypasses the admission controller (which is rare), the enforcer can detect and stop unauthorized or vulnerable containers from executing. It also handles runtime security policies, like network segmentation or file integrity monitoring.
The mental model to build here is one of preventative enforcement. Aqua isn’t just scanning images after they’re built; it’s actively preventing vulnerable or non-compliant images from ever running in your cluster. The admission controller acts as the gatekeeper at the Kubernetes API level, and the enforcer acts as the security guard on each node.
Here’s how you’d typically configure Aqua on AKS. You’d start by installing the Aqua Security Platform, which can be self-hosted or consumed as a SaaS offering. Then, you’d deploy the Aqua Security Agent to your AKS cluster. This agent includes the admission controller and the enforcers.
The configuration happens within the Aqua Security Platform itself. You define image scanning policies, vulnerability thresholds, compliance checks (like CIS benchmarks), and runtime security policies. For example, you might set a policy that blocks any image with a critical vulnerability from being deployed.
# Example of a minimal Aqua Security policy configuration (conceptual)
apiVersion: aqua.security/v1alpha1
kind: ImagePolicy
metadata:
name: block-critical-vulns
spec:
rules:
- action: deny
conditions:
- image:
vulnerability:
severity: critical
Once these policies are defined in Aqua, the agent in your AKS cluster pulls them and enforces them. The admission controller, registered with the Kubernetes API server, will then check every Pod creation or update against these policies.
A crucial, and often misunderstood, aspect is how Aqua uses Kubernetes RBAC and Service Accounts. The Aqua agent deploys with a specific Service Account that has the necessary permissions to interact with the Kubernetes API server (to register the admission controller, for instance) and to monitor pods and nodes. However, Aqua is designed with a principle of least privilege. The enforcers, for example, don’t need cluster-admin rights; they operate within the context of the nodes they are running on and the pods they are tasked with monitoring. Misconfigurations here can lead to the admission controller not being registered or the enforcers not being able to perform their duties, often manifesting as deployment failures without clear Aqua-specific error messages.
The next challenge you’ll likely encounter is fine-tuning runtime security policies to avoid false positives.