SYS.1.6 Containerization

Description

Introduction

The term containerization refers to a concept in which the resources of an operating system are partitioned to create execution environments for processes. Depending on the operating system used, different techniques can be employed that differ in scope and security properties. The term “operating system virtualization” is also often used. However, no complete operating system is virtualized; instead, only certain resources are made available through a shared kernel. The term container is generally used to refer to the resulting construct.

Before hastily building and using complex container environments, it should first be carefully considered whether the effort for creating and operating a container environment is in an appropriate ratio to the actual benefit. The proper operation of container environments is very complex and many requirements must be observed. Containers can be used as an additional separation mechanism to achieve a hardened environment, provided the type of container technology and the configuration applied are appropriate and suitable for this purpose.

A distinction is made between application containers (e.g., according to the specification of the Open Container Initiative / OCI) and system containers. System containers are the oldest type of containers, such as FreeBSD Jails, Solaris Zones, OpenVZ, LXC, and LXD. They provide an environment that behaves similarly to a standalone operating system, can offer corresponding services, and can run multiple applications. Application containers, in contrast, are specifically designed to run a single application. They follow the lifecycle of the application but do not offer operating system-specific services within the container. From a technical standpoint, however, both types use the same mechanism for separation — namely process isolation by the kernel.

For Linux containers (LXC), the mechanisms Namespaces and cgroups are mainly used to supplement process isolation.

• Namespaces control which resources a process can see. There are seven different namespaces: Mount (mnt), Process ID (pid), Network (net), Interprocess Communication (ipc), UTS (uts), User ID (user), and Control Group (cgroup).
• cgroups control which resources or what share of a resource a process can use. Resources include in particular Memory, CPU, BLKIO, and PIDS.

Many details must be observed when using namespaces and cgroups. Among other things, the order in which namespaces are shared plays a decisive role. For this purpose, container runtimes have been developed, such as runc, crun, railcar, or katacontainers. The main task of container runtimes is to create a special execution environment for processes. They communicate with the kernel and call syscalls with the appropriate parameters and in the correct order to obtain the desired execution environment.

Typically, containers require a file system — analogous to an operating system — in which the programs to be executed are stored. In the container environment, certain file formats have become established to describe these file systems. These are referred to as images, though they are sometimes incorrectly called containers as well. Depending on the container type used, the content of these images can range from a single statically compiled application to the complete content of an operating system including various execution environments and other dependencies. Images are portable, self-contained units that can be deployed in a container environment and contain all components required for functionality.

In addition to the runtime, there are container engines such as Docker, Rocket, or CRI-O that handle many management tasks. They primarily form the interface to users and process passed commands. They ensure that the required images are available and that corresponding metadata is prepared. Finally, the container engine calls the container runtime with appropriate parameters. The container engine is therefore not part of the containerization mechanism itself but takes on a management function.

Furthermore, there are different types of containers. These differ in terms of the deployment scenario and the lifecycle of a container. A persistent container is one intended for longer-term use. There can indeed be valid reasons for permanently storing data in containers. However, especially in cloud environments, volatile containers are frequently encountered. There, containers generally have a much shorter lifespan, which is also often determined by orchestration tools.

The OCI has efforts underway to provide standards and reference implementations. For example, runc is the standard reference implementation of a container runtime. Other container runtimes that are compatible with the OCI standard can therefore be largely interchanged and used.

Objective

The objective of this building block is to protect information that is processed, offered, or transmitted in, by, or with containers. The building block addresses how containers can fundamentally be secured. A distinction is made between the services for operating the containers — i.e., the software responsible for the configuration and management of containers — and the applications and services that are executed within the containers.

Scope and Modeling

The building block SYS.1.6 Containerization must always be applied whenever services or applications are operated in containers.

This building block considers containers independently of specific products. The requirements are oriented toward the capabilities of implementations currently available on the market. When selecting a product, the building block APP.6 General Software should be taken into account.

The building block supplements the aspects addressed in building blocks SYS.1.1 General Server and SYS.1.3 Servers Running Linux and Unix with the specifics of containerization. The requirements of these building blocks should be met by the host system, regardless of whether it runs on physical servers or is virtualized. Furthermore, the requirements of these building blocks also apply to each of the userspace environments created in the course of containerization. Additional building blocks such as CON.8 Software Development or the building blocks in sub-layer OPS.1.1 Core IT Operations must regularly be taken into account. This applies especially to the creation of images.

Typically, containers communicate with each other through virtual networks on the host system. The building blocks in sub-layers NET.1 Networks and NET.3 Network Components must be taken into account accordingly.

