Organizations are increasingly turning to containers to fuel their digital transformations. According to BMC, a 2019 survey found that more than 87% of respondents were running containers—up from 55% just two years earlier. Additionally, 90% of survey participants that were running applications in containers were doing so in production. That was up from 84% in 2018 and two-thirds of surveyed IT professionals a year before that.
The Benefits and Challenges of Containers
According to Kubernetes’ documentation, containers are lightweight and decoupled from the underlying infrastructure. These properties make it easier for admins to port containers across their cloud environments and OS distributions in support of their business needs. They are also much easier to create than virtual machines (VMs), which helps organizations that are looking to horizontally scale their container environments.
That said, organizations are running into some security challenges with their containers along the way. In a 2019 Tripwire survey, for instance, 60% of IT security professionals who managed environments with containers at companies consisting of over 100 employees admitted that their employers had suffered at least one container security incident in the preceding 12 months. Three-quarters of respondents working at organizations with over 100 containers in production went on to tell Tripwire that they had suffered a container security incident in that same period of time. Not surprisingly, 94% of survey participants disclosed the fact that they were concerned about their organization’s container security posture.
Where that Leaves Organizations
Organizations want to enjoy the benefits of using containers, as described above. They don’t want to suffer a security incident. Acknowledging that reality, developers and security professionals need to minimize the security issues confronting the container images. That’s especially the case with the container images that they’re creating themselves.
Presented below are some best practices that these teams can use to create secure container images for their organization.
Practice Vulnerability Scanning
As noted in this blog, for third-party images, vulnerability scanning is the main priority. If the images for the applications you need always seem to be full of CVEs, even in the latest version, you may want to build your own image for the application. For images you build yourself, make scanning for vulnerabilities part of your CI cycle. Choose a container vulnerability scanner that supports not just operating system packages but also language libraries.
As with vulnerability management more generally, however, organizations can’t scan their images once and be done with it. New CVEs come up all the time, after all. Container Journal therefore recommends that organizations scan their images on an ongoing basis as well as build image scanning into different parts of the application life cycle. That includes when the image is being built within the CI/CD pipeline as well as when the image is running.
Make the Container Images as Simple as Possible
Complexity is the antithesis of security. Google understands this fact in relation to containers, which is why it recommends that organizations remove unnecessary tools from their images and other workloads. No one in the organization might have an immediate use for a utility like netcat, for instance. But if that utility is present, an attacker could leverage it to create a reverse shell inside of an organization’s system. It’s therefore in organizations’ interest to limit the number of tools that are packaged in their image and install only what’s needed; doing so will help to reduce the ways in which an attacker could misuse their containers for malicious purposes.
Run the Container as Non-Root
Organizations can’t stop at just reducing the size of their images, however. Nefarious individuals could always try to use a container compromise to install their own tools. In response, organizations might consider avoid running the container as root. The Walmart Global Tech Blog notes that running a container as root might help developers to get an application to work but that it also creates various security risks. (For instance, execution of code becomes root in that scenario, thereby allowing attackers with root access to execute malicious code.) Organizations can prevent their containers from running as root by deleting or uninstalling the sudo command. Additionally, they might consider launching their containers in read-only mode using the --read-only flag to prevent malicious actors from adding in tools of their choice.
Security as a Source of Trust
Container images are useful but only if organizations can trust that they’re secure. Using the steps above, organizations can build their own containers to continue to drive their digital transformation and grow their business to meet tomorrow’s needs—all while helping to keep their containers secure against digital attackers.
For more information about how to harden the security of their containers, check out Tripwire’s container security guide here.
