One can hardly ignore the surge in containers. For perhaps the first time, a technology is able to deliver on two paradigms at the same time: microsservives and devops. The microservice pattern allows applications to be broken into smaller, loosely coupled, autonomous parts so they can be managed and deployed independently of one another. This allows software to be deployed more often and quicker. DevOps is the process for delivering these kinds of service and containers are the vehicle.
Containers are generally considered to be more secure than their virtual machine counterparts, but like all technology, it comes with its own set of risks. Security analyst have noted as possible a number attack vectors. Generally speaking, these can be grouped into attacks on the container host and attacks on the containers themselves. On the container host side, some possible attacks might be kernel attacks and attacks against the container engine itself, while on the container side the attacks may exploit vulnerabilities in the containers or the images used to build containers.
IT pros and developers should be vigilant to ensure that any container environment and the containers it runs are secure. Here are 14 tips for security containers.
- Use Trusted Container as a Service Platform. Containers as a Service (CaaS) provides a platform for running containers such that the user does not have to maintain the environment. Rather, it is patched, monitored and maintained the staff of the service provider.
- Use Official, Purpose-Built, Lean Images. Public repositories like Docker Hub contain thousands upon thousands of images for almost every kind of software imaginable. However, most of these images are the work of users who published an image and have not maintained or patched it. Docker Hub does mark some images as “official” images. These images are provided and vetted by software makers who provide fresh updates to these images and multiple version of the image.Repositories have a number of official, more general purpose images like CentOS or Ubuntu that provide images with their respective package managers installed in the images. User can then pull the image and provision the image using the integrated package manger. Other images are more tailored to suit the needs of an application or may be a complete application themselves. Docker Hub provides purpose built images for software based on many popular open source platforms like NodeJS, PHP, and Python and complete applications like WordPress, MySQL, or Redis.Most images that are purpose built are lean because they only contain the bare minimum software to run a given app. In some cases, though, there are versions of these images available that contain extra software or are built on a particular operating system distribution that contains extra utilities and libraries. A common mistake container users make when they start deploying containers is to treat them the same as virtual machine, and install all the system utilities that were installed on a virtual machine in the container such as an SSH server or text editor. While this is possible, it does come with risks because these utilities have to be set up and maintained alongside of the software included in the container and it also creates a larger attack surface for the container.
- Persist Data Outside of Containers. Container engines often provide a way to mount volumes at any arbitrary point in the containers file system. Mounting persisted data such as database files, non-application or user files, and configuration files on volumes outside the container mitigates risks against it accidently being deleted or shared.
- Adhere to the Single Responsibility Principle. The Single Responsibility Principle (SRP) says that any component of a software application should only be responsible for one part of the functionality of an application. In containers, this means not installing more than one component of an application in a container. For example, suppose and application needs a cache service, database service, and a web server to run. While it is possible to install all these components in a single container
- Refresh Containers on Tighter Patch Cycles. Containers by design are meant disposable, implying that container users should not actually be patching existing containers. Users should create newly patched images and deploy these as new containers
- Implement Security Best Practices for Applications. In addition to securing containers themselves, users should harden applications according to the software provider’s recommendation.
- Use Containers for Applications Only. Containers can run all kinds of software but their primary purpose is to run applications. Users may be tempted to containerize and run network infrastructure components such as browsing proxies, virtual routers, NAS, SAN, or other storage solutions. Containers can provide front-ends for these components, however the storage or functionality provided by these components should be on the appropriate network appliances.
- Never Run Containers in Elevated Mode. Container engines usually provide a way that allows containers to be run with elevated permissions, usually as root on the host operating system. This opens up the container host to possible attacks from within a container itself by substantially lowering the threshold between the container and the container host.
- Use Application Gateways/Firewalls. While containers and container engines attempt to be secure by default, they don’t inherently provide any edge security. Containers themselves therefore should not be exposed to the internet without traffic first passing through some sort of edge protection. Application gateways/firewalls are security appliances (either physical or virtual) that provided unified threat management purpose built for applications. These devices provide a whole host of security features that all applications behind them can benefit from. Some common features include data scrubbing to remove PCI data, SSL inspection to mitigate man-in-the-middle attacks, ID federation and two-factor authentication, JSON and XML schema validation, virus and malware detection, real time risk monitoring, connection throttling to mitigate DDoS, URL mangling prevention, HTTP header inspection, and injection prevention for OS and SQL.
- Use a SIEM Solution to Monitor Containers. Security Information and Event Management (SIEM) solutions are usually part of a Security as a Service offering from security vendors. These solutions aggregate logs and other data from an environment and apply heuristics based, correlative analysis to this data to detect anomalous behaviors on a network to protect against real-time and zero-day attacks. SIEM solutions also provide tools and analysis for security forensics to that policies can be created on Application Gateways to help mitigate against future attacks on an environment. Setting up a SIEM requires log information from services such as databases, web servers, proxies, and operating systems, so consideration needs to be taken into account about how logs persisted when using containers.