Traditionally, discussions of IT security have focused largely on the network with less planning put into application security. Organizations spend large amounts of money on firewalls and Intruder Prevention Systems in an effort to keep the bad guys out. IT pros also spend time scrutinizing audit logs and monitoring alerting mechanisms in an effort to detect any attempts at a security breach.
While these types of activities are undeniably important, they tend to be inadequate in a containerized environment. The reason for this is that network-related security measures tend to focus on the lower layers of the OSI stack. While containerized environments do of course utilize these layers, containerized environments place a large emphasis on Layer 7, the application layer. As such, any attempt at hardening a containerized environment must address the application layer of the OSI stack, not just those layers related to low-level network communications.
Why Application Security is Important
Containers are different from competing technologies such as virtual machines. Unlike a virtual machine, which includes an operating system, drivers, and one or more applications, a container will usually only include a single application. This application cannot function without an operating system, so it shares an OS kernel with other containers that may be running on the system.
In many ways, the container architecture lends itself well to the system’s overall security. While it is true that containers provide process-level isolation, which is not quite as secure as the full OS-level isolation that can be achieved using virtual machines, containers help with security in other ways.
Because numerous containers can share a common OS kernel, containerized applications are not allowed to write to the kernel. Instead, write operations are directed to a thin, read/write layer that is specific to the container. This ensures that the kernel remains in pristine condition, and cannot be compromised by malicious activity within a container.
Furthermore, containers tend to have relatively short lifespans. Unlike virtual machines, which may exist for years, containers are designed to be highly dynamic. Containers can be created or deployed on a whim. In fact, some organizations have adopted a policy of destroying containers every few hours, and replacing those containers with new containers that have been spun up from a known good container image. This helps to ensure that any unauthorized modifications to a container are short-lived.
The point is that the container architecture is relatively secure. The greatest potential for a security breach often lies in the containerized applications.
As previously noted, a containerized application cannot modify the underlying kernel, and it should not be able to cause harm to other containers. The problem with thinking about container security in this way, however, is that the inability of an attacker to modify the OS kernel or to modify another container is attributed to storage isolation. But containers do not provide network isolation. As such, an attacker could conceivably take control of a container, and then use that container as a platform for launching a network-based attack against other resources.
In order for such an attack to be successful, an attacker would most likely need to find a way of compromising the application (or process) that is running within a container. For example, a containerized web server most likely communicates with a backend database running in a separate container or virtual machine. If an attacker can exploit a vulnerability within the web server application, then they might be able to gain access to the database, or other network resources. Since there are often numerous web server containers that collectively act as a Web front-end, an attacker might even be able to use all of those web server containers to stage a Distributed Denial of Service attack.
How to Secure Your Applications
Unfortunately, there is no magic formula for application security. Every application is different, and a security technique that works for one application might be inadequate (or even harmful) for another application. Even so, there are some best practices that you can adhere to.
First, check with the application vendor to see if they have any security recommendations. Many application vendors will publish a set of security best practices that are specific to their application.
You should also make sure that you are using the latest stable version of an application. Applications are often updated in response to vulnerabilities that have been detected. If you neglect to update an application, then you may be running an application that contains a well- documented (and therefore easily exploitable) security vulnerability.
Finally, ensure that your container images include only those components that are absolutely necessary for running the application. Any extra services, binaries, etc. can increase the application’s attack surface which decreases application security.
