The major risks of cloud native security

Introduction

In 2021, the digital data economy represents around 20% of the European stimulus budget, which amounts to 750 billion euros. This economy, based on the algorithms of digital platforms and industry usage data, founds its reality on a range of so-called cloud native technologies.

These technologies are called cloud native because they arise from the cloud service infrastructures that must be considered as a prerequisite. Portability, interoperability and data sharing are the keywords of the underlying virtualized technical architectures. Let's take 5G as an instance. Its strategic challenges are linked to the ability of telecom operators to deploy digital platforms to manage their infrastructure as code, which are the only ones relevant for 5G services. To be convinced of this, the white papers from Ericsson and Nokia and the one from the Rakuten case study should be suitable. Finally, to feel really involved, note that a French telecommunications operator underlined, in December 2020, in its 2020-2025 strategic plan, the crucial importance of these microservice based software applications and infrastructure as code, for 5G, with the aim to guarantee its competitiveness. These technologies are not innovative, but essential. They are resilient and trusted. The cloud native computing foundation exposes a huge catalog. The technological solutions implemented are called, in 2021: Git, Helm, Argo, Kubernetes, Kube Edge, Harbor, Falco. The GitHub developer community, created in 2008, has over 68 million users. Docker Hub, created in 2013, offers a library of over 100,000 container images. Remember that a container is a small virtual machine, with a full runtime environment for software application, which must be plugged into a host operating system in order to operate. Netflix, created in 1997, has more than 600 services in production and deploys 100 times per day; Uber, created in 2009, has more than 1000 services and deploys several thousand times a week; WeChat, established in 2011, has around 3,000 services in production and deploys 1,000 times per day. So, agility and DevOps practices represent the daily life of engineers. Automation, artificial intelligence, big data analysis support the management of software developments and infrastructure as code for which cybersecurity is a rock for trust.

In this context, I will introduce, for readers familiar with cloud native technologies, a facet of digital security that addresses the major technical risks of application containers. These risks have been fully described, since 2017, by the National Institute of Standards and Technology, NIST, an agency of the United States Department of Commerce. Its goal is to promote the economy by developing technologies, metrology and standards in concert with industry. The Application Container Security Guide that documents top threats has become a mandatory reference. Therefore, the remaining part of this article deals with its content.

Risks and security

For application containers, as for other information security topics, the intent is about identifying, eliminating unacceptable risks and then managing the residual risks of those assets. Risks, by definition, relate to the consequences of threats and opportunities upon the breach of the confidentiality, integrity and availability of containers. These security objectives, called CIA, are combined with the asset usage objectives. In this case, a container aims at portability, interoperability and data sharing. The ready to use software application is the full set of containers, each of which contains a microservice. So application security involves the security of each container, the security of communications between containers, and the security of the infrastructure that provides the resources to power and manage them. The guide suggests a list of advice. However, other major security risks might occur depending on the business context. Therefore, both compliance with the security guide and the analysis of specific risks are required. In the following, we will only deal with the recommendations of the guide.

The Top 23 NIST risks for containers (1)

Share-Run security risks

We will focus on the security risks of continuous deployment of images (Docker Share-Run) , stored in an external base image registry (Docker Hub) or in an internal parent image registry (Mirantis / Docker Hub Enterprise, Harbor) to an orchestrator (Kubernetes). These risks are addressed in a way that remains technology agnostic. So the recommendations are as relevant to IBM / Redhat Openshift as they are to Docker Kubernetes Service (DKS), with the point of view to reduce the time between Developper Desktop and production servers in mind. This will be effective by the relevant use of automation, artificial intelligence and security baselines.

Therefore, the risks that concern the continuous integration of software images (Docker Build-Share), from additions or mergers of code on the main branch (Git push / merge) of a source code repository (Github) to the aforementioned registers are not discussed.

Image risks

1-Image vulnerabilities

Image components (web server, database server) may lack critical security updates or be out of date. Since containers are not updated, but destroyed and redeployed from updated images, there is a risk of generating containers with vulnerabilities.

2-Image configuration defects

A misconfigured image (abusive user privilege, SSH daemon included) can increase the attack surface, even if the image is up to date.

3-Embedded malware

An image could contain malware because it is often built from a template image that can be compromised or untrusted, so the malware could be used to attack other containers or hosts in the production environment.

4-Embedded clear text secrets

An image, like a web application, can contain secrets in clear text (password, API key). So, anyone with access to the image can easily perform an image analysis to know these secrets.

5-Use of untrusted images

An untrusted image (with untrusted software inside), can be easily used, when working under pressure, such as a troubleshot, due to the portability and the easy reuse of containers. So the risk is to introduce malware, data leakage or vulnerabilities.

Registry risks

6-Insecure connections to registries

If insecure connections to the registers are made, the content of the images is subject to the same risks of confidentiality as any other data transmitted in the clear.

7-Stale images in registries

Over time, the stored images in the registry can include many vulnerable and outdated versions. Therefore, the probability of accidentally deploying a known-vulnerable version increases.

8-Insufficient authentication and authorization restrictions

Registries can contain images used to run sensitive or proprietary applications or to access sensitive data. However, the registries are considered to be trusted sources. Therefore, their compromise can lead to the compromise of containers and hosts in production.

Orchestrator Risks

9-Unbounded administrative access

