Enforce Runtime Security Policies with Aqua (2026)

Aqua Security can be configured to enforce runtime security policies, preventing unauthorized actions by containers and nodes.

Let’s see Aqua in action. Imagine we have a containerized application that absolutely must not execute shell commands directly within its environment. This is a common security requirement for production workloads.

Here’s a simplified view of a Kubernetes Deployment for our hypothetical application:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-secure-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-secure-app
  template:
    metadata:
      labels:
        app: my-secure-app
    spec:
      containers:
      - name: app-container
        image: my-vulnerable-app:latest # In a real scenario, this would be your app's image
        ports:
        - containerPort: 80

Now, let’s define a policy in Aqua Security to block any attempt to run a shell within this container. Aqua’s policy engine allows us to specify granular rules. We’ll create a "Runtime Policy" that includes a "File & Process" rule.

Our rule would look something like this (this is a conceptual representation of how it’s configured in Aqua’s UI or API, not direct YAML):

Policy Name: BlockShellExecution Applies to: my-secure-app label

Rule Type: File & Process Action: Block Target:

• Process Name: sh, bash, zsh, ash, dash (and any other common shells)
• Command Line Arguments: (Optional, but could be used to be more specific, e.g., block sh -c)

When this policy is active and a pod matching my-secure-app is running, if any process tries to execute one of these shell commands, Aqua’s runtime agent will intercept and block it.

For example, if someone tries to exec into the pod and run kubectl exec -it my-secure-app-xxxxx -- bash, Aqua will prevent bash from starting. The user would see an error, and an event would be logged in Aqua Security detailing the blocked action, the pod it occurred in, and the policy that blocked it.

This isn’t just about blocking shells. You can enforce policies like:

• Network Restrictions: Prevent outbound connections to specific IP ranges or ports.
• File System Access: Block write operations to sensitive directories like /etc.
• Privileged Operations: Deny containers from running with privileged: true or accessing host devices.
• System Calls: Block specific dangerous syscalls (e.g., ptrace, syslog).
• Image Integrity: Ensure only approved images are deployed.

Aqua’s runtime security works by deploying an agent (often as a DaemonSet in Kubernetes) to each node. This agent monitors container activity at the kernel level using technologies like eBPF or auditd. When an action violates a defined policy, the agent intervenes, either by terminating the process, blocking the action, or alerting.

The core of Aqua’s runtime enforcement lies in its ability to translate high-level security requirements into low-level kernel-level interventions. It provides a unified platform to define, deploy, and monitor these policies across your entire containerized environment, from development to production. The runtime-security module is what enables this layer of defense after your containers have started, complementing image scanning and admission control.

What many operators overlook is the granularity of process name matching. While blocking sh and bash is common, you might encounter custom scripts or less common shells. Aqua’s policy engine allows for regular expression matching on process names and command-line arguments, giving you the power to block highly specific or broadly defined executable patterns. This means you can create rules that are precise enough to avoid false positives while still being robust enough to catch sophisticated evasion attempts that might use alternative shells or cleverly disguised commands.

The next challenge you’ll likely face is integrating these runtime policies into your CI/CD pipeline for automated enforcement.