+SYS.1.6 Containerisation
---+SYS.1.6.G1. Vulnerabilities or Malware in Images
---+SYS.1.6.G2. Administrative Access Without Security
---+SYS.1.6.G3. Resource Conflicts on the Host
---+SYS.1.6.G4. Unauthorised Communication
---+SYS.1.6.G5. Breaking Out of the Container into the Host System
---+SYS.1.6.G6. Data Loss Through Container Management
---+SYS.1.6.G7. Loss of Confidentiality of Access Data
---+SYS.1.6.G8. Disorderly Provision and Distribution of Images
---+SYS.1.6.A1 Planning Container Use (B)
---+SYS.1.6.A2 Container Management Planning (B)
---+SYS.1.6.A3 Secure Use of Containerised IT Systems (B)
---+SYS.1.6.A4 Planning the Provision and Distribution of Images (B)
---+SYS.1.6.A5 Separation of Administration and Access Networks for Containers (B)
---+SYS.1.6.A6 Use of Secure Images (B)
---+SYS.1.6.A7 Persistence of Container Logging Data (B)
---+SYS.1.6.A8 Secure Storage of Container Access Data (B)
---+SYS.1.6.A9 Suitability for Container Operation (S)
---+SYS.1.6.A10 Policy for Images and Container Operation (S)
---+SYS.1.6.A11 Only One Service per Container (S)
---+SYS.1.6.A12 Distribution of Secure Images (S)
---+SYS.1.6.A13 Release of Images (S)
---+SYS.1.6.A14 Updating Images (S)
---+SYS.1.6.A15 Limitation of Resources per Container (S)
---+SYS.1.6.A16 Administrative Remote Access to Containers (S)
---+SYS.1.6.A17 Running Containers Without Privileges (S)
---+SYS.1.6.A18 Application Services Accounts (S)
---+SYS.1.6.A19 Including Data Stores in Containers (S)
---+SYS.1.6.A20 Protection of Configuration Data (S)
---+SYS.1.6.A21 Extended Security Policies (H)
---+SYS.1.6.A22 Provision for Investigations (H)
---+SYS.1.6.A23 Container Immutability (H)
---+SYS.1.6.A24 Host-Based Attack Detection (H)
---+SYS.1.6.A25 High Availability of Containerised Applications (H)
---+SYS.1.6.A26 Advanced Isolation and Encapsulation of Containers (H)

SYS.1.6 Containerisation

Introduction

The term containerisation describes a concept in which resources of an operating system are partitioned to create execution environments for processes. Depending on the operating system used, techniques that differ in terms of their functional scope and security features can be employed. This is often referred to as “operating system virtualisation”. However, an operating system is not virtualised in its entirety; certain resources are made available through a shared kernel. Generally, the term container is used to describe the resulting construct.

Before building and using complex container environments without due consideration, a thorough evaluation should be made in terms of whether the effort required to create and operate a container environment is suitably proportional to the actual benefits. The proper operation of container environments is very complex and there are many requirements to consider. Containers can be used as an additional separation mechanism to harden an environment, provided that the type of container technology and the configuration undertaken are appropriate and suitable for this purpose.

Here, a distinction is made between application containers (e.g. in line with the specification of the Open Container Initiative, OCI) and system containers. System containers such as FreeBSD jails, Solaris zones, OpenVZ, LXC, and LXD are the oldest type of containers. They provide an environment that behaves similarly to a standalone operating system that can provide appropriate services and run multiple applications. Application containers, on the other hand, 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 point of view, however, these two types rely on the same mechanism for separation (i.e. process isolation by the kernel).

In the example of the Linux container (LXC), the mechanisms of namespaces and cgroups are mainly used to supplement process isolation.

  • Namespaces are used to control which resources a process can see. There are seven different namespaces: mount (mnt), process ID (pid), network (net), inter-process communication (ipc), UTS (uts), user ID (user), and control group (cgroup).
  • cgroups are used to control which resources or which part of a resource a process can use. In particular, resources include memory, CPU, BLKIO, or PIDS.

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