Security requirements for possible services, such as web servers (APP.3.2 Web Server) or web applications (APP.3.1 Web Applications and Web Services) are the subject of separate building blocks that must be applied in addition. If the host system is virtualized, the building block SYS.1.5 Virtualization must be modeled.

If the containers and the underlying infrastructure are not operated and used exclusively in-house, but parts of them are provided by or used by third parties, additional requirements from building blocks OPS.2.3 Use of Outsourcing and OPS.2.2 Cloud Usage as well as OPS.3.2 Offering of Outsourcing must be taken into account.

The building block contains fundamental requirements for the setup and operation of containerization. The other services commonly found in this area — such as orchestration of containers, storage systems, virtual networks, automation for CI/CD pipelines, or the operation of image registries — are not addressed here. Likewise, this building block makes no statements about requirements applicable to the building of images. For requirements on orchestration of containers with Kubernetes, the building block APP.4.4 Kubernetes must be consulted.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to describe the threat landscape. The following specific threats and vulnerabilities are of particular significance for building block SYS.1.6 Containerization.

Vulnerabilities or Malware in Images

Containers are primarily created on the basis of pre-built images, which can be self-created but are also frequently obtained from the internet. Furthermore, software is increasingly delivered in the form of images. IT Operations can also use these images as a basis for creating their own images by adding, modifying, or removing software or configurations.

The software contained in the images could be vulnerable, and the containers started from the image could therefore be attackable. Such vulnerabilities are often not known to IT Operations, as the software contained in the images is frequently not registered in their own software management. IT Operations must fundamentally rely on updates being made available through the image creation process. From the outside, it is often laborious to determine which software packages are present in these images.

In addition, images could contain intentionally integrated malware, such as ransomware or cryptominers. Since a single image is often deployed in a large number of containers, the resulting damage can be immense.

Administrative Access Without Security

To manage container services on a host, administrative access is required. This access is often implemented as services that can be addressed either locally or over the network. Authentication and encryption mechanisms for administrative access are frequently available but not enabled by default in all products.

If unauthorized persons can access the network sockets or the host system, they can use unprotected administrative access to execute commands that can lead to a loss of confidentiality, integrity, and availability of all containers running on this host.

Resource Conflicts on the Host

Individual containers can overload the host and thus jeopardize the availability of all other containers on the host or even the operation of the host system itself.

Unauthorized Communication

All containers on a host can fundamentally communicate with each other, with the host, and with any other hosts. If this communication is not restricted, it can be exploited, e.g., to attack other containers or hosts.

Furthermore, there is a risk that containers are reachable from outside, even if this is not desired. This could enable an attack against services that should actually only be reachable internally to be carried out from outside. This threat is heightened by the reduced attention often paid to such internal services. If, for example, a vulnerability on an only internally deployed service is tolerated and this service is also reachable from outside, this can significantly jeopardize the entire operation.

Container Escape to the Host System

If there is the possibility of executing one’s own code in a container, an attack may potentially overcome the isolation of the container with respect to other containers or the host, and gain access to other containers, the host system, or the infrastructure. This is also referred to as a “container escape”. This attack can take place, e.g., via vulnerabilities in processors, in the operating system kernel, or in locally offered infrastructure services such as DNS or SSH.

As a result, an attack could take control of the host system or other systems in the infrastructure. This threatens the loss of confidentiality, integrity, and availability of all containers running on this host, as well as on the host itself if elevated privileges can also be obtained there.

Data Loss Through Container Management

In the course of container management, containers can be shut down without giving the software currently running in them the opportunity to complete, e.g., ongoing write processes (improper shutdown). If data is being processed by the container at these times, all of this data is lost. Data persistently stored in the container can also be permanently lost in this way.

Confidentiality Loss of Access Credentials

The principles of the design and creation of images for containers require that access credentials — e.g., for databases — be available in the container. Via the images themselves, the scripts used to create the images, or the version control of the scripts, such access credentials can fall into unauthorized hands.

Access credentials are also frequently made available as environment variables at the time of container creation. The confidentiality of this data is also at risk.

Disorderly Provision and Distribution of Images

In contrast to classic installations by IT Operations, where control over the deployed applications, components, and services rests entirely with IT Operations itself, this control is lost, e.g., when automation via CI/CD in container environments is used. Instead, IT Operations merely provides a platform into which developers can directly introduce their applications — including all dependencies — and modify them at any time.

Requirements

The following are the specific requirements of building block SYS.1.6 Containerization. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is sensible and appropriate.

Exactly one role should be Primarily responsible. In addition, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

SYS.1.6.A1 Planning of Container Deployment (B)

