In the early days of Docker, container security solutions were pretty primitive. But as containers have grown in popularity and gained a massive presence in production environments, the solutions for securing containers have grown more sophisticated.
To appreciate just how much has changed in the world of container security since Docker’s founding in 2013, let’s walk through how container security tools and practices have evolved (along with containers themselves) over the past several years.
Early days of the modern container (up to mid-2015)
Docker introduced their suite of products in 2013, which made building easily reusable container images possible. The early adopters outside of the hyperscale world in the technology industry saw even more possibilities. By the time Docker 1.0 was released in mid-2014, even the mainstream technology industry was starting to see the value when combined with continuous integration and continuous delivery programs — It was like a dream team.
At that time, existing application security approaches were still considered adequate. Container usage and the marketing from several vendors centered around reuse and higher density on compute nodes compared to the most common approach at the time — a traditional virtual machine (VM) per application.
Even well into 2015, container technology was still implementing enterprise-friendly authentication and authorization features in container registries and repositories, and using TLS by default for requests to download images instead of clear-text HTTP.
Security becomes a priority (mid-2015)
By mid-2015, container vendors were starting to increase the default security profile of running containers by introducing tools like SELinux and OpenSCAP, and increasing the use of seccomp to reduce the amount of the host operating system that a running container could read from and write to. Examples are written in some release notes like “prohibit mounting of /sys” (from Docker 1.6.1).
Container management matures (2017-now)
Kubernetes became the dominant orchestration option for containers at scale across Linux and Windows in 2017. This is also true for multiple network providers — from community drive projects to startups (ex: Tigera), as well as established networking vendors (ex: Juniper). And with containers being a supported offering by all the major cloud providers, we have entered an era where containers are considered mature and scalable by mainstream users, and wider adoption will start to pick up across the technology landscape.
Gaps around what code is in play
Unfortunately, as you may have noticed so far in this article, everything in the realm of security around containers has received significant attention from various vendors. What code actually makes it into the container and is running has not been covered. Dynamic testing always exists to test a service once it is live, but that is often just once, and very late in the development cycle.
Shifting security scanning to much earlier in the development cycle using tools designed to be plugged into the CI/CD pipeline, like tools from Twistlock, can catch known vulnerabilities before they make it to production, and will give development teams the ability to fix problems well before they become actual risks — And teams can deliver a higher-quality product with less rework.
If a full suite of security scanning tools is used, it will also scan what is already built and in use to identify which systems are at risk from newly discovered vulnerabilities, allowing security teams to mitigate risks as they’re discovered, and development teams can prioritize updates to production systems based on the risk level of anything that is found.
Between the products available from container specialists and other container providers (open source or commercial), a complete solution that considers all aspects of a container’s lifecycle can be built, maintained and used at scale for organizations of any size, from the largest companies to a small shop with a couple services backing a mobile app.