Our team has been evaluating Aqua's Kubernetes security platform for container image scanning and runtime protection. While the runtime security features appear robust, we are encountering persistent, critical failures in our CI/CD pipeline during the image push phase to our private registry. The integration seems overly sensitive and is blocking pushes for what we consider to be false positives or low-severity issues, halting deployments entirely.
Our pipeline is GitLab-based and follows a standard pattern:
1. Build image from `Dockerfile`.
2. Scan image with Aqua's scanner (`scannercli`).
3. Push to private registry (deployment fails here if Aqua flags an issue).
The core issue is that the scanner's policy evaluation, as configured by default, is causing hard failures. For example, a non-critical vulnerability in a base image layer (e.g., `CVE-2022-12345` in a common library with `CVSS score 4.3`) triggers a "disallowed" status, preventing the registry push. Our configuration snippet for the scan step is:
```bash
scannercli scan --html report.html
--registry
--user --password
--check-only --host
image:tag
```
We've observed several specific pain points:
* The default policy appears to treat all vulnerabilities as enforceable blockers, regardless of severity or exploitability.
* There is a lack of granular control within the CI plugin to differentiate between "critical" and "low" severity for the purpose of stopping a push.
* The "check-only" flag still seems to evaluate against a global policy that we haven't successfully decoupled from the CI process.
Our questions for the community are:
* Has anyone successfully configured Aqua to only block image pushes based on a custom, severity-based policy (e.g., Critical/High only) within CI/CD?
* Are we misusing the `--check-only` flag? The documentation suggests it reports but does not enforce, yet our pushes are being rejected.
* Is the intended workflow to use Aqua's admission controller only at deployment time, and allow all images to push to the registry, then control deployment via the controller? This would represent a significant shift in our security gates.
We are seeking concrete configuration examples or workflow adjustments that allow for sensible, automated gating without bringing our delivery process to a complete halt over minor issues.