As with an operating system, containers usually require a file 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 also called images. However, they are sometimes also referred to incorrectly as containers. Depending on the type of container 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. These images are transportable, self-contained units that can be deployed in a container environment and contain all the components required for functionality.

In addition to runtimes, there are container engines such as Docker, Rocket, or CRI-O, which take on many administrative tasks. Primarily, they form the interface to the user and process transferred commands. They ensure that the required images are available and that corresponding metadata are prepared. Finally, the container engine calls the container runtime with corresponding parameters. The container engine is thus not part of the containerisation mechanism, but takes on an administrative function here.

Furthermore, there are different types of containers. These differ according to the deployment scenario and the lifecycle of the container in question. A “persistent container” is a container that is intended to be used for a longer period of time. There may well be valid reasons to store data permanently in containers. Especially in the cloud environment, however, “volatile containers” are frequently encountered. There, containers usually have a much shorter lifespan, which is also often determined by orchestration tools.

Within the OCI, efforts are being made 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 thus be widely exchanged and used.

Objective

The objective of this module is to protect information which is processed, provided, or transmitted from or with containers. The module deals with how containers can be secured in principle. A distinction is made between the services for operating containers (i.e. the software that is responsible for configuring and managing them) and the applications and services that are executed within containers.

Scoping and Modelling

SYS.1.6 Containerisation must always be used whenever services or applications are run in containers.

This module considers containers without regard for specific products. The requirements are based on the capabilities of implementations currently available on the market. When selecting a product, module APP.6 General Software must be taken into account.

The module supplements the aspects dealt with in the modules SYS.1.1 General Server and SYS.1.3 Linux and Unix Servers with specifics related to containerisation. The requirements of these modules should be met by the host system regardless of whether it is running on physical servers or is virtualised. Furthermore, the requirements of these modules also apply to each of the user space environments created in the context of containerisation. Other modules, such as CON.8 Software Development or the modules of the sub-layer OPS.1.1 Core IT Operation, must be considered on a regular basis. This is especially true for the creation of images.

Typically, containers communicate with each other through virtual networks on the host system. The modules of the sub-layers NET.1 Networks and NET.3 Network Components must be considered accordingly.

Security requirements of possible services, such as web servers (APP.3.2 Web Servers) or web applications (APP.3.1 Web Applications and Web Services) are the subject of separate modules that must be applied additionally. If the host system is virtualised, module SYS.1.5 Virtualisation must be followed.

If containers and their underlying infrastructure are not completely operated and used on their own, but parts of them are provided or used by third parties, additional requirements of the modules OPS.2.1 Outsourcing for Customers, OPS.2.2 Cloud Usage, and OPS.3.1 Outsourcing for Service Providers must be considered.

The present module contains basic specifications for setting up and operating containers. The other common services in the containerisation environment, such as orchestration of containers, storage systems, virtual networks, automation for CI/CD pipelines, or the operation of image registries, are not considered here. This module also does not make any statements about requirements that apply to the construction of images. For requirements regarding the orchestration of containers with Kubernetes, module APP.4.4 Kubernetes should be considered.

Useful Resources

For more information about threats and security safeguards with regard to containers, see the following publications, among others:

  • 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/

1. Ħarsa ġenerali

SYS.1.6.A1 Planning Container Use (B)

Before containers are deployed, the goal of such a deployment (e.g. scaling, availability, disposable containers for safety or CI/CD) SHOULD be determined so that all the security-related aspects of installation, operation, and decommissioning can be planned. The planning SHOULD also take into account the operational overhead resulting from container deployment or mixed operation. The planning MUST be adequately documented.
SYS.1.6.A2 Container Management Planning (B)

The management of containers MUST ONLY be carried out in line with appropriate planning. This planning MUST cover the entire lifecycle from commissioning to decommissioning, including operation and updates. When planning container management, it MUST be taken into account that the creator of a container is to be considered like an administrator due to the effects they have on parts of the operation.

Containers MUST be started, stopped, and monitored via the management software used.
SYS.1.6.A3 Secure Use of Containerised IT Systems (B)

In the case of containerised IT systems, consideration MUST be given to how containerisation affects the IT systems and applications operated, in particular the management and suitability of the applications.