Before containers are deployed, the objective of the container deployment (e.g., scaling, availability, disposable containers for security, or CI/CD) MUST first be defined so that all security-relevant aspects of installation, operation, and decommissioning can be planned. The operational overhead arising from container deployment or mixed operation SHOULD also be considered during planning. Planning MUST be appropriately documented.

SYS.1.6.A2 Planning of Container Management (B)

Container management MUST ONLY take place following appropriate planning. This planning MUST cover the entire lifecycle from commissioning to decommissioning, including operation and updates. When planning management, it MUST be taken into account that, due to the impact on operations, the creators of a container are in some respects to be regarded as administrators.

Starting, stopping, and monitoring of containers MUST be carried out via the management software in use.

SYS.1.6.A3 Secure Use of Containerized IT Systems (B)

For containerized IT systems, it MUST be taken into account how containerization affects the IT systems and applications being operated, particularly with regard to management and suitability of the applications.

Based on the protection needs of the applications, it MUST be verified whether the requirements for isolation and encapsulation of the containerized IT systems and virtual networks, as well as the applications being operated, are sufficiently met. Operating system-specific mechanisms SHOULD be included in this review. For the virtual networks, the host acts as a network component; the building blocks in sub-layers NET.1 Networks and NET.3 Network Components MUST be taken into account accordingly. Logical and overlay networks MUST also be addressed and modeled. Furthermore, the containerized IT systems used MUST meet the requirements for availability and data throughput.

During ongoing operation, the performance and status of the containerized IT systems SHOULD be monitored (so-called health checks).

SYS.1.6.A4 Planning of Provision and Distribution of Images (B)

The process for providing and distributing images MUST be planned and appropriately documented.

SYS.1.6.A5 Separation of Administration and Access Networks for Containers (B)

The networks for host administration, container administration, and their access networks MUST be separated appropriately to the protection needs. As a general rule, at least the administration of the host SHOULD only be possible from the administration network.

Only the communication relationships necessary for operation SHOULD be permitted.

SYS.1.6.A6 Use of Secure Images (B)

It MUST be ensured that all images used originate exclusively from trustworthy sources. It MUST be clearly identifiable who created the image.

The source MUST be selected such that the software contained in the image is regularly reviewed for security issues and these are remediated and documented. The source MUST commit to and maintain this approach to security issues.

The version of base images used MUST NOT be deprecated. Unambiguous version numbers MUST be specified. If an image with a newer version number is available, it MUST be checked in the context of patch and change management whether and how this can be rolled out.

SYS.1.6.A7 Persistence of Container Logging Data (B)

Storage of container logging data MUST take place outside the container, at a minimum on the container host.

SYS.1.6.A8 Secure Storage of Access Credentials for Containers (B)

Access credentials MUST be stored and managed such that only authorized persons and containers can access them. In particular, it MUST be ensured that access credentials are only stored in specially protected locations and not in the images. The management mechanisms for access credentials provided by the management software of the container service SHOULD be used.

At a minimum, the following access credentials MUST be stored securely:

• passwords of all accounts,
• API keys for services used by the application,
• keys for symmetric encryption, and
• private keys for public-key authentication.

Standard Requirements

Together with the basic requirements, the following requirements reflect the state of the art for this building block. They SHOULD generally be fulfilled.

SYS.1.6.A9 Suitability for Container Operation (S)

The application or service to be operated in the container SHOULD be suitable for container operation. It SHOULD be taken into account that containers can be terminated unexpectedly for the application running in them more often than other environments. The results of the review according to SYS.1.6.A3 Secure Use of Containerized IT Systems SHOULD be traceably documented.

SYS.1.6.A10 Policy for Images and Container Operation (S)

A policy SHOULD be created and applied that defines the requirements for operating containers and the permitted images. The policy SHOULD also include requirements for the operation and provision of images.

SYS.1.6.A11 Only One Service per Container (S)

Each container SHOULD provide only one service.

SYS.1.6.A12 Distribution of Secure Images (S)

It SHOULD be appropriately documented which sources for images have been classified as trustworthy and why. In addition, the process SHOULD be appropriately documented for how images or the software components contained in images are obtained from trustworthy sources and ultimately made available for productive operation.

The images used SHOULD have metadata that makes the function and history of the image traceable. Digital signatures SHOULD protect every image against modification.

SYS.1.6.A13 Release of Images (S)

All images for productive operation SHOULD undergo a test and release process in accordance with building block OPS.1.1.6 Software Testing and Releases, like software products.

SYS.1.6.A14 Updating Images (S)

When creating the concept for patch and change management in accordance with OPS.1.1.3 Patch and Change Management, it SHOULD be decided when and how updates of images or the software or service being operated are rolled out. For persistent containers, it SHOULD be checked whether, in exceptional cases, updating the respective container is more appropriate than completely reprovisioning the container.

SYS.1.6.A15 Limiting Resources per Container (S)

Resources on the host system — such as CPU, volatile and persistent storage, and network bandwidth — SHOULD be appropriately reserved and limited for each container. It SHOULD be defined and documented how the system responds in the event that these limits are exceeded.

SYS.1.6.A16 Administrative Remote Access to Containers (S)

Administrative access from a container to the container host and vice versa SHOULD in principle be treated like administrative remote access. NO administrative remote access from a container to the container host SHOULD occur. Application containers SHOULD NOT contain remote maintenance access. Administrative access to application containers SHOULD always take place via the container runtime.

SYS.1.6.A17 Execution of Containers Without Privileges (S)

The container runtime and all instantiated containers SHOULD only be executed from a non-privileged system account that does not have or cannot obtain elevated rights for the container service and the operating system of the host system. The container runtime SHOULD be encapsulated through additional measures, for example by using CPU virtualization extensions.

If containers must exceptionally take on host system tasks, the privileges on the host system SHOULD be limited to the required minimum. Exceptions SHOULD be appropriately documented.

SYS.1.6.A18 Application Service Accounts (S)

System accounts within a container SHOULD NOT have permissions on the host system. Where operational reasons make this permission necessary, it SHOULD only apply to the absolutely necessary data and system accesses. The account in the container that is necessary for this data exchange SHOULD be known to the host system.

SYS.1.6.A19 Mounting Data Stores into Containers (S)

Containers SHOULD ONLY be able to access the mass storage and directories necessary for operation. Permissions SHOULD only be explicitly granted if required. If the container runtime mounts local storage for a container, the access rights in the file system SHOULD be restricted to the service account of the container. If network storage is used, permissions SHOULD be set on the network storage itself.

SYS.1.6.A20 Hardening of Configuration Data (S)

Container configuration data SHOULD be versioned. Changes SHOULD be traceably documented.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the protection level corresponding to the state of the art. The proposals SHOULD be considered in the case of high protection needs. The specific determination is made within the framework of an individual risk analysis.

SYS.1.6.A21 Extended Security Policies (H)

Extended policies SHOULD restrict the permissions of containers. Mandatory Access Control (MAC) or a comparable technique SHOULD enforce these policies. The policies SHOULD restrict at least the following accesses:

• incoming and outgoing network connections,
• file system accesses, and
• kernel requests (syscalls).

The runtime SHOULD start containers in such a way that the kernel of the host system prevents all activities of the containers not permitted by the policy (e.g., by setting up local packet filters or by revoking permissions) or at least reports violations appropriately.

SYS.1.6.A22 Provision for Investigations (H)

In order to have containers available for later investigation if needed, an image of the state SHOULD be created according to defined rules.

SYS.1.6.A23 Immutability of Containers (H)

Containers SHOULD NOT be able to modify their file system during runtime. File systems SHOULD NOT be mounted with write permissions.

SYS.1.6.A24 Host-Based Intrusion Detection (H)

The behavior of containers and the applications and services operated in them SHOULD be monitored. Deviations from normal behavior SHOULD be detected and reported. The reports SHOULD be appropriately handled in the central process for handling security incidents.

The behavior to be monitored SHOULD include at a minimum:

• network connections,
• created processes,
• file system accesses, and
• kernel requests (syscalls).

SYS.1.6.A25 High Availability of Containerized Applications (H)

For high availability requirements of containerized applications, it SHOULD be decided at which level availability is to be achieved (e.g., redundantly at the host level).

SYS.1.6.A26 Further Isolation and Encapsulation of Containers (H)

If further isolation and encapsulation of containers is required, the following measures SHOULD be reviewed in order of increasing effectiveness:

• fixed assignment of containers to container hosts,
• execution of individual containers and/or the container host with hypervisors,
• fixed assignment of a single container to a single container host.

Additional Information

Good to Know

Further information on threats and security measures in the area of containers can be found, among other places, in the following publications:

• NIST 800-190 https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-190.pdf
• CIS Benchmark Docker https://www.cisecurity.org/benchmark/docker/
• OCI - Open Container Initiative https://www.opencontainers.org/
• CNCF - Cloud Native Computing Foundation https://www.cncf.io/
• SANS Checklist https://www.sans.org/reading-room/whitepapers/auditing/checklist-audit-docker-containers-37437
• Docker Security Guide https://docs.docker.com/engine/security/