Aqua Security’s Assurance Policies are how you enforce security and compliance rules across your containerized environments. When you’re talking about "block risky images," you’re essentially telling Aqua: "Don’t let anything run that doesn’t meet these specific criteria." This is the core of preventing known vulnerabilities, misconfigurations, or even unauthorized artifacts from hitting your production or staging clusters.
Let’s see this in action. Imagine you have a CI/CD pipeline that builds and pushes container images to a registry. Aqua can scan these images as they’re pushed.
# Example of a security scan in a Jenkinsfile (simplified)
pipeline {
agent any
stages {
stage('Build') {
steps {
script {
sh 'docker build -t my-app:latest .'
}
}
}
stage('Scan') {
steps {
script {
// Aqua CLI command to scan an image
// Replace 'aqua-registry.example.com/my-app:latest' with your image path
sh 'aqua scan image aqua-registry.example.com/my-app:latest --output-format json > scan_results.json'
}
}
}
stage('Push') {
steps {
script {
// This stage would only proceed if the scan was successful and met policy
// We'll get to how the policy enforces this next.
sh 'docker push aqua-registry.example.com/my-app:latest'
}
}
}
}
}
Now, how do we block the risky ones? That’s where Assurance Policies come in. An Assurance Policy is a set of rules that Aqua evaluates against your images and running containers. If an image or container violates any rule in the policy, Aqua can take action – like preventing deployment or even terminating a running container.
The "riskiness" of an image is typically defined by its vulnerability score, compliance status, or whether it contains unauthorized software. For example, you might want to block any image with a critical vulnerability, or any image that doesn’t have a recognized software bill of materials (SBOM).
Here’s a snippet of what an Aqua Assurance Policy might look like (this is a conceptual representation, actual policies are configured via the Aqua UI or API):
{
"policyName": "production-readiness-policy",
"description": "Ensures images deployed to production are secure and compliant.",
"rules": [
{
"ruleType": "vulnerability",
"severity": "CRITICAL",
"action": "BLOCK"
},
{
"ruleType": "vulnerability",
"severity": "HIGH",
"fixAvailable": true,
"action": "BLOCK"
},
{
"ruleType": "compliance",
"checks": ["CIS Docker Benchmark", "NIST SP 800-190"],
"action": "BLOCK"
},
{
"ruleType": "malware",
"action": "BLOCK"
},
{
"ruleType": "secret",
"action": "BLOCK"
}
]
}
In this policy:
- The first rule says: if an image has any CRITICAL vulnerabilities, block it.
- The second rule adds: if an image has a HIGH severity vulnerability and a fix is available, block it. This is a common strategy to balance security with the operational burden of patching.
- The third rule ensures images pass specific compliance checks.
- The fourth and fifth rules prevent images with known malware or hardcoded secrets from being deployed.
When Aqua scans an image (either during build, push, or when it’s about to run), it compares the scan results against the active Assurance Policies. If any rule in the policy is violated, and the action for that rule is BLOCK, Aqua prevents the image from being deployed or, if it’s already running, can terminate the pod.
The real power comes from integrating this into your workflow. You can apply policies at different scopes: globally, per-account, or even per-project. This means you can have a more lenient policy for development environments and a much stricter one for production. Aqua’s integration with Kubernetes admission controllers is key here. The admission controller intercepts pod creation requests and calls Aqua. If Aqua says "block," the admission controller denies the request, preventing the pod from ever starting.
One of the most nuanced aspects of Assurance Policies is their ability to differentiate based on the lifecycle stage of an image. You can configure a policy to block deployments of images with critical vulnerabilities in your production environment, but perhaps only warn about them or block only if a fix is unavailable in your development environment. This allows for a progressive security posture that matures as the artifact moves through your pipeline. It’s not just about what is blocked, but when and where that blocking occurs, reflecting a sophisticated understanding of risk tolerance at different stages of software delivery.
The next step after mastering Assurance Policies is often implementing runtime security, which builds upon the image assurance to monitor and protect running workloads.