Based on the protection needs of the applications, it MUST be checked whether the requirements for isolation and encapsulation of the containerised IT systems, virtual networks, and operated applications are sufficiently fulfilled. The mechanisms of the operating system in question SHOULD be included in this check. Since the host performs the function of a network component for virtual networks, the modules of the sub-layers NET.1 Networks and NET.3 Network Components MUST be considered accordingly. Logical and overlay networks MUST also be considered and modelled. Furthermore, the containerised IT systems used MUST meet the requirements at hand regarding availability and data throughput.

During operation, the performance and the state of the containerised IT systems SHOULD be monitored (health checks).
SYS.1.6.A4 Planning the Provision and Distribution of Images (B)

The process for the provision and distribution of images MUST be planned and appropriately documented.
SYS.1.6.A5 Separation of Administration and Access Networks for Containers (B)

Networks for the administration of the host, the administration of the containers, and their access networks MUST be separated according to the protection needs at hand. In principle, at least the administration of the host SHOULD only be possible from the administration network.

Only the communication relationships necessary for operation SHOULD be allowed.
SYS.1.6.A6 Use of Secure Images (B)

It MUST be ensured that all images used originate from trusted sources. The creator of each image MUST be clearly identifiable.

Sources MUST be selected on the basis of whether the creator of a given image regularly checks the included software for security problems, fixes and documents them, and provides corresponding guarantees to customers.

The utilised version of base images MUST NOT be deprecated. Unique version numbers MUST be provided. If an image with a newer version number is available, a patch and change management process MUST check whether and how it can be rolled out.
SYS.1.6.A7 Persistence of Container Logging Data (B)

Container logging data MUST be stored outside of the respective container (on the container host at minimum).
SYS.1.6.A8 Secure Storage of Container Access Data (B)

Access data MUST be stored and managed in such a way that only authorised persons and containers can access it. In particular, it MUST be ensured that access data is only stored in specially protected locations and not in images. The access data management mechanisms provided by container service management software SHOULD be used.

At minimum, the following credentials MUST be stored securely:

  • Passwords of any accounts
  • API keys for services used by the application
  • Keys for symmetric encryption
  • Private keys for public key authentication
SYS.1.6.A9 Suitability for Container Operation (S)

An application or service to be operated in a container SHOULD be suitable for such operation. It SHOULD be considered that containers can often be terminated unexpectedly, with corresponding consequences for the application run therein. The results of the checking described under SYS.1.6.A3 Secure Use of Containerised IT Systems SHOULD be documented in a comprehensible manner.
SYS.1.6.A10 Policy for Images and Container Operation (S)

A policy SHOULD be established and applied that specifies the requirements for container operation and permitted images. The policy SHOULD also include requirements for the operation and deployment of images.
SYS.1.6.A11 Only One Service per Container (S)

Each container SHOULD only provide one service at a time.
SYS.1.6.A12 Distribution of Secure Images (S)

The sources of images that have been classified as trusted and SHOULD be adequately documented along with the corresponding reasons. In addition, the process of how images or the software components contained in an image are obtained from trusted sources and eventually deployed to a productive environment SHOULD be adequately documented.

Images used SHOULD have metadata that makes their function and history traceable. Digital signatures SHOULD secure each image against modification.
SYS.1.6.A13 Release of Images (S)

All images for productive operation SHOULD undergo a test and release process in the same way as software products in accordance with module OPS.1.1.6 Software Tests and Approvals.
SYS.1.6.A14 Updating Images (S)

When establishing a concept for patch and change management according to OPS.1.1.3 Patch and Change Management, it SHOULD be decided when and how the updates of images or the software or service operated are to be rolled out. For persistent containers, checks SHOULD be made as to whether an update of a container is more appropriate than completely re-provisioning the container in exceptional cases.
SYS.1.6.A15 Limitation of Resources per Container (S)

Resources on the host system such as CPU, volatile and persistent memory, and network bandwidth SHOULD be appropriately reserved and limited for each container. How the system should react if these limits are exceeded SHOULD be defined and documented.
SYS.1.6.A16 Administrative Remote Access to Containers (S)

