Computer-implemented method and system for providing a set of rules for restricting execution of and / or resource access for at least one container instance formed from a container image

Abstract

The invention relates to a computer-implemented method for providing a set of rules for restricting the execution of and / or resource access for at least one container instance (IZ) formed from a container image (IM), having the following steps: - prior to loading the container image, creating the set of rules (REP) and instantiating a container-image-specific version of the set of rules and storing the container-image-specific version in a rule database (DB); - when loading the container image by means of a container runtime environment (L), loading the container-image-specific version of the set of rules into a local memory (Ch) of an execution environment for executing the container instance, which is formed from the container image by means of the container runtime environment, and - prior to executing the container instance, determining privileges and resources of the execution environment (A), said privileges and resources being allocated to the container instance to be executed by the container runtime environment, by means of a monitoring service (D) which is operated on the execution environment and which, as a client for the at least one container instance, - monitors processes necessary for executing the container instance during the execution of the container instance using the determined privileges and resources and on the basis of the loaded container image-specific version of the set of rules and, on the underlying runtime environment, enforces rules of the container image-specific version of the set of rules and converts the containerized processes into respective operating system namespaces by combining said processes or carries out suitable conversion measures which allow the monitoring service to validate the processes on the execution environment as well, and - in the event of a negative result of the monitoring process, initiates a measure which counteracts said processes.

Description

[0001] Description

[0002] Computer-implemented method and system for providing a set of rules for restricting execution and / or resource access for at least one container instance formed from a container image

[0003] The invention relates to a computer-implemented method and system for providing a set of rules for restricting execution and / or resource access for at least one container instance formed from a container image and an associated computer program product.

[0004] Industrial systems, especially control units, industrial PCs, IoT and edge devices, and cloud servers, are often used in the field for extended periods. They are constantly exposed to changing conditions and a dynamic environment. To cope with these circumstances, new devices are primarily designed to be flexibly adapted over their lifespan, for example, by supporting downloadable applications or apps. Software containers, hereinafter referred to simply as containers, are well-suited for this purpose. Containers thus represent a form of virtualization of an execution environment on a guest computer, also called a host system, and encapsulate an application running in a container from the underlying host system.Applications are now being implemented in many areas, such as industrial automation and process control, but also for applications in transport systems or vehicles using containers.

[0005] To start a container on the host system, a container image is required. This image contains an application program (also called application software) as well as the necessary binaries and libraries. The container image itself can consist of several layers, which can be protected (cryptographically, memory-protected, etc.). A container image is typically portable, can be stored in a repository (also called a container registry), and shared with other users. On the host system, a container instance, or simply a container, is created from the container image and executed on a container runtime environment such as Docker, Podman, or Containerd.If needed, for example, due to increased user demand for the application, additional container instances can be created and executed from the same container image on the same or a different host system, which can also be configured as a virtualized hardware resource. The root file system of a container instance is formed from the layers of an image and an additional volatile layer. Multiple container instances ("as guests") can use the operating system kernel (also called the kernel) of a host system in isolation from one another. In addition to the operating system kernel, the resources managed by the operating system kernel (e.g., connected hardware interfaces or other resources) can also be used. The terms container instance and container are used synonymously in the following text.

[0006] When a container instance starts, execution permissions, also called privileges, are assigned to the processes running within it. These privileges include capabilities and Seccomp profiles (https: / / docs.docker.com / engine / security / seccomp / ), which define a set of permitted system calls. Access to device or other file system resources of the underlying device or system is also agreed upon. To prevent attacks on the host system by the application, these execution permissions and resource accesses can be restricted, so that the container is only granted the rights necessary for the application to operate. Typically, a containerized application does not consist of a single isolated container instance but is deployed as a complete application in conjunction with other container instances, due to a microservice-based architecture.The interaction of multiple container instances, or rather the interaction of their virtual infrastructure and, in particular, their runtime and process permissions, is defined, among other things, in a deployment or instantiation configuration. In orchestrated environments, a Kubernetes manifest or Helm chart can be used for this purpose, while in unorchestrated environments, a Docker-specified docker-compose format can be used.

