Container Security is the use of security tools and policies to protect containers from threats. Container security differs from traditional security because the container environment is more complex and ephemeral, and therefore the process of securing containers is continuous.
What Is a Container?
A container is a package of software and its dependencies — such as code, system tools, settings and libraries — that can run reliably on any operating system and infrastructure. A container consists of an entire runtime environment, enabling applications to move between a variety of computing environments, such as from a physical machine to the cloud, or from a developer’s test environment to staging and then production. Containers are a useful tool, but they are not built with a security system of their own, meaning they introduce new attack surfaces that can put the organization at risk.
Container technology solves the problems that arise from virtualization. In virtualization, virtual machines isolate applications from each other. Each application is provided with CPU, memory and other resources by a host operating system called a “hypervisor,” which functions as if it is running on its own physical server. Provisioning virtual machines takes a lot of time, and once up and running, they don’t use system resources efficiently.
Instead of virtualizing hardware, container technology virtualizes software. So instead of providing a virtual server to an application, the application has its own virtual operating system. This approach enables better control of resources, since resource limitations can be imposed on each containerized app, and all containers can run completely independently from the dozens or hundreds of other containers running in the same environment.
These benefits, along with the need to run apps in hybrid cloud/on-premises environments, as well as the increased demand for computing resources due to the rise in remote work, are driving containers into the IT mainstream.
Of course, with greater adoption comes greater risk. More enterprises are deploying more containers, often without always securing them properly.
Want to Stay Ahead of Adversaries?
Download the 2020 Global Threat Report to uncover trends in attackers’ ever-evolving tactics, techniques, and procedures that our teams observed this past year.Download Now
What Are the Core Elements of Cloud Security?
Cloud Security Posture Management (CSPM)
CSPM is a set of tools and practices used to monitor and automate the management of cloud security risks. CSPM solutions provide visibility across connected enterprises and encompass containers, Kubernetes and serverless functions.
Cloud Workload Protection (CWP)
A cloud workload is the application or service processed by a remote server at any time. The workload can be a container or it can be a web server, database, etc. CWP helps secure these workloads at the host level by providing visibility into the container environment while protecting the workload at runtime.
Cloud Access Security Brokers (CASB)
Cloud access security brokers are software that resides between cloud service users and cloud applications to monitor activity and enforce security policies. CASBs can be used on-premises or in the cloud.
What Are the Common Cloud Container Platforms?
Containers are suited for cloud environments because they deliver more services on the same infrastructure as hypervisors, which makes them more economical and faster to deploy.
There are many approaches to containerization, and a lot of products and services have sprung up to make them easier to use. These are the most popular platforms that are relevant to container technology:
- Docker: Docker is a container platform that lets users build, test and deploy applications quickly. As the pioneer in its sector, Docker runs on about one of every five hosts and has over 5 million users and 6 million repositories on Docker Hub.
- Kubernetes: Kubernetes is a portable, extensible, open-source platform for orchestrating containerized workloads and services. Unlike Docker, which runs on a single node, Kubernetes uses automation to orchestrate container management to run across a cluster.
- AWS Elastic Container Service (ECS): Amazon ECS is a scalable container orchestration service that runs Docker containers on the AWS cloud. It lets users run ECS clusters with AWS Fargate, a serverless compute that removes the need to provision and manage servers, and integrates natively with other AWS services as well.
- Microsoft Azure Kubernetes Services (AKS): AKS is the new version of Azure Container Service. AKS simplifies Kubernetes management, deployment and operations with serverless Kubernetes, an integrated continuous integration and continuous delivery (CI/CD) experience, and enterprise-grade security and governance.
- Google Cloud Platform (GCP): Google Cloud Platform enables users to migrate quickly with pre-packaged cloud infrastructure solutions in hybrid and multi-cloud environments with no vendor lock-in.
Challenges of Container Security
Containers do not include security capabilities and can present some unique security challenges.
The primary challenge is visibility. Visibility is the ability to “see” into a system to understand if the controls are working and to identify and mitigate vulnerabilities. Containers can lack centralized control, so overall visibility is limited, and it can be hard to tell if an event was generated by the container or its host. And because containers are short-lived, forensic evidence is lost when they are terminated.
It can be difficult for enterprises to know if a container has been designed securely. Typically, the IT team receives a container from a development team, which most likely was built using software from other sources, and that other software was built using yet another software, and so on. Unless security was documented in the development and the container’s user has access to that documentation, it is reasonable to assume that the container is insecure.
A Set and Forget Mentality
Another container management pitfall is that managers often utilize a containers a “set and forget” mentality. But like any other part of the computer environment, containers should be monitored for suspicious activities, misconfigurations, overly permissive access levels and insecure software components (such as libraries, frameworks, etc.). What was secure yesterday is not guaranteed to be secure today.
Some enterprises do a good job of subjecting their containers to security controls. And that responsible approach gives rise to a new set of problems: Every vulnerability scan produces a massive volume of results that have to be sorted, prioritized and mitigated. Teams that still rely on manual processes in any phase of their incident response can’t handle the load that containers drop onto them.
Traditional tools mostly focus on either network security or workload security. But securing containers requires attention to both, since hosts, networks and endpoints are all part of a container’s attack surface, and vulnerabilities exist in multiple layers of the architecture.
The Anatomy of Container Security
Container security can be thought of in three layers: kernel, images and runtime.
Containers isolate resources into namespaces. A namespace is an abstraction that “tells” the processes inside it that they have their own isolated instances of a resource that is, in reality, a global resource. Namespaces can be exploited to escalate privileges inside the namespace and effect kernel-based vulnerabilities.
Container images are layers of files built onto a base image. Images include libraries, tools and settings necessary for containers to run on containerization platforms (like Docker) and include executable code that lets the container run in isolation from the rest of the environment. An image shares the operating system of the container’s host’s kernel. During an image’s build phase, secrets may be leaked into the image in the form of variables — and these secrets will remain exposed in the image history. Also during the build phase, the content can be modified maliciously. To mitigate risk, only use signed base images from trusted sources. Also, consider encrypting the layers and using a locally stored key to decrypt at runtime.
In the general vocabulary of computers, runtime is the hardware and software that supports the running of an application’s code. In relation to containers, runtime includes consuming the container mount and metadata provided by the container engine, communicating with the kernel, and setting up policies. Container runtimes increase the attack surface because they add potentially vulnerable code onto the technology stack. Securing runtime is challenging because containers come with a lot of options that aren’t configured by default, so misconfigurations are a serious concern.
How To Establish a Container Security Policy
As containers enter the mainstream of enterprise IT, best practices are emerging with them. A helpful starting point to establishing a container security policy is NIST Special Publication 800-190: Application Container Security Guide.
Developing a container security policy is an in-depth endeavor. Here are some fundamental principles that should be foundational in any enterprise:
- Choose a cloud-native solution
- Use automated vulnerability scanning
- Only allow use of images from trusted sources
- Avoid mixing containers associated with sensitive data with containers associated with non-sensitive data
- Use container-specific host operating systems to reduce attack surfaces
- Monitor container runtimes for vulnerabilities
- Ensure containers are included in the patch program
- Ensure strong authentication and authorization controls are in place
The CrowdStike Falcon® platform offers security teams the ability to manage CSPM, CWP and container security, all from one platform. Learn more about how the Falcon platform delivers container security.