Container technology has been around in UNIX since the late 1970s, but is now typically found in cloud native applications, which have become leading drivers of enterprise IT innovation and digital transformation.
The term “cloud native” refers to an approach of transforming monolithic applications to microservices architectures, running services as containers in the cloud. This rapid adoption of containerized applications is driven by the allure of benefits such as increased speed, agility, scalability, lower cost, and the portability between an on-premises datacenter, private/public cloud, and hybrid cloud environments.
Cloud Native Poses New and Unique Security Challenges.
However, along with these advantages, cloud-native applications introduce significant security and compliance challenges. The cloud native approach changes how software is built, deployed, and run, which fundamentally changes how software and systems need to be protected and tested.
One of the more popular ways containers are deployed and run is within an open-source orchestration system called Kubernetes. Also referred to as “K8S,” Kubernetes is described as a “platform for managing containerized workloads and services that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem.”
That growth creates a significant problem. The latest State of Container and Kubernetes Security Report from StackRox shows that “94% of responders have experienced a security incident in their Kubernetes and container environments during the last 12 months.” According to this report, the number one security issue detected is a misconfiguration, followed by security incidents occurring during a runtime.
As the number of containers running on a system grows, so does the likelihood that one of the contained applications has a flaw that could lead to a breach, allowing container breakout. A common misconception about containers is security versus process isolation. Unlike virtual machine (VM) technology, which virtualizes the hardware and provides each VM with its own instance of an operating system, containers virtualize the operating system, providing applications namespace and memory allocation. Since the containers run on top of the underlying host and operating system, they will most likely be compromised if the host and OS are compromised.
Another security concern is risk of legacy applications being converted as-is without considering best practices, configurations, and security settings. While the containers provide a level of resource and process isolation, the fact remains that a process running as root within a container is running as root on the host system, in direct communication with kernel subsystems and devices.
Are There Best Practices to Secure Container Builds and Deployments?
The cloud-native approach requires a culture change, just adopting new technologies with the same mindset will not produce desirable results. Everything needs to mature together – the culture, the design, the team, the architecture, the tools and the processes. Closer collaboration between DevOps teams and security teams is necessary. Security cannot be an afterthought; instead, it must be embedded in the CI/CD lifecycle.
Containers and microservices have dramatically altered application development; under the continuous deployment model of application development today, regulatory compliance and auditing can be challenging. Most containers have a short lifespan, running for only days – sometimes even hours or minutes. These short lifetimes and the density of containers deployed make the task of monitoring significantly different from monitoring VM or hardware deployments.
Additionally, security vulnerabilities may lie either within the container or in the host OS, meaning both must be tracked, patched, and audited. Each of these environments generally requires different audit tools and processes, which presents new security and compliance challenges:
-
- Traditional security infrastructure lacks container visibility. Most existing host-based and network security tools do not have the ability to capture container activity.
- Attack surface can change quickly. Cloud-native applications are made up of many microservices that are highly distributed and must be audited individually.
- Logging and monitoring – In order to have a full view of any activities, cloud-native applications require logging at multiple layers, the host, the Docker infrastructure, the Kubernetes infrastructure, and the containers themselves.
- Distributed data flow requires continuous monitoring (ConMon)
- Detection, prevention, and response must be automated
When it comes to cloud native applications, there are no best security practices. We cannot expect to have one solution that will work for every environment. We all have specific use cases and the solution will look different for each one of us. Instead of searching for best practices, we should use cloud-native patterns. Cloud-native patterns are a collection of design decisions about cloud-native practices and technologies and the context in which they work.
In light of the challenges we described, here are some cloud-native patterns to consider:
-
- Implement secure system design at the start of every project. Waiting to implement security in the application or system right before it goes “live” is not an option anymore. Instead, security must be embedded as an integral part of the CI/CD lifecycle. By following this approach we show that security is a high priority and developers are included from the beginning.
- Use workload isolation to isolate critical or risky workloads. Block network traffic with network policies. Limit resource consumption. Specify application-level segmentation policies.
- Harden the host operating system (OS). Patch hosts, only install needed components, segregate containers by data sensitivity, and update the OS regularly. If possible use container-specific host OS, as they have a smaller attack surface. Consider purpose-built OS for hosts and containers.
- Implement role-based access controls (RABC). Assign appropriate roles to appropriate users. Restrict access to only those processes and users who need it.
- Automate testing. Include code scanning and security configuration testing in the development pipeline. This way the team can trust that the delivery process will catch most issues and the changes can flow to production quickly.
- Protect secrets used by containers and do not store secrets in containers. Use a central tool for managing and abstracting secret data from the application.
In addition, consider running containers from different customers or data classification needs in separate hosts for clearer boundaries between VMs. In order to create a more compliant environment, use images from trusted sources, check images for known vulnerabilities, and purchase tools that are purpose-built for native applications. When evaluating new tools, ensure that they integrate with existing ones to minimize the learning curve. Add policy-based scanning that prioritizes compliance concerns. Enforce a collaboration between security and compliance in order to automate workflows and “bake in” compliance as part of the code development.
The rapid adoption and growth of cloud computing services – both cloud-native applications and container technology – will continue to grow in popularity and capability. Security practitioners will be challenged to keep pace, but by building on lessons from the past, and working with our development teams’ processes and tools, we can build security into architecture and containers that power our modern applications.
