Container deployment (particularly at the enterprise level) present questions around scale not seen with traditional monolithic software deployments. How do these scale-related issues affect security, and what can you do to meet the scale-based security challenges of containers?
Keep reading for a discussion of security considerations in highly scalable containerized environments.
Security and Monolithic Applications
First, let’s take a quick look at the basic security challenges of a traditional monolithic enterprise-level application. Typically, such an application would present three basic types of attack surface: the vulnerabilities of underlying server hardware, the vulnerabilities of the operating system and network software, and the attack surfaces of the application itself.
Generic Attack Surfaces
The first two sets of vulnerabilities can be regarded in many ways as generic and publicly available, since they are likely to be based on known and widely used hardware and software. An operating system exploit potentially affects everyone who uses that OS, and the range of methods for protecting against it are likely to be similar for most users. Security at the hardware and OS/network levels is often a matter of applying known and available preventive/monitoring measures, patches, and precautions.
Unique Attack Surfaces
The attack surfaces presented by the monolithic application itself, however, are more likely to be particular to that application. They have a greater chance arising from specific elements of the application’s architecture, or from peculiarities of the code. This doesn’t mean that monolithic applications are immune to generic or semi-generic attacks, of course; exploits that involve such things as buffer overflow in sloppily designed or implemented code can be very effective, as can attacks against known vulnerabilities in commercial or open source software components. But the presence or nature of such vulnerabilities may not be easy for an attacker to determine or predict.
A Monolith is a Monolith
The attack surfaces of such an application are likely to be further limited by its monolithic nature. Even if it is organized into discrete components, those components are likely to be fairly large-scale. Much, if not all, of what goes on inside the program will occur within the application boundary—another reason why buffer overflows and malformed data exploits have been common points of entry into monolithic apps.
Containers and Security
With containers, while some of the vulnerabilities and challenges remain the same (server hardware and host operating systems/networks remain vulnerable, although the abstraction built into cloud deployment makes for a very different host-system security picture for all deployments, whether container-based or monolithic), the overall security picture for large-scale container deployments is in many ways quite different at the application level.
Why is this?
Boundaries that Are Not Boundaries
Perhaps the most fundamental difference between a container-based and monolithic application lies in the nature of the application boundary itself. In a monolithic application, that boundary is generally well-defined, and much of the data remains clearly within that boundary, even when it is being passed from one service to another.
Container-based applications, on the other hand, are generally broken down into microservices, with each microservice (or set of closely related microservices) in its own container. Data is passed between containers, typically within a defined and protected control group and namespace.
Control groups and namespaces, however (even in the more sophisticated versions found in Docker and other container management systems), are not application boundaries. They are basic security elements built into Linux in order to restrict access from and to groups of discrete components and resources, and as such, they have the same potential vulnerabilities as any operating system components. In other words, containers replace the overall application boundary with a boundary defined and managed by generic infrastructure.
Different Attack Surface Topology
Each container is small, of course, and the number of attack surfaces that it presents is likely to be much, much smaller than that of a monolithic application. The cumulative number of attack surfaces from all discrete types of containers in an application, however, may be quite large— larger, in fact, than that of an equivalent monolithic application, if you take into account communication within the container application’s namespace.
Containers as Moving Targets
On the other hand, containers are not designed to be persistent, and in practice, they are often quite ephemeral. A large-scale container-based application is likely to spawn thousands of copies of the same container, each of which will perform one task or set of tasks, then disappear. This presents attackers with a very unstable and rapidly moving attack surface. Gaining entry into one container may amount to very little, if that container disappears almost immediately, and establishing a permanent foothold within the application itself may be very difficult.
Dig In or Drill Down
Under these circumstances, an attacker’s best strategy may be to either establish a beachhead in some kind of persistent storage, or to drill down to the host OS.
This latter kind of attack, of course, represents one of the key potential vulnerabilities of any container-based application. Unlike virtual machines, containers draw heavily on the host’s resources, relying on cgroup/namespace protection to provide insulation between containers and the kernel. As long as this protection is properly configured and managed, the actual attack surface at the container-host interface should (at least in theory) be relatively limited.
Managing Container Security at Enterprise Scale
The problem, particularly at enterprise scale, is that managing security configurations for thousands of different containers may not be easy. This problem is compounded by the widespread use of pre-made, repository-based container images containing open source code as generic, modular components. Most repositories are scanned for exploits, vulnerabilities, and outdated open source components, but it is all too easy to pull a repository-based or locally stored image that falls seriously short of meeting your application’s security requirements.
A Unified Security Suite
One good attack surface is all it takes—Your application is only as secure as its most vulnerable component. When you are managing an application made up of thousands of different containers, with enterprise assets at stake, the only effective approach to security is to use an overall container security suite such as Twistlock.
It allows you to manage and enforce control group, namespace, and container security policies to control root and kernel resource access, and monitor container behavior. It also allows you to define expected container behavior, and compare observed behavior to those definitions—a kind of granular, microservice level of security which goes beyond typical monolithic application monitoring. And it can enforce container security policies at the image level with in-depth image scanning.
An enterprise-scale container-based application requires an enterprise-level security suite. Given the level of data breach risk in the present-day world, the use of a security service such as Twistlock is not an option, but a necessity.
Get more regular updates on cloud native and container security by signing up for our newsletter, or contact us for a demo today.
- Read The Ultimate Guide to Container Security and learn the ins and outs to securing your containers!
- We announced the General Availability of Twistlock Container Security Suite. Get yours today!
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.