Container technology has quickly become ubiquitous in the IT industry, with most companies having adopted container technology on some level or contemplating adopting it soon. A survey by Portworx and Aqua Security discovered that 87 percent of IT professionals surveyed (up from 67 percent the previous year) were running container technologies in some capacity, with over 90 percent of them running in production. The trend toward container adoption continues to accelerate as enterprises and DevOps teams are increasingly seduced by the lightweight and agile nature of a cloud-native model that supports continuous integration and deployment (CI/CD) and microservices architecture. The reduced overhead makes it easier to deploy containers to run repetitive processes like batch jobs and ETL (extract, transform, and load) functions that often run in the background. However, throughout 2019, the vulnerabilities of container technologies have been starkly revealed, requiring companies to prioritize securing containers at multiple levels or risk exposing sensitive data.
Container security and container vulnerabilities
When asked about the major challenges they faced in container adoption, 51 percent of respondents to the Portworx and Aqua Security survey cited security as the primary concern of migrating to a cloud-native model. In fact, many companies that are drawn by the lowered costs and faster deployment speeds of container technologies often accept the security vulnerabilities of containers and container images as part of the risk instead of actively addressing issues before they arise. Tripwire’s State of Container Security report released at the beginning of 2019 highlighted this issue when it was revealed that 47 percent of organizations surveyed had vulnerable containers in production, while a whopping 46 percent were unsure if deployed containers had vulnerabilities they were unaware of. Sixty percent of all organizations surveyed had experienced a container security incident over the next year, and 42 percent had limited container adoption due to security concerns. A whopping 98 percent sought additional security capabilities for container environments.
In February, the discovery of the runC vulnerability that affected Docker, Kubernetes, and even Apache Mesos revealed that the implementation of user access controls by Docker to limit access privileges was still not sufficient to stop attackers from gaining root access to host servers. It stood out among many of the major vulnerabilities discovered in containerized environments as an example of why the most popular container technologies were not exactly the most secure. Another severe copy vulnerability in Docker was patched in November, driving home the point. These vulnerabilities were all signs that organizations needed to take responsibility for ensuring that they incorporated security into the DevOps and CI/CD pipeline, a process known as DevSecOps. Instead of just patching vulnerabilities when they were discovered, often even after a breach or an attack, organizations are now dedicating resources and professionals to tackling the task of automating security configurations and products into the DevOps pipeline.
Kubernetes requires specialized security solutions
The name on everyone’s lips in terms of container orchestration is Kubernetes, but the platform only offers basic security measures, requiring organizations to enforce security monitoring and compliance enforcement themselves. A variety of third-party tools have been developed to help bridge the gap, which you can read all about here. Experts have pointed out several serious security issues with Kubernetes. A serious issue involves visibility, as the automatic movement of containers by Kubernetes can hide configuration issues and errors, and the deployment of compromised container images can cause serious security breaches if they are not identified and patched immediately. The complexity of the system also creates problems with clarity on access privileges and permissions, as developers may accidentally be granted rights to data, they should not be able to access. This coupled with the multitude of configuration points can create vulnerabilities as developers make serious configuration errors, allowing container escapes.
There have been several solutions reiterated this year for securing Kubernetes clusters to protect pods against malicious attackers who seek to take advantage of default configurations that allow them to run malicious operations on the contents of clusters. Experts suggest using a minimalist operating system to prevent malicious operations from being executed from within a pod and securing communication between pods to prevent malware from spreading. Using namespaces for each application within a cluster can also restrict permissions and secure pods. Gaining visibility into the communications within a cluster through the various security tools available for Kubernetes can ensure that a strong monitoring and alert system is in place.
Service mesh security is on the rise
Many organizations have been guilty of switching to containers to avoid the process of having to constantly patch and update, but what they’ve had to realize the hard way is that containers, too, need to be constantly upgraded and secured, and they need to be verified to ensure that they do not contain unpatched vulnerabilities. Instead of exposing themselves to zero-day attacks and risking the deployment of compromised containers by making security patches toward the end of application development, organizations are implementing security policy as code and automating security rules and configurations into the CI/CD pipeline right in the initial stages of development. Container environments and orchestration platforms are also constantly being monitored across the build-ship-run lifecycle to ensure that vulnerabilities are immediately addressed, and compromised containers are quickly isolated.
Service-mesh architectures such as Istio and Linkerd are being adopted by organizations as a means of abstracting networks by creating a mesh of proxies that services can use to call on each other. This enhances the visibility and security of the network by enabling the authentication of microservices within an application as well as the encryption of traffic between services. By weaving security into their service-mesh architecture, organizations are automating monitoring reports that will alert them if a malicious actor attempts to infiltrate a container or orchestration platform and execute malicious operations.
Cloud 2.0 means attacks are set to increase
Hackers have not left unnoticed the poor security practices of organizations migrating to cloud-based development and production environments en masse, as many organizations have demonstrated a willingness to sacrifice security for agility. However, as attacks have been increasing and vulnerabilities are being discovered and patched, organizations are learning the hard way that security needs to be an integral part of their shift to Cloud 2.0. As container-based microservices architectures are implemented by organizations, the attack surface will only increase. DevOps teams that fail to integrate security into their service meshes will be scrambling to tackle breaches such as when Tesla’s public cloud in 2018 was found to have cryptomining containers deployed by Kubernetes or when a cryptojacking worm nicknamed Graboid was found in over 2,000 unsecured Docker hosts this year.
There are security experts who surmise that the vulnerabilities of containerized environments will cascade until the system crashes, leaving the fast-growing Kubernetes and Docker obsolete in the near future as the infrastructure proves to be more of a liability than an asset. However, IT professionals who recognize the potential of containers in the DevOps pipeline and are able to take a mature, security-first approach to container adoption can reap the benefits of the reduced overhead and agility offered by the innovation.