If the users and groups access is not limited by the implementation of the least privilege principle, a malicious or careless user can affect or disrupt the way containers run when managed by the Orchestrator.

10-Unauthorized access

Orchestrators often include their own authentication directory service. This can lead to less rigorous account management practices and “orphaned” accounts in the orchestrator. However, these accounts are often highly privileged ones within the orchestrator. So compromise of them can lead to system wide compromise.

11-Poorly separated inter-container network traffic

While an encrypted inter-container network offers many operational and security benefits, it can also create a security "blindness" scenario in which organizations are unable to effectively monitor traffic.

If applications with different sensitivity levels, such as a public website and an internal cash management application, use the same inter-container virtual network, sensitive internal applications may be at greater risk of attack.

12-Mixing of workload sensitivity levels

The orchestrator takes care of the scaling and load balancing. This means that, by default, it can place loads of different sensitivity levels on the same host (a public web server and an application that processes sensitive financial data). So, in the case of a critical vulnerability in the web server, it can put the container handling sensitive financial data at considerably higher risk of compromise.

13-Orchestrator node trust

It is critical that the level of trust of the clusters is maintained. If it were not the case:

• Unauthorized hosts could join the cluster and run containers.

• The compromise of a single host in the cluster could involve the compromise of the entire cluster, for example, if the same key pairs used for authentication are shared on all nodes.

• Communications, between the orchestrator and a DevOps team, administrators and hosts, might be unencrypted or unauthenticated.

Container Risks

14-Vulnerabilities within the runtime software

Vulnerabilities within runtime software are particularly dangerous if they allow "container leak" scenarios in which malware can attack resources in other containers and the host operating system itself.

15-Unbounded network access from containers

By default, in most container runtime environments, individual containers can access each other and the host operating system over the network. If a container is compromised and acts maliciously, allowing this network traffic can put other resources in the environment at risk.

Access to the egress network is more complex to manage in a containerized environment because much of the connection is virtualized between containers. Therefore, operational tools and processes that do not consider containers are unable to inspect this traffic or determine whether or not it is a threat.

16-Insecure container runtime configurations

Container runtime environments typically provide many configuration options to administrators. Setting them incorrectly can reduce the relative security of the system (modification of system calls, mounting of sensitive directories on the host).

17-App vulnerabilities

Containers can always be compromised due to vulnerabilities in the applications they run. So, this is not really an issue with the containers themselves, but rather the induced manifestation of typical software vulnerabilities in a container environment. When a container is compromised, it can be misused in many ways, such as granting unauthorized access to sensitive information or activating attacks against other containers or the host operating system.

18-Rogue containers

Rogue containers are unintended or unauthorized containers in an environment. This can be common, especially in development environments, where application developers can launch containers to test their code. If these containers are not subjected to the rigors of vulnerability scanning and proper configuration, they can be more vulnerable to exploits. Untrusted containers therefore present an additional risk to the organization, especially when they persist in the environment without the development teams and security administrators being informed.

Host OS Risks

19-Large attack surface

Every host operating system has an attack surface, which is all the means by which attackers can attempt to access and exploit vulnerabilities in the host operating system.So the larger the attack surface, the better the chance that an attacker can find and gain access to a vulnerability, leading to compromise of the host operating system and the containers that run on it. Therefore, host operating systems that are not hardened and downsized give rise to an additional risk.

20-Shared kernel

Container-specific operating systems have a much smaller attack surface than general-purpose operating systems. However, although containers provide strong resource isolation at the software level, using a shared kernel invariably results in inter-object attack surface which involves a weak point in the level of isolation provided by container runtime environments

21-Host OS component vulnerabilities

Like any other software, these components can have vulnerabilities and, due to their location at low level, they can impact all the containers and applications that run on the hosts.

22-Improper user access rights

Organizations are exposed to risk when users log on directly to hosts to manage containers, rather than going through an orchestration layer. Direct management enables wide-ranging changes to the system and all containers on it, and can potentially enable a user that only needs to manage a specific app’s containers to impact many others

23-Host OS file system tampering

Insecure container configurations can expose host volumes to greater risk of file tampering. For example, if a container is allowed to mount sensitive directories on the host OS, that container can then change files in those directories. These changes could impact the stability and security of the host and all other containers running on it.

Conclusion

We looked at container security in a pure player DevOps culture whose technologies are used to take advantage of the data economy. Container security provides some answers to the question: “How can I help to make a digital platform like Netflix more secure ?”. As a consequence, we did not talk about migrating the on-premise information system into the cloud, or issues as turning investments (CAPEX) into operating expenses (OPEX) through outsourcing. Therefore, for a trusted future, the issue is how to make 5G cloud digital platforms better for managing the quality of services, latency, security of access, business continuity and agility of service deployments in all subsidiaries around the world. In other words, the security of data is considered and aligned with GAIA-X and SecNumCLoud perspectives. This covers industrial usage data such as the Skywise predictive maintenance initiative from Airbus, which saves 30% on maintenance costs, or the digital twin programs of connected objects such as nuclear power plant clones by EDF. Incidentally, we will deliver other articles on cloud security topics such as Secure Access Service Edge, SASE (pronounced sassy) and many other key issues.

(1) M. Souppaya, J. Morello, K. Scarfone. NIST. (2017, september). Special Publication 800-190. Application Container Security Guide. https://doi.org/10.6028/NIST.SP.800-190