Setting up trusted repositories is one of the most critical security controls for any containerized environment. Doing so is necessary to ensure that:
- Your organization can get images from a trusted source
- Developers building images get base images from trusted image repositories
- You can block untrusted images from your Production environments
- You can alert on untrusted images in other environments, such as Developments
Lax security practices are a leading cause of security breaches in any environment. Providing new tools and training are not enough, you also have to remove incentives that lead to bad security practices. In this case, we’re talking about being proactive and establishing a library of trusted images that’s wide and deep enough to meet your teams’ needs. This greatly reduces the motivation individuals in your organization might have to run insecure packages.
To start the process of bringing your containerized environments under control, you can partner with teams inside your organization to create a library of the images they require. In particular, you can partner with development teams to create a set of trusted base images they can use to build new images. This practice, “Use trusted base images for containers”, is cited by The Center for Internet Security (CIS) as one of key items in its CIS Docker 1.11.0 Benchmark for container images and build files.
Because those images come from verified sources and you know which versions of software they contain, you can more effectively monitor them for vulnerabilities. When vulnerabilities are identified and patches become available, you can rebuild images to include security patches and replace the old versions. Simply starting your Dockerfiles with FROM foo:latest is a good start, but not nearly enough to really make sure you have up to date images. Library images don’t always have the most up to date patches and, even if they do, you’re probably still adding additional software into them to create your own specific images.
Another benefit of bringing the creation and running of images under control is that your organization can follow many of the other CIS best practices for container security, such as:
- Create a user for the container
- Do not install unnecessary packages in the container
- Rebuild the images to include security patches
- Enable Content trust for Docker
I should emphasize that what I’m describing is an incremental process. Having established a set of trusted images and repositories, you can begin applying restrictions to specific environments in your organization. For example, you can start by generating alerts when untrusted images run in your Production environment. You can partner with the Development and Production teams to provide images that meet all of their requirements and establish processes for introducing new images. Eventually, when everything is in place, you can block untrusted images from running in Production.
As you bring your containerized environment under control this way, your security team may able to transition away from playing whack-a-mole with threats inside your container environments, and can start working to strategically prevent them from getting there in the first place.
Your organization can use Twistlock to create and enforce trusted registries and images. This trusted registry can house images that have been scanned and approved by Twistlock and are stored on any Docker compliant registries you already use.
Twistlock simplifies the process of managing trusted repositories and images. You can apply simple policies that generate alerts or block non-trusted images from running. You can trust images based on the repository where they’re located, their image name, or their image ID. The net result is that you definitively control exactly what images are allowed to run in different parts of your environment with a simple, centrally managed policy.
Ready to simplify your organization’s trusted repository and images? Request a live demo of Twistlock here.
- Read The Ultimate Guide to Container Security and learn the ins and outs to securing your containers!
- Learn about the Three Pillars of Intent-Based Security for Containers to be able to use whitelisting.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog
Twistlock 18.11 Release NotesRead the Blog
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog