How container adoption affects container security
Scalability and efficiency make container adoption an attractive option for enterprises today. Learn how containerization has evolved and grown since the release of Docker 1.0 five years ago.
Security pros know October as National Cybersecurity Awareness Month. But October 2019 marked another important event: It was the fifth anniversary of the release of Docker 1.0.
Since Docker was introduced, there has been a tremendous evolution in containers and the containerization ecosystem. Consider, for example, the emergence of container-focused cloud services, the proliferation of orchestration tools to tackle usage at scale, and the explosion of use of container runtimes and container-aware orchestration tools.
Cloud monitoring provider Datadog found that, as of June 2018, nearly 24% of organizations have adopted Docker -- in fact, Docker runs on more than 20% of all hosts. This growth is tremendous; it rivals that of virtualization, cloud and numerous other technologies that are ubiquitous in the modern technology landscape.
From a container security perspective, there have been changes as well. According to data from Skybox Security, container-related vulnerabilities have increased 240% over the past two years. Some of these vulnerabilities are fairly significant -- enough to rival even the notorious dirty copy-on-write issue, which security teams may remember caused quite a stir in the early days.
Recent container vulnerabilities include a runC issue that could enable attackers to gain root access and an issue with Docker Skeleton Runtime for Apache OpenWhisk that could enable attackers to overwrite user code. Another vulnerability exists in orchestration platforms, such as Kubernetes, which enables insecure archive extraction with the kubectl cp command.
Given how much has changed and how rapidly change will continue, it is valuable to revisit container security and review what's changed, what's stayed the same and what security pros can do to keep pace.
What's new in container security?
Many of the change drivers in the container security ecosystem relate to two things: usage and maturity. Given the expansion of usage, one could expect the continued emergence of security products specific to containers. This includes everything from container-specific intrusion detection systems (IDSes), including Alert Logic or Qualys, to threat and runtime protection, like StackRox or Aqua, to full suites of container-oriented security products, such as Palo Alto and numerous others.
As usage expands, so does maturity. As the maturity of the ecosystem increases, security pros should expect to see consolidation in the marketplace. There has been some evidence of this already -- for example, Palo Alto Networks acquiring Twistlock and Qualys acquiring Layered Insight.
Expect to see more evolution and maturation of the technical mechanics of container security as well. For example, consider the bolstering and expansion of security-relevant features in orchestration components. The refinement of the underlying substrate that enables container segmentation is also evidence of the maturation trend. For example, the work done in the Linux kernel to harden and extend namespaces, including the introduction of cgroup namespaces in Linux 4.6 and proposed time and syslog namespaces.
Standardization and authoritative guidance are two other byproducts of maturity. Consider standardization efforts, such as the App Container standard, which specifies container formatting and environments, or authoritative guidance, such as NIST's SP 800-190 "Application Container Security Guide." This paper was designed to give guidance to organizations during container adoption on how best to secure and regulate their use. It outlines risk considerations for container usage, lifecycle guidance and considerations, as well as offers example threat scenarios and general guidance about secure deployment.
How does this change your container security approach?
At a macro level, the daily work security pros need to do to keep containers secured has not changed drastically since the early days. Yes, the segmentation model between containers has improved, but there are still portions of Linux that are not namespaced -- for example, time.
Together with the different segmentation boundary in containers relative to OS virtualization, there is still added complexity in multi-tenant use and means. Security admins must continue to pay particular care to grouping containers based on what they do, their sensitivity or criticality, and what type of data they process.
Tools designed with containers in mind can provide enhanced security relative to those designed on a different set of assumptions. This was true with respect to cloud and virtualization and is true today in the case of containers. For example, vulnerability scanning tools, IDSes, inventorying and discovery tools, audit tools and others that are designed to work within the containerization ecosystem can provide additional security benefits.
The fact that the ecosystem has matured means buyers of these tools have more options. However, the essence of the problem remains unchanged: Legacy, noncontainer-aware tools need to adapt their usage in light of the changing context where products specifically designed around the new model may offer advantages.
Docker container security: 2014 to 2019
Things have changed in two ways since the initial Docker 1.0 release five years ago. These shifts are pointed out explicitly in the NIST guidance: container-specific OS instances and cultural or educational shifts by organizations to accommodate container usage.
In the case of container-specific OS instances, as container usage has proliferated, OS versions have evolved -- some commercial, some otherwise -- to be designed specifically to run containers. They are unique in that they do not have many of the other underlying services or capabilities that a more general OS footprint might offer. Today, there is no obligation to build, harden and test custom, lightweight OS images to support containers, which is a time-consuming effort. Instead, architects and engineers can select from deployments designed specifically for the very purpose of supporting containers.
In terms of cultural and educational shifts, the adaptation of containers into production development, release, support and security processes is an outgrowth of increased maturity and familiarity with containers. As infosec pros have become familiar with what containers are and how to best use them, industry knowledge accrues. This helps build awareness of container-specific security considerations to others in the organization. Just a few years ago, educating security practitioners about containers was a challenge. As usage expands, this becomes less of an issue, and it becomes easier to institute container-specific processes and security measures.
In short, container adoption has changed the landscape and will continue to do so. Usage is still not quite fully mainstream, but it will not be long until it is. For security pros willing to jump in with both feet, it presents an opportunity.