Aqua Image Assurance and KubeEnforcer: Policy Gates from Registry to Kubernetes

Trivy CLI scanning and Aqua Platform enforcement solve different parts of the container-security problem. Trivy can inspect a filesystem or image and return findings; that report does not block a registry push, deployment, or runtime action unless a separate control consumes it. Aqua’s Image Assurance and Kubernetes KubeEnforcer integration is a vendor-specific policy path that can connect assessed images to admission decisions. It requires the relevant Aqua product components, configuration, and entitlements; it is not a guarantee that every cluster or workload is protected merely because an Aqua scan ran.

This guide focuses on the control boundary that sits between an image assessment and Kubernetes API admission. Aqua’s public deployment repository and KubeEnforcer Helm documentation describe current deployment inputs, webhook TLS configuration, optional scanner integration, and policy evaluation. Exact UI names and behavior can change between Aqua Platform releases, so use the product documentation for the version and deployment model you actually operate.

Separate assessment from enforcement

An image scanner produces evidence about an artifact. Image Assurance policies define which conditions make an image acceptable for a configured control. KubeEnforcer is the cluster-side component that integrates with Kubernetes admission so a create or update request can be evaluated against the configured image-assurance decision. Those are distinct operations:

Stage	Question answered	Evidence to retain
Build or registry assessment	What did the scanner observe in this exact image?	Image digest, scan time, scanner and database inputs, raw report
Aqua policy evaluation	Does this image meet the selected Image Assurance policy?	Policy identifier and version, findings, disposition and exception owner
Kubernetes admission	Should this API request be allowed under the cluster’s configured enforcement path?	Admission response, webhook health, image reference and audit event
Runtime monitoring	What is the workload doing after it was admitted?	Enforcer or operator status, observed events and workload identity

Do not infer enforcement from a green scan result. Confirm that the image was registered or evaluated in the expected Aqua tenant, the policy applies to the right workload, KubeEnforcer is connected, and the cluster’s admission webhook actually handles the request. Also do not treat an admitted workload as proof that the scanner found no issues: policy exceptions, unregistered-image behavior, policy scope, and enforcement configuration can all affect the decision.

Understand the KubeEnforcer and scanner components

Aqua’s current public aqua-helm repository documents a KubeEnforcer chart and describes Kubernetes Assurance Policy evaluation as part of preventing non-compliant workloads from being deployed. Its chart documentation also says that Trivy Operator is enabled by default for that chart configuration and that Starboard should not be enabled at the same time. With the operator present, the chart describes compliance re-evaluation during workload runtime and reflection of results in the Aqua UI; without it, the KubeEnforcer checks compliance when workloads start. Verify these statements against the exact chart release and Aqua product version before relying on them in a change plan.

This is not the same as installing the standalone Trivy CLI in a CI job. The operator and admission component have cluster lifecycle, service-account, network, certificate, and API-server dependencies. Aqua’s deployment documentation describes communication to Aqua SaaS or a gateway, a KubeEnforcer token, Kubernetes discovery permissions, and TLS authentication between the Kubernetes API server and the enforcer webhook. Give each of those inputs a named owner and rotation or renewal plan.

When discovery is enabled, review the chart’s documented Kubernetes permissions rather than granting cluster-wide access by habit. The repository lists read operations over workload, node, namespace, and related objects for its discovery behavior. Confirm which features require each permission in your selected configuration, and remove optional permissions only where the supported product setup allows it. A least-privilege review must preserve the controls you intend to use while excluding unrelated privileges.

Roll out policy enforcement without surprising the cluster

Begin in a non-production cluster with a pinned, reviewed Helm chart version. Render the chart and inspect the generated ValidatingWebhookConfiguration, service endpoints, certificate references, namespace selectors, and service-account roles before installation. Source the KubeEnforcer token from a secret manager or protected Kubernetes Secret; avoid placing it in shell history, a committed values file, or verbose CI logs. Ensure the webhook certificate and CA bundle are valid and that the API server can reach the configured endpoint.

Use a staged rollout:

Connect a test cluster to a test Aqua tenant or an approved isolated policy scope.
Register or assess known image digests and verify the expected policy results in Aqua.
Confirm KubeEnforcer health, webhook TLS, admission configuration, and the selected namespace or workload scope.
Submit a known-compliant image and a deliberately non-compliant test image; observe both API-server decisions and Aqua audit evidence.
Test the documented behavior when the webhook, gateway, or required certificate is unavailable. Inspect the rendered webhook failure policy rather than assuming the cluster will fail open or fail closed.
Roll enforcement to additional namespaces only after owners understand the denial response, exception process, and emergency recovery path.

Kubernetes admission controllers are in the API request path before an object is persisted. That gives policy useful preventative leverage, but it also makes availability and scope material. A webhook with excessive scope can block unrelated workloads; a webhook with exclusions or failure behavior that is not understood can permit traffic that the policy owner thought was blocked. Keep an inventory of excluded system namespaces and workloads and review it whenever cluster add-ons change.

Verify the identity of the image, not only its tag

Tags can move. Make the scan and admission workflow test an immutable image digest or Aqua’s documented image identity, then verify that the deployed Pod resolves to the artifact that passed assessment. Test multi-architecture image indexes and registry mirrors in the same way your production nodes pull them. A successful scan of app:latest is weak release evidence if the tag changes before scheduling.

For a failed admission, collect the namespace, resource name, requested image digest, webhook response, policy decision, and Aqua-side scan record. Redact tokens and secrets. Determine whether the denial came from vulnerability policy, an unregistered artifact, configuration or malware rules, a stale assessment, or a connectivity/certificate failure. Avoid adding a broad allow rule merely to restore deployment; make a time-bounded exception with an owner and compensating control if an emergency approval is required.

Keep vendor capabilities separate from universal guarantees

Aqua describes its platform as connecting image assurance, cloud posture, and runtime security. Treat statements about exploit blocking, workload behavior, malware detection, and coverage as vendor capability claims whose exact availability depends on product version, licensed features, deployment mode, sensor coverage, and policy configuration. They are not generic properties of Kubernetes admission or proof that every threat is stopped. Kubernetes provides the admission extension mechanism; Aqua components and policy supply a particular implementation of it.

Use this architecture as one control in a layered pipeline: source review, dependency and image scanning, provenance and signature verification, cluster admission, runtime monitoring, and incident response. Keep the Trivy report, Aqua policy disposition, cluster admission event, and deployed image digest linked to the same release record. When those four pieces line up, the organization can explain what was assessed, what rule applied, what the cluster decided, and what artifact actually ran.

Related:

Sources: