Container behavior control: where Aqua Security breaks
An image is built from a trusted source, signed, and has passed a vulnerability scan — and yet a foreign process still ends up inside the container in production. Most often it is a shell launched through debug access, or an external binary pulled in already at runtime. Build-time scanners stay silent: the image file system has not changed by a single byte.
The reason is that build-time checks answer the question “what is in the image,” not “what is happening in it.” Runtime container protection is a separate layer: monitoring the actual behavior of the container in production.
An anomaly is almost always visible not in files but in system calls — an unexpected process launch, access to sensitive paths, an attempt to open a network port outward.
Aqua Security covers this area as follows: for each image, a profile of allowed behavior is built, and any deviation — a new executable, privilege inheritance, writing to system directories — is recorded and stopped according to a defined policy.
Setup comes down to ensuring that anomaly detection in the container triggers not after the fact in a report, but at the moment of the incident in the working environment.
Next we break down how this works: control of processes inside the image, reaction modes to triggers, and the procedure for handling false signals.
What behavior control provides in a production cluster
Behavior control in a production cluster is not another image scanner, but a continuous comparison of the container's actual actions with a baseline profile.
As long as the workload behaves predictably, it runs; as soon as a shell appears inside, a file is accessed that is atypical, or an outbound request is made to a destination that is not allowed, the policy triggers, and the process is stopped before it can cause harm.
This is exactly what image scanning does not see: it evaluates content before launch, not what happens afterward.
In Aqua Security, such rules are described as behavior profiles — separately for each workload, with an observation mode during the learning period so that legitimate operations are not blocked.
Incident response time is reduced from hours to minutes thanks to ready context: which process, from which image, on which node, and what preceded it.
Some triggers are closed automatically by policy, leaving the on-call engineer to investigate isolated cases rather than manually trawling logs across all containers.
Observability becomes end-to-end: a single event log across all workloads shows after which update the behavior changed and allows it to be correlated with a specific release. A whole class of failures disappears — execution of foreign code inside an already running container.
Updates become more predictable: divergence from the baseline profile is visible before rollout, not after an outage.
Behavior control modes: alerting, blocking, isolating
The modes differ not in the depth of checks, but in the consequence of a trigger: alerting records a deviation, blocking prevents the process from performing a prohibited action, and isolating removes the container from operation.
Therefore, choosing a mode is primarily a choice between the risk of downtime and the risk of compromise.
| Mode | When it fits | Limitations |
|---|---|---|
| Alerting | The first weeks after enabling behavior control, while the procedure is not yet refined, and for workloads with frequent legitimate anomalies | Prevents nothing: triggers are visible in events, but the attack continues. Requires constant triage of the alert stream, otherwise noise grows and people stop reading it |
| Blocking | For services with a stable behavior profile, where the cost of a false stop is lower than the cost of an incident | A false trigger stops a specific operation, so exception rules and a clear triage procedure are mandatory — who and by what criterion clears a trigger |
| Isolating | For critical segments where compromise of a single container is unacceptable | The container loses network and some operations, and traffic switches to standby instances. Requires mature readiness checks and autoscaling, otherwise isolation turns into availability below the norm |
Workloads are moved between modes in stages: first alerting and profile collection, then blocking on verified services, and isolation only where rollback has been practiced.
Exception rules in Aqua Security are managed as code, tied to the image version, and reviewed with every release — otherwise, after a service update, blocking mode will start stopping normal processes.
Implementing Aqua Security: audit, staging, profiles, handover
We structure the implementation of Aqua Security so that enabling blocking rules does not stop deployment. First we record the actual state of the environment, then collect behavior profiles on real workloads, and only after that move rules from observation mode to blocking. Each stage ends with an artifact by which the customer can see the result and verify it.
- Inventory of the environment and workloads. We build a map of clusters and environments, image registries, and service owners. We immediately note where the agent must be installed with privileges and where a restricted mode is sufficient — the deployment plan depends on this.
- Audit of access and existing rules. We review roles, service accounts, key lifetimes, and permission overlaps between teams. The output is a list of what is already covered and a prioritized list of gaps.
- Deployment on staging. A copy of the production environment with a typical set of services. We verify that the agent does not break builds and deployments and does not take a noticeable share of resources from workloads.
- Behavior profile learning. One to two weeks of observation: the system builds a baseline for launched processes, network connections, and file operations. Deviations go into a report rather than a block.
- Rule testing on staging. We reproduce typical scenarios: launching a shell inside a container, accessing an external address, writing to system directories. We make sure the rule triggers and gives the engineer a clear message.
- Phased enablement in production. The order is development, pre-production, production. We enable blocking one rule at a time, with an observation window and fast rollback to the previous mode.
- Handover to operations. We provide response procedures, on-call instructions, a role and access scheme, and the procedure for updating profiles. After an agreed period, we run a verification pass and adjust the rules.
What remains in your hands: policies, profiles, procedures
Implementation does not end with behavior control enabled, but with the handover of a package that your operations team can use to continue without us.
Everything configured in Aqua Security is captured as versioned artifacts in your repository: rules are stored as text, go through review, and roll back to a previous version, rather than living only in the web interface.
- Behavior control policies — what processes inside the container are allowed to do: launching a shell, writing to system directories, modifying binaries, outbound connections. Each rule specifies the mode (alert or block) and scope, so restrictions can be enabled gradually without stopping services.
- Application behavior profiles — baselines collected in learning mode on real traffic. You can see which processes, files, and connections are normal for the service; anything outside the profile becomes a signal rather than background noise.
- Role and access scheme — who on the team views events, who changes policies, who closes triggers. Environments are separated so that experiments in the test environment do not affect production.
- Response procedure for a trigger — a step-by-step scenario: who receives the notification, what is checked in the first minutes, under what conditions the container is stopped, and how the review is documented. With a priority matrix so the on-call engineer does not decide this anew every time.
- Integration with the build pipeline — image scanning before deployment: which rules trigger at build time, how a release is blocked, and how a justified exception is documented.
- Container protection documentation — architecture description, integration points with the image registry and logging system, rule update procedure, and troubleshooting of common errors.
- Acceptance and verification procedure — a set of test scenarios (launching a shell, attempting to write to a system directory, accessing a blocked address) that are run after every policy change and confirm that protection actually works.
We hand over each item along with a short “what to do if” instruction — so the package can be given to a new on-call shift, not only to those who took part in the implementation.
Case study: a class of failures disappeared, response accelerated severalfold
The problem was not that threats were not seen, but that checks relied on a manual procedure. Before a release, an engineer ran image scanning, reviewed the report by eye, and decided whether it could be shipped.
Some images went into the production environment without rechecking, the registry grew, and a container with excessive privileges and write access to the root file system was found through indirect traces in logs — days after launch.
We deployed Aqua Security and described rules as code: what privileges the container is allowed, where it can write, and which images are allowed into the environment at all.
The rules apply both at build time and at launch — an image without a clean report does not pass, and suspicious behavior of a running container leads to its stop, not to a log entry “to think about later.” Changes to rules go through review like ordinary code, so the reason for a block is always reproducible.
What changed in numbers
The share of images under automatic rules grew from about 40% to 100%, and only written, justified exceptions remained. Time from detection to response dropped from several hours to minutes and no longer depended on who was on call.
Incident investigation, which previously took half a workday, now comes down to checking a ready event chain.
The main result is that a whole class of failures disappeared: containers with excessive privileges, writes to system directories, and unnecessary outbound network connections no longer reach the production environment. The team stopped being the last line of defense and returned to development.
How behavior control differs from image scanning
Image scanning is a build-time check. While the container is not running, the analyzer examines layers, package versions, and dependencies, compares them against vulnerability databases, and produces a report.
It is a one-time snapshot: the result applies to the artifact, not to how it will behave in the cluster.
The answer to “what is inside” does not answer “what is happening.” A vulnerability in a library without a use scenario remains a risk, not an incident: it may be unreachable from the code or mitigated by configuration.
At the same time, downloading foreign code, accessing cloud metadata, or reading environment secrets are not visible in the image at all — they appear only at runtime.
Runtime control observes what the process actually does: which child processes it spawns, where it writes, with whom it opens connections, and which files it accesses.
A profile is built from normal behavior — a set of allowed actions — and deviation from it becomes an event tied to a specific container and node.
The difference between the approaches is the decision point. Build-time says “it is better not to let this image through,” while runtime observation says “this container is now doing what it should not,” and allows stopping it before the action completes.
One approach does not replace the other: build-time reduces the attack surface, while control covers what appears only in the runtime environment.
That is why we configure Aqua Security so that both loops work on consistent rules: then it is clear that an image was allowed deliberately, and what exactly the container violated at the moment of the trigger.
Technical concerns: false positives and load
Before starting, the same questions almost always come up: will protection start blocking normal processes, will the agent consume node resources, and will everything break when the cluster is updated. Below are direct answers.
Will false positives block working processes?
For the first week to a week and a half, protection runs in observation mode: the Aqua Security agent collects a baseline of container behavior and only writes events, stopping nothing.
Based on the accumulated profile, we describe rules — which calls are normal for a specific image — and enable blocking selectively. Residual false positives come down to a few per week and are handled by an exception list.
Is node load noticeable to applications?
The agent reacts to significant events — process launch, file access, privileged call — not to every passing request, so there is no rechecking of already open connections.
Overhead stays within a few percent, and peaks occur at container startup, not during operation under peak load. We take measurements before and after implementation on your own staging environment so this can be seen in numbers.
Is this compatible with cluster and image updates?
The agent is installed as a separate set on each node and starts with it — updating the runtime does not require manual reconfiguration. Policies are kept as configuration in the repository and rolled out in the same way as other service definitions. Before an update, rules are run on the test environment, so divergence is caught before production.
What to do if protection starts getting in the way?
Blocking is switched with a single change — the mode returns to observation, and applications continue running without a restart. Policies are versioned, and rollback means restoring the previous rule set, not rebuilding the staging environment.
Let's discuss your production environment protection task
To make the estimate based on facts rather than “give or take a quarter,” we need an initial snapshot of the environment. Below is what to send: it is enough to put together an implementation plan and give timelines.
- Service deployment diagram: namespaces, image registries, and the procedure for promoting a tag from the test environment to production.
- Node inventory and container runtime version — this determines what we cover with a node agent and what with an admission controller.
- Current network map: which services communicate with which, and over which ports. We use it to build behavior profiles so rules do not drop legitimate traffic.
- Event logging requirements: retention period, where events are shipped, and who reads them during incident investigation.
- List of regulatory and internal requirements for production environment protection — we will align policies with them before work starts.
- Maintenance windows for the production environment and the composition of the on-call shift: we build the implementation plan so that releases are not blocked.
In response, you will receive not generalities but a working package: a component placement diagram, implementation stages with rollback points, the procedure for moving rules from alert mode to blocking, and acceptance criteria.
In Aqua Security, production environment protection policies are defined declaratively, so they are enabled in stages and rolled back without rebuilding images.
Describe the task in free form — we will come back with a work estimate and implementation plan.