In principle, administrative access from a container to the container host and vice versa SHOULD be considered as administrative remote access. Remote administrative access SHOULD NOT be established from a container to the container host. Application containers SHOULD NOT contain remote maintenance access points. Administrative access to application containers SHOULD always be carried out via the container runtime.
SYS.1.6.A17 Running Containers Without Privileges (S)

A container runtime and any instantiated containers SHOULD only be executed by a non-privileged system account that does not have (and cannot gain) elevated rights to the container service or host operating system. The container runtime SHOULD be encapsulated by additional measures, such as using the virtualisation extensions of CPUs.

If containers are to take over tasks of the host system in exceptional cases, privileges on the host system SHOULD be limited to the minimum necessary. Exceptions SHOULD be adequately documented.
SYS.1.6.A18 Application Services Accounts (S)

System accounts within a container SHOULD have no permissions on the host system. If such authorisation is required for operational reasons, it SHOULD only apply to the data and system access that is absolutely necessary. The account in the container that is necessary to exchange data SHOULD be known in the host system.
SYS.1.6.A19 Including Data Stores in Containers (S)

Containers SHOULD ONLY be able to access the mass storage and directories necessary for operation. Permissions SHOULD only be explicitly assigned where needed. If the container runtime for a container includes local storage, the access rights in the file system SHOULD be restricted to the service account of the container. If network storage is used, the permissions SHOULD be set on the network storage itself.
SYS.1.6.A20 Protection of Configuration Data (S)

Descriptions of container configuration data SHOULD be versioned. Changes SHOULD be documented in a comprehensible manner.
SYS.1.6.A21 Extended Security Policies (H)

Extended policies SHOULD restrict the permissions of containers. Mandatory Access Control (MAC) or a comparable technology SHOULD enforce these policies. At minimum, policies SHOULD restrict the following types of access:

  • Incoming and outgoing network connections
  • File system access attempts
  • Kernel requests (syscalls)

A runtime SHOULD start containers in such a way that the kernel of the host system prevents all activities of the containers that are not allowed by the relevant policy (e.g. by setting up local packet filters or 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 in case they are needed, an image of each container's state SHOULD be created according to specified rules.
SYS.1.6.A23 Container Immutability (H)

Containers SHOULD not be able to change their file system during runtime. File systems SHOULD not be integrated with write permissions.
SYS.1.6.A24 Host-Based Attack Detection (H)

The behaviour of containers and the applications or services running in them SHOULD be monitored. Deviations from normal behaviour SHOULD be noticed and reported. The reports SHOULD be handled appropriately in a centralised process for security incident handling.

At minimum, the behaviour to be monitored SHOULD cover:

  • Network connections
  • Created processes
  • File system access attempts
  • Kernel requests (syscalls)
SYS.1.6.A25 High Availability of Containerised Applications (H)

In cases involving containerised applications with high availability requirements, the necessary level of availability SHOULD be defined (e.g. redundant at the host level).
SYS.1.6.A26 Advanced Isolation and Encapsulation of Containers (H)

If further isolation and encapsulation of containers is required, the following measures SHOULD be considered for increased effectiveness:

  • Fixed assignment of containers to container hosts
  • Execution of the individual containers and/or the container host by means of hypervisors
  • Fixed assignment of a single container to a single container host

1.1 Referenzi

1.2 Rekwiżiti identifikati

1.3 Regolamenti relatati

2. Rekwiżiti identifikati

Rekwiżiti

3. Regolamenti relatati

Regolamenti

Kwistjonijiet marbuta

Links
includes SYS.1.6.G1. Vulnerabilities or Malware in Images
includes SYS.1.6.G2. Administrative Access Without Security
includes SYS.1.6.G3. Resource Conflicts on the Host
includes SYS.1.6.G4. Unauthorised Communication
includes SYS.1.6.G5. Breaking Out of the Container into the Host System
includes SYS.1.6.G6. Data Loss Through Container Management
includes SYS.1.6.G7. Loss of Confidentiality of Access Data
includes SYS.1.6.G8. Disorderly Provision and Distribution of Images