[0007] In summary, when instantiating a container image, it is not only executed, but may also be reconfigured by assigning host resources or privileges to the runtime environment, so that, for example, applications delivered within a container image may have a changed attack potential or may not be operated in compliance with the image developer's license.

[0008] At the same time, a container instance running on a runtime environment can dynamically load runtime executable programs using appropriate permissions, thus overwriting the application version originally provided by the developer in the (container) image or modifying the program's execution permissions at runtime, so that an attacker can execute modified program code or the same program code with modified permissions and thus, for example, gain access to sensitive data.

[0009] Even assuming that only trusted images are run in the execution environment, a developer who provides an image cannot prevent the scenarios described above. This is because, firstly, the known signature methods for container instances only protect the image in the registry with regard to integrity and authenticity, and secondly, the instantiation information is not part of the image but is created independently. Therefore, the creator of instantiation information is independent of the image creator, which means that the execution permissions of individual programs made available within the image can be modified.

[0010] Well-known application whitelisting solutions include fapolicyd (see https: / / github.com / linux-application-whitelisting / fapolicyd). This is an application whitelisting solution for Linux systems that doesn't focus on containers but is generally applicable to Linux systems. Fapolicyd uses the kernel's fanotify module (see https: / / de.wikipedia.org / wiki / Fanotifv) to perform checks against a locally stored rule set before executing the actual program. Fapolicyd also supports the direct integration of local Linux package managers, which are used to determine file checksums and locally stored permissions. Furthermore, program options passed to a program to be started can be evaluated, and user-specific permissions can be granted. However, certain container-specific options—such as...The assignment of a specific mount to an instance is evaluated. For Windows systems, solutions such as AppLocker (see https: / / learn.microsoft.com / de-de / windows / security / application-security / application-control / windows-defender-application-control / applocker / applocker-overview) or Windows Defender Application Control (https: / / learn.microsoft.com / de-de / windows / security / application-security / application-control / windows-defender-application-control / wdac) exist. Like fapolicyd, they use similar mechanisms, and both solutions are not container-based.

[0011] From BELAIR MAXIME MAXIME BELAIR(g)ORANGE COM ET AL: "SNAPPY programmable kernel-level policies for containers", PROCEEDINGS OF THE 36TH ANNUAL ACM SYMPOSIUM ON APPLIED COMPUTING, ACMPUB27, NEWYORK, NY, USA, March 22, 2021 (2021-03-22), pages 1636-1645, XP058740439, DOI: 10.1145 / 3412841 .3442037 ISBN: 978-1-4503-8128-4, a framework is known that allows unprivileged processes such as containers to securely and dynamically enforce fine-grained, sequential, and programmable eBPF security policies to the kernel at runtime.

[0012] The invention is therefore based on the objective of designing a method and a system in such a way as to ensure improved protection against unauthorized access to one or more common resources or altered execution authorization compared to the prior art.

[0013] This problem is solved by the features according to the independent claims. Advantageous embodiments of the present invention are described in the dependent claims.

[0014] The invention claims a computer-implemented method for providing a rule set for restricting execution and / or resource access for at least one container instance formed from a container image, comprising the following steps:

[0015] - Before loading the container image, create, generate, or define the rule set, instantiate a container image-specific version of the rule set, and store the container image-specific version in a rule database.

[0016] - When loading the container image, a container runtime environment loads the container image-specific version of the rule set into local storage of an execution environment for executing the container instance created from the container image by the container runtime environment. - Before executing the container instance, determine the privileges and resources of the execution environment assigned to the container instance to be executed by the container runtime environment using a monitoring service running on the execution environment, which acts as a client for at least one container instance.

[0017] - processes necessary for the execution of the container instance are monitored during the execution of the container instance using the determined privileges and resources as well as the loaded container image-specific version of the rule set, and rules of the container image-specific version of the rule set are enforced on the underlying runtime environment, and the containerized processes are translated into the respective operating system namespaces by connecting or suitable implementation measures are carried out that enable the monitoring service to validate the processes on the execution environment itself.

[0018] - and, if the monitoring yields a negative result, initiates a measure to counteract the execution of the aforementioned processes.

[0019] If at least one process is identified as unauthorized or "critical" during monitoring, then a treatment / measure to counteract or prevent access to the resources is initiated by means of an alert message, by stopping the "unauthorized" or "critical" process, or by stopping the execution of the entire container instance. "Stopping" here can mean either interrupting or terminating the process.

[0020] If the result is positive, the processes will continue.

[0021] After initiating such a measure and / or terminating the execution of the container instance, the container image-specific version of the rule set can be deleted from local storage.

[0022] In this context, resources can refer to a namespace that can be shared by multiple container instances. Resources can also be file system objects, which are typically files or directories / folders, and device files. If such objects or files are virtual, parent-child relationships apply, similar to those for namespaces. If these objects or files are physical, they reside on the host system. Multiple container instances may access them via the container runtime environment. Container instances can start entirely in their own operating system namespaces (e.g., Linux namespaces) or run together in shared operating system namespaces. It is not necessary for all container instances to share all namespaces; they can also share specific namespace types, such as just the network namespace.The latter is used, for example, in so-called sidecar containers, which implement a transparent proxy for a workload container. With appropriately privileged containers, it is also possible for them to operate in the host namespace and thus within the parent namespace of other container instances.

[0023] An authorization criterion in the rulebook can be designed in such a way that processes are marked as permitted or as unauthorized / prohibited with a corresponding identifier / label.

[0024] One or more authorization criteria of the rule set can be designed in such a way that they are integrity-protected together with the deployment configuration or the container image by means of a signature. This protects it against unauthorized modification. The signature can thus be validated by the runtime environment during deployment.

[0025] The authorization criteria determine whether an alarm message should be sent or the execution of the container instance should be stopped.

[0026] The monitoring service is designed as a monitoring unit in the form of a client for the container instances; this can be integrated on the device / host system (e.g., via a plugin / agent) or run outside the host system on a remote system. On a host system's execution environment, the monitoring service can also be run as an enforcement daemon alongside the container runtime environment. In the Linux world, a daemon is a background process that typically performs tasks without requiring user interaction. These tasks are often critical services such as logging, routing, or other web services.

[0027] The instantiation of the container-specific version of the rule set can be performed within a container registry. The container image-specific version of the rule set can include certain properties of signatures and / or namespaces required for the container image, the mounting of drives and / or files of the execution environment, and / or process privileges. When instantiating the container-specific version of the rule set, checksums can be generated for each binary file of the container image.

[0028] The solution according to the invention offers the advantage that the creator of a container image can define an application whitelisting rule set for the programs delivered within the image, and this rule set can then be enforced in the execution environment. Ideally, such a solution also supports container-specific aspects. When the container image is uploaded to a container registry, the rule set is instantiated as a container-image-specific version and stored by the registry in a rule database, e.g., in the form of an application whitelisting database. For monitoring the execution of the container instance, the instantiated container-image-specific version of the rule set can be provided in a repository accessible by the container runtime environment. The repository can contain an application whitelisting rule set.

[0029] The method is preferably computer-aided or computer-implemented, and is preferably executed using computer-aided or computer-implemented methods. The steps of the method can be repeated any number of times, and repetitions can be terminated based on defined conditions, whether event-driven or time-limited.

[0030] Another aspect of the invention is a system suitable for providing a rule set for restricting execution and / or resource access for at least one container instance formed from a container image, comprising: an interface to a container register that creates the rule set before the container image is loaded, instantiates a container image-specific version of the rule set, and stores this in a rule database; a container runtime environment designed to load the container image-specific version of the rule set into local memory of the system for executing the container instance formed from the container image by the container runtime environment when the container image is loaded; and a monitoring unit for operating a monitoring service on an execution environment of the system, which is configured as a client for the at least one container instance.to determine the privileges and resources assigned to the execution environment by the container runtime environment of the container instance to be executed before the container instance is executed, and to monitor the processes necessary for the execution of the container instance during its execution using the determined privileges and resources as well as the loaded container image-specific version of the rule set, and to enforce the rules of the container image-specific version of the rule set on the underlying runtime environment, and to translate the containerized processes by connecting them to the respective operating system namespaces or to carry out suitable implementation measures that enable the monitoring service to validate the processes on the execution environment itself, and, in the event of a negative result from the monitoring, to initiate a measure to counteract the execution of the aforementioned processes.

[0031] Furthermore, a computer program product can be used, comprising a non-volatile storage medium on which a loadable and executable program code is stored, which executes the method according to one of the above-mentioned embodiments in a processor unit, in particular one, or distributed in several devices / systems according to one of the previously described embodiments.

[0032] Additionally, a variant of the computer program product is claimed with program commands for configuring a creation device, for example a 3D printer, a computer system or a manufacturing machine suitable for creating processors and / or devices, wherein the creation device is configured with the program commands in such a way that the execution environment can be created.

[0033] The system or devices, units or equipment and computer program(s), which may include a loadable and executable program code or distributed loadable and executable program code modules, may be designed according to the further developments / implementations of the aforementioned method and their further developments / implementations and vice versa.

[0034] One embodiment of the invention provides that one or more units, components, or devices can be integrated into the system and that these can be designed as software, firmware, or hardware components. The system typically includes at least one processor that can execute operations as a kernel at the operating system level.

[0035] A processor or processor unit can be, in particular, a central processing unit (CPU), a microprocessor, or a microcontroller, such as an application-specific integrated circuit or a digital signal processor, possibly in combination with a memory unit for storing program instructions, etc. A processor can also be, for example, an integrated circuit (IC) or a multi-chip module, in particular an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit), a system-on-a-chip (SoC), a graphics processing unit (GPU), a processor for evaluating a neural network such as a TPU (tensor processing unit), or a digital signal processor (DSP).The processor can have one or more processing cores (multi-core). A processor can also be understood to be a virtualized processor or a soft CPU. It can, for example, also be a programmable processor that is equipped with configuration steps for executing the aforementioned method according to the invention, or is configured with configuration steps such that the programmable processor implements the features of the method according to the invention or other aspects and sub-aspects of the invention. The processor can have tamper protection to protect against physical manipulation, e.g., tamper sensors for detecting physical attacks.

[0036] Exemplary embodiments of the invention

[0037] Exemplary embodiments of the method and transmission device according to the invention are shown in the drawings and are explained in more detail below. The drawings show:

[0038] Figure 1 shows an exemplary arrangement in which the method according to the invention can be applied, and Figure 2 shows an exemplary description of the process during the start of a new container instance. Figure 1 shows, for example, a host system with an execution environment A, which includes a monitoring unit, in this example an enforcement daemon D. At the operating system level, the execution environment A exchanges commands or instructions with a kernel K. The kernel ultimately controls processes. With an extended Berkeley Packet Filter eBPF (abbreviated eBPF, see also https: / / ebpf.io), the kernel additionally provides an interface with which processes can be interrupted or, more generally, the process flow can be monitored, delayed, or influenced.This means that adapted eBPF programs may delay the start of a program until an integrity check has been performed, or delay the start of the program in the event of a rule violation.

[0039] Before starting a container instance (IZ) for an application that can run within that container instance, a deployment configuration or provisioning information is defined during the development of the container image from which the container instance (IZ) is created using a container runtime environment (L). Depending on the application type, the deployment configuration can also be generated automatically, possibly with default values. Additionally, at least one authorization criterion is defined, either during development or automatically, and may be made available via an app store or other download platform.

[0040] A developer creates or defines a rule set for a container image they have built, which can be deployed to a repository (REP) and uploads it to a container registry (REG) along with the deployment configuration. This instantiates a container image-specific version of the rule set, which is then stored in a rule database (in this example, the Application Whitelisting Database DB) by the container registry in step 3. The database can also be created using a CI / CD pipeline. A pipeline is a process that drives software development by building, testing, and deploying code, also known as CI / CD. In containerized environments, this pipeline also includes packaging the program code into a container image for deployment, for example, in a cloud.

[0041] The rule set is then enforced by a corresponding container runtime environment L in step 1 by running an enforcement daemon D alongside the container runtime environment L on a corresponding execution environment A. When a container image is loaded, the enforcement daemon loads the instantiated application whitelisting rule set generated for the image in step 2 from a rule database (in this example, the application whitelisting database DB) into a local cache Ch running on the execution environment. The enforcement daemon then uses this cache to enforce the monitoring and / or other rules determined for the instance.-Checks and thus whitelisting on the runtime environment are performed by determining the privileges and resources assigned to the container instance by the container runtime environment before it is executed. During the execution of the container instance, the necessary processes are monitored using these determined privileges and resources, as well as the loaded container image-specific version of the rule set. In the event of a negative monitoring result, a measure to counteract the execution of the aforementioned processes is initiated, such as an alarm or termination of the container instance.

[0042] The developer first creates an abstract rule set in which they can directly reference the executable program files of the image. At this stage, it is not necessary to generate corresponding checksums for the respective programs to be protected, as the individual layers of an image are protected by checksums during the creation process according to the OCI image format. Common container signing methods such as Notary v2 or Cosign use the same approach and do not sign the image as a whole, but rather the individual layers and the sequence of their composition for the respective container image tag.

[0043] The abstract rule set created by the developer can further specify that only certain users or groups are allowed to execute a program. The user or group name can also be defined here, which, due to the local, container-specific / etc / passwd entries, can only be translated to a user ID or group ID in the registry when the abstract rule set is instantiated. Furthermore, execution parameters of the respective programs can be specified (also using regular expressions). The same applies to executable programs. Individual directory ranges in the container root file system can also be excluded from whitelisting, so that only specific application programs are restricted in their execution.

[0044] Additionally, container-specific aspects can also be incorporated into the abstract rule set. For example, process privileges such as capabilities, the overwriting of certain file system areas (e.g., / etc or parts thereof within the instance), or the mounting of specific host directories can be restricted. The same applies to the assignment of specific namespaces. For instance, it can be specified that the same program must be executed differently by a user if it is run in the network namespace of the host system and not in a separate container namespace. The method according to the invention has the advantage that different execution conditions can be defined for different instantiations.

[0045] Once the rule set has been created and the image built by the image creator, both are uploaded to the registry. The abstract rule set can be linked to the image, for example, using appropriate metadata or as a separate OCI layer.

[0046] Once the image and the rule set are uploaded, the instantiation of the rule set is triggered within the registry. During this process, corresponding checksums are generated for each file defined in the rule set in the respective layers, and the specified user and group names are translated to the respective IDs within the container.

[0047] The next step involves instantiating the container image on at least one execution environment. For this, a user can either instantiate the image directly via the command line, or alternatively, in a non-orchestrated environment, pass a Docker Compose file, or, with an orchestrator like Kubernetes, a Kubernetes manifest.

[0048] In all three variants, the image is referenced and instantiated using appropriate parameters. During instantiation, the respective instance can be configured with, for example, process privileges, mount options for the root filesystem, or persistent or dynamically created filesystems of the underlying host system.

[0049] If an image is not yet present in the local cache when an instantiation request is made, or if a corresponding image pull policy exists, the image is loaded from the specified container registry. The kernel can then inform the enforcement daemon via the container runtime environment's pull request, for example, using fanotify or appropriately configured eBPF programs. The image loading process can be interrupted, and the instantiated rule set can be loaded into the enforcement daemon's local cache first. Alternatively—as shown in Figure 2—the rule set can be loaded from the application whitelisting database only when the instance is actually started.

[0050] Figure 2 shows an example of the process flow when starting a new container instance. As illustrated in Figure 2, the loading of the rule set from the application whitelisting database can only occur once the instance is actually started.

[0051] This method has the advantage that the cache memory is only filled when the instance actually needs to be started. Consequently, the cache memory does not necessarily have to be persistent on the execution environment, but can be held exclusively within volatile memory.

[0052] Furthermore, the enforcement daemon can query the runtime environment for environment-specific instantiation information of the container instance before or during the loading of the container-specific version of the rule set provided in the registry. This includes, for example, the determination of assigned namespaces, mounts, or process privileges. If a complex rule set is present, individual rules that are not applicable to the respective instance can be deleted from the cache by the corresponding rules provided by the application whitelisting database. However, it must be noted that in this case, the application whitelisting information to be stored in the cache can be stored on an instance-specific basis, not an image-specific one.Both methods can also be used in combination, so that the mapping of the instance-specific settings in the enforcement daemon, for example, only takes place at runtime, as long as a certain number of rules is not exceeded or the number of instances of the same type with different instantiation does not exceed a certain number.

[0053] The enforcement daemon's task is to enforce instance-specific rules on the underlying runtime environment and translate the containerized processes, for example, by connecting them to the respective operating system namespaces or by performing other suitable implementation measures that allow the enforcement daemon to validate the processes on the execution environment itself. The file hashes generated during the image upload are also used within the rule set for this purpose, as they validate the authenticity and integrity of the program within the instance. If all the necessary information is contained within the enforcement daemon and the container init process does not violate any rule in the rule set, the container process is released.

[0054] If additional processes are started during the runtime of a container instance, monitoring is performed analogously to the init process described above. Process calls that violate the rules are also blocked. Compliant processes are allowed to run.

[0055] When the instance is stopped by the runtime environment, the container init process terminates and the instance meta information is deleted. The kernel (e.g., via appropriate eBPF programs) informs the enforcement daemon about the termination of the container init process.

[0056] This then clears the local cache and deletes the instance-specific information. Image-specific whitelisting rules can still be retained and, for example, only evicted after a timeout following the termination of the last instance or according to other common memory eviction strategies based on cache utilization, using a policy within the enforcement daemon.

[0057] The enforcement daemon can also define which registries or images need to be validated. Individual registries or paths running on an image registry can also be excluded within a configuration policy. Alternatively, the container runtime environment can be configured to require container images to have specific signatures. This assumes that the creator of a signature fulfills certain criteria, meaning, for example, that a specific signature always entails the provision of an application whitelisting rule set.

[0058] Although the invention has been illustrated and described in detail by the preferred embodiment, the invention is not limited by the disclosed examples and other variations can be derived by the person skilled in the art without leaving the scope of protection of the invention.

[0059] The implementation of the processes or procedures described above can be carried out using instructions stored on computer-readable storage media or in volatile computer memory (hereinafter collectively referred to as computer-readable memory). Examples of computer-readable memory include volatile memory such as caches, buffers, or RAM, as well as non-volatile memory such as removable media, hard drives, etc.

[0060] The functions or steps described above can be represented in the form of at least one instruction set in / on computer-readable memory. These functions or steps are not bound to a specific instruction set, a specific form of instruction sets, a specific storage medium, a specific processor, or specific execution schemes, and can be executed by software, firmware, microcode, hardware, processors, integrated circuits, etc., either independently or in any combination. Various processing strategies can be employed, such as serial processing by a single processor, multiprocessing, multitasking, or parallel processing, etc.

[0061] The instructions can be stored in local memory, but it is also possible to store the instructions on a remote system and access them via a network.

[0062] In the context of the invention, "computer-aided" or "computer-implemented" can, for example, refer to an implementation of the method in which, in particular, a processor, which may be part of the (control / computing) device or unit, executes at least one process step of the method. The method may also be implemented in a cloud computing environment that can execute the method and thus deliver the results of the method to a control / computing device or unit, which can then issue corresponding commands or take appropriate actions to the devices, in particular those of the aforementioned arrangement.

