{"id":22194,"date":"2024-01-11T10:00:00","date_gmt":"2024-01-11T09:00:00","guid":{"rendered":"https:\/\/www.riskinsight-wavestone.com\/?p=22194"},"modified":"2024-01-05T17:38:23","modified_gmt":"2024-01-05T16:38:23","slug":"safe-sailing-step-by-step-container-security","status":"publish","type":"post","link":"https:\/\/www.riskinsight-wavestone.com\/en\/2024\/01\/safe-sailing-step-by-step-container-security\/","title":{"rendered":"Safe sailing: step-by-step container security\u00a0"},"content":{"rendered":"\n

Containers represent an opportunity for rapid, flexible, and efficient application deployment.\u00a0<\/span>\u00a0<\/span><\/p>\n

In 2019, 84% of production infrastructures were already using containers[1]<\/a>. As it is often the case, this massive adoption has taken place without the integration of Cybersecurity teams, sometimes out of ignorance of the technology, and sometimes out of a vision of simplicity and efficiency for development teams.<\/span>\u00a0<\/span><\/p>\n

The need to secure containers is greater than ever, and it’s time for Cyber teams to understand the technology and define the right security measures.<\/span><\/b>\u00a0<\/span><\/p>\n

We’ll start with a comparison between containers and virtual machines, then look back at the reasons for the emergence of containers. We’ll then look at how to secure them throughout their lifecycle, <\/span>step by step<\/span><\/b>.<\/span>\u00a0<\/span><\/p>\n

\u00a0<\/span><\/p>\n

Virtual machine, container: what’s the difference?<\/span>\u00a0<\/span><\/h1>\n

But why choose a container? To understand this, we first need to look at the difference between a virtual machine and a container.<\/span>\u00a0<\/span><\/p>\n

The main difference between a VM (Virtual Machine) and a container lies in the elements included in the virtualized space. A container contains only the applications and dependencies required to run it, whereas a VM will contain an operating system on which one or more applications will be installed. As a container has no operating system of its own, it relies on the one of the hosts on which it runs on. This distinction makes for greater lightness and complexity.<\/span>\u00a0<\/span><\/p>\n

\"\"<\/span><\/p>\n

So why use containers at all?\u00a0<\/span>\u00a0<\/span><\/h2>\n

Containers were not developed to <\/span>enhance security, but rather for infrastructure purposes<\/span><\/b>. The main advantages are:<\/span>\u00a0<\/span><\/p>\n

– <\/span>Consistency<\/span><\/b>: containers can be launched on any machine and will operate in the same way.<\/span>\u00a0<\/span><\/p>\n

– <\/span>Economy<\/span><\/b>: containers are faster and require fewer resources than VMs, so they cost less.<\/span>\u00a0<\/span><\/p>\n

– <\/span>Automation<\/span><\/b>: it’s much easier to automate the deployment of a container than the creation of a virtual machine (Cloud technologies have come a long way in this respect).<\/span>\u00a0<\/span><\/p>\n

These three advantages, combined with the popularization of the DevOps approach within companies, have led to an explosion in the use of containers. Without being side-lined, security has not been an objective in the design of containers. As a result, good security practices have been put in place as the technology has been developed and used.<\/span>\u00a0<\/span><\/p>\n

\u00a0<\/span><\/p>\n

Execution models<\/span>\u00a0<\/span><\/h2>\n

\u00a0<\/span>The advantages of containers are linked to a specific mode of operation based on very specific execution kinematics. Let’s take a look at container execution models.<\/span>\u00a0<\/span><\/p>\n

A container can be <\/span>run on an on-premise or cloud-hosted machine<\/span><\/b>. As explained above, a container contains only an application and its dependencies. It has no operating system, and thus relies on the host’s functionality. Consequently, a container requiring Linux functionality will need to run on a machine with a Linux operating system. Conversely, a container requiring Windows functionality will run on a Windows machine. However, virtualisation processes, such as Hyper-V for Windows, make it possible to overcome these constraints.<\/span>\u00a0<\/span><\/p>\n

To run a container on a machine, you simply need to install container management software (a container runtime). Among container platforms, Docker, lxd and Containerd are the most widely used.<\/span>\u00a0<\/span><\/p>\n

\u00a0<\/span>This makes it easy to run a single container on a machine. However, companies often have a large number of applications. The problem then arises of managing and scaling the containers to be deployed.\u00a0<\/span>\u00a0<\/span><\/p>\n

This is where <\/span>container orchestrators<\/span><\/b> come in. An orchestrator makes it easy to manage the deployment, monitoring, lifecycle, scaling and networking of containers. These orchestrators can be configured on <\/span>on-premise machines or through services made available by Cloud providers<\/span><\/b>. In the latter case, they are easy to set up and configure, as they are managed by the Cloud provider. The most widely used orchestrator technology in companies is Kubernetes. There are also a number of products based on it, such as OpenShift. Other alternatives, such as Docker Swarn, also enable orchestration.\u00a0<\/span>\u00a0<\/span><\/p>\n

\u00a0<\/span>In some cases, there may be a need to manage and scale containers, all without managing the infrastructure. For this purpose<\/span>, Cloud providers have made available services that enable containers to be run in a managed way<\/span><\/b>. All the user has to do is specify a few configuration points. This type of service is called CaaS (Container as a Service).<\/span>\u00a0<\/span><\/p>\n

The following infographic summarizes the execution models and the names of the technologies or services:\u00a0<\/span>\u00a0<\/span><\/p>\n

\"\"\u202f<\/span>\u00a0<\/span><\/p>\n

This wide variety of deployment modes means that the container can be adapted to suit business needs. It’s important to remember that the <\/span>security of a container at runtime also depends on the security of its infrastructure.<\/span><\/b>\u00a0<\/span><\/p>\n

\u00a0<\/span><\/p>\n

Focus on the <\/span>Kubernetes<\/span><\/i> orchestrator\u00a0<\/span>\u00a0<\/span><\/h1>\n

As previously stated, Kubernetes and products based on this technology for orchestration are the most widespread. Kubernetes will be used to illustrate how an orchestrator works. To put it simply, let’s take the analogy of a container port.<\/span>\u00a0<\/span><\/p>\n

\"\"<\/span><\/p>\n

\u00a0<\/p>\n

Let’s start with the <\/span>worker nodes<\/span><\/b>. These will be our <\/span>container ships<\/span><\/b>. Their role is to carry the load, i.e., to execute the orchestrator’s containers.<\/span>\u00a0<\/span><\/p>\n

Kubernetes then introduces the concept of <\/span>pods<\/span><\/b>. A <\/span>pod will be the containers<\/span><\/b> on the ships. A <\/span>pod is generally made up of a single container<\/span><\/b>. It is this component that runs the application to be deployed.<\/span>\u00a0<\/span><\/p>\n

Next, we have the <\/span>control plane, made up of master nodes<\/span><\/b>. These are represented by the <\/span>cranes<\/span><\/b> that dispatch the containers from one boat to another, according to the load each boat can accommodate. In Kubernetes technical terms, the master node will decide on which worker node(s) to execute pods. The <\/span>master node is the cluster’s central point<\/span><\/b>. It contains all the cluster’s intelligence. It’s also with this node that we interact to administer the cluster, and it’s with this node that the worker nodes interact to know what actions to perform according to the pods they’re executing (create new ones, destroy them…).<\/span>\u00a0<\/span><\/p>\n

Finally, there’s a <\/span>load balancer<\/span><\/b>, represented in this analogy by the trucks carrying the containers. The load balancer distributes the load of incoming flows between pods. For example, if three pods are hosting the same application, the load balancer will distribute requests between the 3 pods, so as not to overload any one of them. The load balancer is the interface between the cluster and the outside world, just as trucks are the link to the outside of the port.<\/span>\u00a0<\/span><\/p>\n

Here is a more traditional technical diagram showing the various components:<\/span>\u00a0<\/span><\/p>\n

\"\"<\/p>\n

\u00a0<\/p>\n

\u00a0<\/span><\/p>\n

How can we secure containers at every stage of their lifecycle?<\/span>\u00a0<\/span><\/h1>\n

Now that we’ve covered the basics, let’s take a look at how to secure it all. Security must be applied to every stage of a container’s lifecycle. Indeed, each stage presents its own challenges and associated security impacts. \u202f<\/span>\u00a0<\/span><\/p>\n

\"\"<\/p>\n

\u00a0<\/p>\n

The image is first built<\/span>\u00a0<\/span><\/h2>\n

The first step in the container lifecycle is to <\/span>choose a base image<\/span><\/b>. A container image is a set of lightweight software and files that includes everything needed to run an application: code, runtime, system tools, system libraries and parameters. In most cases, this image is retrieved from the Internet. There is therefore a risk of using an image from an unknown source that has already been compromised (with a backdoor, for example).\u00a0<\/span>\u00a0<\/span><\/p>\n

So, in this first stage, it’s vital to choose the source of your image carefully, to ensure that you take a “trusted image”. This can be achieved by using reference sources such as Docker Hub, or by creating your own image catalogue. In the latter case, the images are verified and validated upstream by the company’s security teams and are known as “golden images”.<\/span>\u00a0<\/span><\/p>\n

The second step is to <\/span>install an application on the image<\/span><\/b>. There is therefore a classic risk of a vulnerability in the application code. Vulnerability scans, developer awareness and adherence to good development practices are essential here to prevent a vulnerability from creeping into the application code.\u00a0<\/span>\u00a0<\/span><\/p>\n

The third step is <\/span>image configuration<\/span><\/b>. These are default configurations applied when containers are deployed. For example, a <\/span>container is run<\/span><\/b> with the <\/span>root<\/span><\/b> (or system administrator) account <\/span>by default<\/span><\/b>: leaving this <\/span>configuration unchanged represents a risk <\/span><\/b>should the container be compromised. Furthermore, setting the container’s <\/span>file system<\/span><\/b> to <\/span>read-only<\/span><\/b> also limits the impact of a compromise. Indeed, with these two configurations, an attacker will have less free rein for his actions.<\/span>\u00a0<\/span><\/p>\n

\u00a0<\/span><\/p>\n

The image is then stored in a container repository<\/span>\u00a0<\/span><\/h2>\n

Once the image has been built, it needs to be stored so that it can be accessed and deployed as many times as required. To do this, we use a container repository, which also needs to be secured. Indeed, if an attacker pushes a corrupted image into the container repository, it can be deployed in production.<\/span>\u00a0<\/span><\/p>\n

Several security measures can be implemented to secure the container repository:<\/span>\u00a0<\/span><\/p>\n

The following resource from the Kubernetes documentation describes the set of components.[2]<\/a><\/span><\/p>\n