What Are Containers?

A container is a technology that allows packaging up code and isolating it with its dependencies using container runtime software. By packaging the application code and its dependencies, the container runtime creates a container image. A running image is a container. The starting point for building a custom container image is a base image (like Alpine Linux) usually created by vendors or communities and uploaded to an image registry.

Some container runtime software is compatible with Linux and Windows, making the containers cross-platform. Containers isolate the software from the environment and make it run identically despite the differences in the environment, for example, staging and production. Containers are flexible, portable, and easy to deploy compared to VMs that use a full OS version each (Docker, Unknown Date, ref. 1).

The most popular container technology is Docker. It became the synonym for containers for most people. The goal of the container runtime is to virtualize system resources like filesystem or networking. This is done using Linux namespaces, and the limitation of resources like CPU and memory is done using cgroups (Ian Lewis, 2017, ref.2).

There are two types of container runtimes, low level and high level. The low-level container runtime is responsible for running the container. It sets up the namespaces and cgroups for the containers. The high-level runtime is responsible for managing containers. It creates the container image, pulls it from a registry, and passes it to the low-level runtime.

The Docker engine is a lightweight open-source containerization technology that implements high-level and low-level runtimes. It is combined with a workflow for building and containerizing applications. It can be installed on any operating system.

Container technology was developed over ten years ago for Linux in the form of LXC. Other vendors offer their system virtualization, such as Solaris Containers, FreeBSD jails, and AIX Workload Partitions (Paul Rubens, 2017, ref.3)(Docker, Unknown date, ref.4).

In 2015 a company called CoreOS created its version of containers that could potentially fragment the container industry. They were the competitor of Docker. But the rocket (rkt) runtime from CoreOS is not actively developed anymore. Its last release date is 16 April 2018. The rkt runtime remains a significant piece of the history of container technology (Iucab, 2018, ref. 5).

In the same year, 2015, a Linux Foundation project called Open Container Project, later renamed Open Container Initiative (OCI), was created to define industry standards for the container format and container runtime software for every platform. This project is sponsored by companies like VMware, AWS, Google, Microsoft, Red Hat, Oracle, IBM, HP, Twitter, Docker, and CoreOS. This makes it a considerable authority in defining container technology standards (Paul Rubens, 2017, ref.3).

The starting point for OCI standards was Docker, which donated 5 percent of its codebase to launch this project. This project made companies focus on developing container orchestration tools for existing container technology instead of developing competitive container technologies. Currently, several companies compete with each other in developing orchestration tools. However, they respect OCI standards, meaning a container will run identically on any orchestration tool (Paul Rubens, 2017, ref.3).

Container advantages are:

• Cross-platform compatibility;
• Use lower resources in comparison with VMs (ex: storage, computing power);
• Boot faster with the application than VMs;
• They can be destroyed quickly, freeing up resources for their host (Paul Rubens, 2017, ref.3);
• They allow for modularity. Instead of running an entire application in a container, it can be split into multiple containers. A web application can be split into a database, front end, and back end container. The application is divided into microservices. It makes making changes to the application easier because only the changed component should be rebuilt.

Container disadvantages are:

• If the host kernel is vulnerable, then all the containers are vulnerable;
• Some legacy software is impossible to switch to run in containers. It can run only on VMs or on a host OS. VMs consume more resources compared to containers;
• Containers provide less isolation compared to VMs because they share the host kernel.

It was agreed with the company mentor that the research would be focused on Docker containers because they are more popular and relevant to include in container security training.

Containers are usually run in a container orchestration environment. Its goal is to automate the containers’ deployment, scalability, monitoring, and management. Orchestration is essential for individuals and companies running multiple containers simultaneously because it is almost impossible to manage them manually. There are many vendors of container orchestration tools, but the most popular is Kubernetes. It is an open-source tool initially designed by Google to manage its infrastructure. Now it is maintained by Cloud Native Computing Foundation.

In the image below, a more detailed architecture of a Kubernetes cluster and how each component is communicating with each other can be found:

A Kubernetes cluster comprises a master node and multiple worker nodes, where all the workloads are hosted. The master node serves as a management node. It can also host workloads, but it is considered a bad practice. If the workload on the master node is compromised, it is a high probability that the whole cluster will also be compromised.

Kubernetes Components

1. Kubectl is a bash tool that is used to communicate to the API server of Kubernetes and manage the cluster;

2. API Server is a RESTful web server that handles the management of the whole cluster. Moreover, it collects the requests from the client that are authenticated, authorized, processed, and then stored in ETCD for further processing and use;

3. ETCD is a key-value store that stores the most sensitive data within the cluster. Access to it should be restricted only to as few users as possible. Full access to ETCD is considered root access to the cluster;

4. Controller Manager is a daemon that listens to specific updates in the API Server and runs controllers within the cluster that keeps its state consistent;

5. The scheduler is a component that “listens” to pod creation requests on the API Server, reviews the node list for potential resource allocation, and sends the request to Kubelet;

6. Kubelet is a worker component that takes care of the pod creation, logging, and its status. It is also the endpoint that API Server calls to get the status and logs of the pods;

7. Kube-proxy is a component that, along with Container Networking Interface (CNI), makes sure that all containers, Pods, and nodes can communicate with each other as if they were on a single network;

8. Docker is explained in the paragraphs above;

9. A Pod is a group of one or more containers that share the same storage and network;

10. The container is explained in the paragraphs above.

References/Literature list

[1] Docker (Unknown Date), “What is a Container”, Retrieved from https://www.docker.com/resources/what-container

[2] Ian Lewis (06.12.2017), “Container Runtimes Part 1: An Introduction to Container Runtimes”, Retrieved from  https://www.ianlewis.org/en/container-runtimes-part-1-introduction-container-r

[3] Paul Rubens (27.06.2017), “What are containers and why do you need them?”, Retrieved from https://www.cio.com/article/2924995/what-are-containers-and-why-do-you-need-them.html

[4] Docker (Unknown Date), “About Docker Engine”, Retrieved from  https://docs.docker.com/engine/

[5] Iucab (16.04.2018), “Realises rkt”, Retrieved from https://github.com/rkt/rkt/releases