Container Security Overview

Introduction…

Container technology has picked-up in the market with major players viz., Docker, Rkt, LXC etc. This technology resolves quite a few critical Business challenges, by speeding up the time to market of the Software applications and it’s Operations. The Legacy businesses who still use old school Software Development methodologies, would need to adapt to this new phenomenon of developing, deploying and managing the software workloads, to keep up with the ever changing technology landscape. In the below sections, I have tried to highlight security challenges that the Container technology brings in.

Above image is an analogy to compare application containers with the actual physical containers that are used for packaging and shipping goods and also isolating the goods in other containers.

Note: It will be useful if you have some basic knowledge of the Linux namespaces to understand the below container security issues.

What are Application Containers and Why use them?

Container technology is a form of Virtualisation, which aims for efficient usage of the hardware and multi-tenancy. Below definition from the NIST-SP (800-190) guidance, best describes the container technology.

As per NIST guidance (800-190) – Containers provide portable, reusable and automatable way to package and run applications.

What the above definition implies? 

Instead of developing large monolithic applications, it is best advised to split an application into microservices and package each application in it’s own container, so that it can be managed efficiently. By Packaging applications into smaller containers gives the below benefits:

• Portability across different infrastructure viz., various Cloud platforms and On-Premise infrastructure.
• Faster time to market the software i.e., develop, test and release quickly.
• Easy Patching and updates to the OS, Infrastructure and applications.

Brief Overview of the Container Architecture:

Below is the simplistic architecture view of Single-container & Single host architecture for the ease of understanding.

To run an application (say a WordPress website) in a container, one would need to get a relevant WordPress Image from the container Image repository or hub. The first layer in the image is the minimalistic base OS distro viz., Alpine, BusyBox etc., the second layer in the image could be a webserver viz., Nginx, Tomcat etc. and the 3rd layer will be your WordPress application. The container can be hosted on a Virtual machine (node) or directly upon the bare metal (Host OS) depending on your deployment strategy. A Container Runtime mediates the container communications with the Shared Kernel of the Host OS viz., networking, CPU shares etc.

Note: For running a WordPress application you would need to get some database viz., MySQL. There are lots of articles available online for installing WordPress, step by step.

Managing Container Workload: Now for running a desired number of containers to serve your website traffic, you would need to spin-up number of containers and spread the workload across different nodes (Virtual machines). There are few cotnainer workload orchestrators viz., Kubernetes, Redhat OpenShift, Docker Swarm etc., that can manage this better. There is lots that can be written about container orchestration architecture however my focus in this article is on the core container security issues.

So what are the major Architectural components:

1. Container Images
2. Image Repository or Hub
3. Container Runtime layer.
4. Host OS (Kernel, resources etc.)
5. Application (above example your WordPress website)

What are the security issues?

• Inter-Container communication:
  • Although the container technology enables process isolation in between the containers by using namespaces and restricts access by using control groups there are still some challenges around environment misconfiguration which could lead to serious issues viz., data exfiltration, unintended cross container communication etc. There needs to be container aware traffic monitoring i.e., network as well as process to address this issue.
• Container Image Issues:
  • The images used to build containers, use layering concept where there is a base image, on top of which other application specific layers are added i.e., webserver, libraries etc. If the base image has vulnerabilities then your application inherits the same. The base image could have vulnerabilities that are not patched.
  • The image could have been misconfigured which may give a user privileged access.
  • There could be embedded malware in the image which could help exfiltrate data from the compromised container to some malicious destination.
  • To overcome this, the images need to be scanned regularly.
• Container Image Registry Issues:
  • There are quite a few Image registry issues around confidentiality, Integrity and availability viz., registries being tampered, users not Authenticated and/or Authorised, MITM attack against images checked-in to registries over unencrypted channel.
• Web Application Issues:
  • There could be web app issues viz., SQL injection, XSS etc. which could compromise a container and there by whole cluster and the environment.
  • A Vulnerability scanner is advised to iron out the issues right in the development phase.
• Host OS Issues:
  • There could be attacks on the Host OS if containers are misconfigured which could tamper files, databases etc. on the Host OS. Also there are risks to the Shared Kernel.
  • The Host needs to be hardened with minimal access to the containers as per the principle of least privilege.

Summary:

The Container technology provides a great opportunity in the development phase where developers can identify and fix the vulnerabilities as highlighted by the scanning tools. Container Images needs to be vetted before building containers. Applying the principle of least privilege to the containers so that rogue containers cannot join or tamper a cluster. Organisations need to leverage Container monitoring tools for profiling containers i.e., what a good container looks like and alerting suspicious or anomalous traffic around network calls, filesystem changes etc.