Automating a Secure Container Pipeline: Aqua 1.1
The proverbial digital ink is not yet dry on our GA announcement last month, and here we are at DockerCon only a month later announcing Aqua Container Security Platform v1.1.
The new version has dozens of new features and enhancements, all driven by customer requirements. I’d like to focus on two aspects where I think we’re making a difference - security automation as part of the container dev-to-production lifecycle, and the protection of ‘secrets’ in containers.
We created a native Jenkins plug-in that adds an Aqua Security step to the CI pipeline that enables organizations to automate container image security scanning, report within the CI/CD tool on vulnerabilities found, and allow/disallow the use of images according to policy.
How does it work? Here’s a step by step description:
1. On your Jenkins server add a new Aqua Secuirty build step
2. Select a local or hosted image scan
3. Successful scan without vulnerabilities that will allow the image to be pushed to your organization registry
4. Failure of an image scan marked as disallowed due to its vulnerabilities.
This will stop the image from being pushed to the organizational registry.
In addition, a detailed, ranked list of vulnerabilities (CVEs) will be available as a result of the scan in a json format .
We also worked with HPE’s ALM (application lifecycle management) product team to integrate into ALM Octane, their next generation ALM solution.
Here, we defined Aqua as a new type of ALM security test, allowing development teams to view how their pipelines have fared in security testing, and to set rules as to what constitutes a “pass” mark. Users can click right from the test results to drill down and view all the CVEs that were found in their image.
These integrations (and we have more on the way) allow our customers to implement Aqua’s container security platform in a very transparent, unintrusive workflow that maximizes the benefits they get in terms of security and compliance, because it is fully integrated into multiple points within the process, and is fully automated. So instead of relying on a human-driven process, there are automated steps that enforce security. And instead of having a single point of failure, say at the image push stage, the customer can continuously check and validate the security posture of their containers every step of the way.
While this is a relatively specific feature, it tackles a major pain point for many of our customers. Since any developer can include secrets such as passwords in environment variables early in the process, and they are accessible in clear text when the container is run, this opens the door to unauthorized access at any time while containers are running in production - which could be anywhere…
With our new encryption feature, we now allow you to encrypt environment variables in images. This is how it works:
1. Using the Aqua Management Console, attach one of our default security profiles to protect your image. In our case I chose the default WordPress security profile.
2. Among many other aspects of the profile, you may now encrypt all the image environment variables or select specific ones like in the following example:
3. From now on, the environment variables will be encrypted everywhere e.g. in the Aqua Management Console UI:
4. And also in a regular “docker inspect wp-server” command which will show the values encrypted.
So as you can see, the “secrets” feature is extremely easy to use, and plug one of the most critical security gaps in container development pipelines today.
Security and Automation are Not Contradictory
The above features are additional steps in realizing our vision of securing containers in a way that is as transparent and automated as possible. Some of our customers create and deploy thousands of containers each week, and it’s simply not possible to stop this flow for security inspection - so our mantra: automation good, manual process bad.