[0063] Unless otherwise specified in the following description, the terms "map," "recreate," "receive," "apply," "output," "provide," and the like preferably refer to actions and / or processes and / or processing steps that modify and / or generate data and / or convert data into other data, wherein the data may be represented or exist in particular as physical quantities. The terms "processor," "central signal processing," "control unit," or "data processing device" encompass processing devices in the broadest sense, such as servers, general-purpose processors, graphics processing units, digital signal processors, application-specific integrated circuits (ASICs), programmable logic circuits such as FPGAs, discrete analog or digital circuits, and any combination thereof, including all other processing devices known to those skilled in the art or which may be developed in the future.Processors can consist of one or more devices, components, or units. If a processor consists of multiple devices, these can be designed or configured for parallel or sequential processing or execution of instructions.

Claims

Patent claims 1. A computer-implemented method for providing a rule set for restricting execution and / or resource access for at least one container instance (IZ) formed from a container image (IM), comprising the following steps: - Before loading the container image, create the rule set (REP) and instantiate a container image-specific version of the rule set and store the container image-specific version in a rule database (DB), - when loading the container image by a container runtime environment (L), the container image-specific version of the rule set is loaded into local storage (Ch) of an execution environment for executing the container instance that is created from the container image by the container runtime environment. - Before executing the container instance, determine the privileges and resources of the execution environment (A) assigned by the container runtime environment of the container instance to be executed, using a monitoring service (D) running on the execution environment in the form of a client for the at least one container instance, which - processes necessary for the execution of the container instance are monitored during the execution of the container instance using the determined privileges and resources as well as the loaded container image-specific version of the rule set, and rules of the container image-specific version of the rule set are enforced on the underlying runtime environment, and the containerized processes are translated into the respective operating system namespaces by connecting or suitable implementation measures are carried out that enable the monitoring service to validate the processes on the execution environment itself. - and, if the monitoring yields a negative result, initiates a measure to counteract the execution of the aforementioned processes.

2. Method according to the preceding claim, characterized in that the instantiation of the container-specific version of the rule set is carried out within a container register.

3. Method according to one of the preceding claims, characterized in that the instantiated container image-specific version of the rule set is provided in a repository accessible by the container runtime environment for monitoring the execution of the container instance.

4. Method according to one of the preceding claims, characterized in that checksums are created during the instantiation of the container-specific version of the rule set for binary files of the container image.

5. Method according to one of the preceding claims, characterized in that after initiating such a measure and / or terminating the execution of the container instance, the container image-specific version of the rule set is deleted from local storage.

6. Method according to one of the preceding claims, characterized in that the container image-specific version of the rule set includes certain properties of signatures and / or namespaces required for the container image, the mounting of drives and / or files of the execution environment and / or process privileges.

7. System for providing a rule set for restricting execution and / or resource access for at least one container instance (IZ) formed from a container image (IM), comprising: an interface to a container register (REG) that creates the rule set (REP) before the container image is loaded, instantiates a container image-specific version of the rule set, and stores it in a rule database (DB); a container runtime environment (L) designed to load the container image-specific version of the rule set into local storage (Ch) of the system for executing the container instance formed from the container image by the container runtime environment when the container image is loaded; a monitoring unit for operating a monitoring service (D) on an execution environment (A) of the system, which is configured as a client for the at least one container instance.to determine the privileges and resources of the execution environment assigned by the container runtime environment of the container instance to be executed before the container instance is executed, and to determine the processes necessary for the execution of the container instance during the execution of the container instance using the determined privileges and resources as well as the loaded container image-specific version of the rule set. to monitor and enforce the rules of the container image-specific version of the rule set on the underlying runtime environment, and to translate the containerized processes by connecting them to the respective operating system namespaces or to perform suitable implementation measures that enable the monitoring service to validate the processes on the execution environment itself, and, in the event of a negative monitoring result, to initiate a measure to counteract the execution of said processes.

8. Computer program product comprising a non-volatile storage medium on which a loadable and executable program code or distributed loadable and executable program code modules can be stored or are stored, which executes the method according to one of the preceding method claims in a program-controlled computing device or in a system according to the preceding system claims.

Images