When it comes to securing containerized applications, the first item on everyone’s agenda is to ensure that only trusted images are running in your environment, based on security and compliance policies. And for good reason too. This is by far the most effective preventive measure you can take to protect your applications.
If you don’t sanitize your image pipeline, the attack surface of your applications might become unmanageably risky. But how can you ensure that the policies you apply are optimal to both image and usage context?
With Aqua, customers can take advantage of the Multiple Image Assurance Policies feature to build an optimal image assurance policy for images based on usage context. This is to ensure that security controls are effective enough and optimized based on the image scope.
What’s an Image Assurance Policy?
Let’s start from the beginning. An Aqua image assurance policy allows you to apply granular checks on an image to eventually enable an automated decision if an image will be allowed or disallowed from running.
One of the first steps in applying security to images is to scan image repositories for known risks. Each image in the repository is scanned for vulnerabilities in both its OS packages and development language files. We also look for any embedded “secrets” and use custom checks to look for sensitive data (e.g. PII) within images to ensure there are no additional risks in the image. Once the scan is completed, the scan results are presented and the image receives a vulnerability score.
Based on the findings and according to your predefined policies, Aqua either allows the image to run in your environment, or disallows it (in other words: blocks it from running).
A “policy” is a combination of controls used to determine the conditions an image must meet, as in these examples:
- Prevent running image as “root” (or “admin” in case of Windows containers); prevents running the image with a “super-user” account, which poses a risk to the underlying host.
- Vulnerability blacklist: When enabled, images that contain one or more of the defined vulnerabilities will automatically be disallowed from running (you can add/remove vulnerabilities from the list).
- Package blacklist: When enabled, images must contain all of the defined packages to be allowed to run (you can add/remove packages from the list).
- Disallow images by CVSS severity: When enabled, images whose security status equals a certain selected status will automatically be disallowed from running.
- Disallow images by vulnerability maximum score: When enabled, images with any vulnerability with a score that is equal to or exceeds the set limit will automatically be disallowed from running.
- Enforce approved base images: When enabled, only images built using an approved base image will be allowed to run; other images will be blocked.
- Custom compliance checks: When used, a user can run an external script on images. If the script finds any faults, the image will be disallowed.
- SCAP scanning: Users can add a script in OVAL (Open Vulnerability and Assessment Language) format, version 5.11 or earlier, that will apply SCAP standard scanning to the images to which the script is applied. If any of the settings defined in the OVAL file are violated, the results are included in the scan results.
What do we mean by Multiple Image Assurance Policies? What’s in it for you?
From Aqua 2.6 and higher, you can apply granular policies to different images on which the allow/disallow decision is made. If an image fails a control in any of the policies for which it’s in scope, it will be disallowed.
Aqua image assurance policies can be applied to images based on a combination of specific image names, Aqua labels (which can be used to tag a variety of entities), and the registries in which they’re stored. This gives admins the flexibility to apply different security policies to their pipeline depending on factors such as the stage within the pipeline, specific sensitive images, application groupings, or specific running environments.
A typical use for this feature would be to apply stricter assurance policies to images in staging, and less stringent policies to images that are still in development or testing. This would make it easier for developers to experiment with images even if they don’t yet meet the stricter policy. For example, an image assurance policy ‘Disallow running images as “root” can be applied to images in the staging registry, while if the image is still in a development or testing stage, it can run as root, as it doesn’t pose any risk at this stage.
In addition, during development, there may be a need to test images that are not fully compliant with the image assurance policies. For example, we may not want to bother with certificates during initial testing, so a Web Layer nginx image may not be configured for HTTPS. We don’t want this image to run in production, but we might want to run it in a test environment.
It’s important to remember that multiple checks can create a policy and multiple policies can be applied to an image. This allows you to automatically apply the right security controls based on a combination of image scope and related security requirements, without halting DevOps processes, striking the right balance between efficiency and security.
To learn more about how early development choices can impact security, check out this Aqua webinar.
If you have any questions, comments or are interested in a product demo, contact us.