Aqua Security’s deployment on OpenShift is a multi-component affair that often trips up newcomers due to the intricate interplay between Aqua’s microservices and OpenShift’s Kubernetes-native abstractions.
Let’s see Aqua Security in action, securing a sample application deployed on OpenShift.
Imagine we have a simple Nginx deployment running in OpenShift:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-app
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
And a corresponding Service:
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
Once Aqua Security is deployed (we’ll cover that next), it will automatically scan this nginx:latest image. If the image has known vulnerabilities, Aqua will flag them. Furthermore, Aqua can enforce policies, preventing pods with vulnerable images from even starting.
The core of Aqua Security’s runtime protection on OpenShift relies on its audit-container and admission-controller components. The audit-container is typically deployed as a DaemonSet, running on each OpenShift node. Its job is to hook into the container runtime (like CRI-O in OpenShift) and monitor container activity, reporting suspicious behavior back to the Aqua Security console. The admission-controller, on the other hand, is a Kubernetes Admission Controller that intercepts API requests to the OpenShift API server. It checks if new pods or deployments comply with Aqua’s defined security policies before they are allowed to run. This is crucial for preventing vulnerable or non-compliant workloads from being deployed in the first place.
To deploy Aqua Security on OpenShift, you’ll typically use their Helm chart or Operator. The deployment involves several key components:
- Aqua Security Console: The central management UI and API. This can be deployed as a stateful application, requiring persistent storage.
- Aqua Security Database: Usually a PostgreSQL instance, also requiring persistent storage.
- Aqua Security Gateway: This is the component that interacts with your OpenShift cluster. It’s deployed as a Deployment in the
aqua-systemnamespace (or a namespace of your choice). The Gateway handles communication with the Aqua Console and orchestrates the deployment of other Aqua components within the cluster. - Aqua Security Audit Container: Deployed as a DaemonSet. This is the runtime security agent that runs on every node.
- Aqua Security Admission Controller: Deployed as a Deployment and registered as a Validating and Mutating Admission Webhook with the OpenShift API server.
The most surprising true thing about Aqua Security’s integration with OpenShift is how it leverages the Kubernetes Admission Controller mechanism to enforce policies at the API level, effectively acting as a gatekeeper for your cluster’s workloads. This isn’t just about scanning images; it’s about actively preventing bad things from happening before they even start.
The Aqua Gateway, when deployed, registers itself as an admission webhook. OpenShift’s API server, upon receiving a request to create a Pod or Deployment, will forward this request to the Aqua Gateway. The Gateway then checks the request against Aqua’s policies. For example, if a policy dictates that no pods can run with an image containing critical vulnerabilities, and the requested image has such a vulnerability, the Gateway will reject the API request. This rejection is then communicated back to the OpenShift API server, which in turn informs the user that the deployment failed due to a policy violation. This dynamic enforcement is a powerful aspect of Aqua’s security posture.
When configuring the Aqua Gateway’s admission controller, you’ll need to ensure the admission-controller.enabled flag is set to true in your Helm values or Operator configuration. Crucially, the aqua-gateway.gateway.service.port needs to be exposed, and the admission-controller.service.port (typically 8443) must be reachable by the OpenShift API server. The webhook configuration itself, which is automatically created by Aqua, will specify the CA bundle to trust the webhook’s TLS certificate and the endpoint for the webhook.
A common point of confusion is the audit-container DaemonSet. This component needs to be able to communicate with the container runtime on each node. In OpenShift, this usually means ensuring that the necessary host network access or specific CNI configurations are in place to allow the audit-container pods to monitor container events effectively. If the audit containers cannot start or report, runtime security features will be unavailable.
The Aqua Security console provides a comprehensive dashboard where you can view scanned images, runtime threats, and policy compliance. You can define granular policies based on image vulnerabilities, malware, runtime behavior, and even Kubernetes configurations. For instance, you can create a policy that prevents any container from running as root (runAsRoot: false) or that requires specific network policies to be in place.
One aspect that often surprises people is the role of the audit-container in detecting runtime threats. It doesn’t just look at the image; it monitors the actual processes running inside the container. If a container that was deployed with a clean image starts behaving maliciously – for example, trying to access sensitive files it shouldn’t, or initiating network connections to known bad IPs – the audit-container will detect this anomalous behavior and report it to the Aqua console. This layered approach, combining pre-deployment scanning and post-deployment runtime monitoring, is what makes Aqua effective.
The next concept you’ll likely encounter is managing Aqua’s integration with CI/CD pipelines for automated image scanning and policy enforcement before deployment.