AWS ECR: Improving Container Security

Following the HIPAA compliance along with our Foundation and application modernisation, we have been asked to add more security layers, especially on the application modernisation step.
How to create a docker image repository?
In your AWS console on the search bar, look for ‘Elastic Container Registry’ and then ‘Create repository’. You will see this screen:

Docker image scanning, showing create repository page

Fill up the repository name and hit create.
You can also check our Terraform stack which will allow you to create a repository using infrastructure as code:
But let’s keep in mind the security layer that I mentioned. One cool feature of the AWS ECR service is the possibility of scanning the image pushed at your will.
Ok, inspecting all images pushed manually is not what we want. It’s possible to enable the scan-on-push feature during the repository creation and edit a pre-existent repository and enable it.

Docer image scanning, showing scan on push is enabled

Our Terraform stack provides the scanning-on-push feature enabled by default:

After pushing an image to your docker registry, the column Vulnerabilities will appear in your ECR for each new image:
 
Checking the vulnerabilities details:
 
Now that we can see the vulnerabilities, what else can we do?
Let’s say that you (and everybody else concerned about security) don’t want to deploy this image to your environments (Dev, QA, Homolog/Staging, and definitely not to Prod).
You can use the script below in your pipeline. The script will stop the deployment if it finds a security vulnerability.
If you want to stop the deployments of CRITICAL vulnerable images only, you just need to set the environment variable SEVERITY to CRITICAL.
If you want to be more strict, you can set more severity levels. To do it, you need to set that environment variable as a list, e.g: SEVERITY = “CRITICAL HIGH”. The meaning of the list is simple. If you set a lower severity level and your image has greater level breaches, the deployment will go on.
Go ahead and add the script one step before you deploy a new image to your environment:

Conclusion

It’s a simple solution that can avoid a major vulnerability to go forward to your production environment. Using the AWS tools on your behalf could save you from a few headaches.

At DNX Solutions, we work to bring a better cloud and application experience for digital-native companies in Australia.

Our current focus areas are AWS, Well-Architected Solutions, Containers, ECS, Kubernetes, Continuous Integration/Continuous Delivery and Service Mesh.

We are always hiring cloud engineers for our Sydney office, focusing on cloud-native concepts.

Check our open-source projects at https://github.com/DNXLabs and follow us on Twitter, Linkedin or Facebook.