DYNAMIC INTEGRITY MONITORING OF A CONTAINER RUNTIME ENVIRONMENT RUNNING ON A GUEST COMPUTER

Description

[0001] The invention relates to methods for dynamic integrity monitoring of a container runtime environment executed on a guest computer, on which at least one container is executed and managed by means of an orchestration device.

[0002] Container virtualization is a method that allows multiple instances of an operating system to use the same operating system kernel on a guest computer in isolation from one another. Software containers, hereinafter referred to simply as containers, thus represent a lightweight way of virtualizing a runtime environment on a guest computer, also called a host system, and encapsulate a software application running in a container from the underlying host computer. Software applications are now implemented in many areas using container technology, for example in industrial automation and process control, but also in transportation systems and building automation.

[0003] To start a container on the guest machine, a container image is required, which contains not only the application software but also the necessary binaries and libraries. A container, or more precisely, a container instance, is created from the container image on the guest machine and executed in the guest machine's runtime environment.

[0004] An orchestrated runtime environment comprises an orchestrator and at least one, and usually multiple, guest machines, also called nodes, that are associated with the orchestrator. The orchestrator starts, manages, and terminates container instances on the associated guest machines. Typical orchestrated runtime environments are Kubernetes-based container environments that manage either cloud-based Container-as-a-Service environments or cloud-based virtual instances as nodes of an orchestrated runtime environment.

[0005] Besides their use in IT environments, orchestrated runtime environments are also used in the industrial Internet of Things (IoT) environment. In contrast to the typical Kubernetes scenario described above, devices operating as nodes in an orchestrated runtime environment in industrial settings do not typically run container instances on the device for short periods, usually a maximum of 24 hours, but rather for longer periods. d.h. These processes can run for several days to weeks without interruption. If an attacker gains unauthorized access to a node, they can install additional software on the node managed by the central orchestration unit or modify it. In particular, in such environments, container instances can be started in parallel with the instances managed by the orchestration component without the orchestrator being aware of it or being able to prevent this process.

[0006] Known integrity monitoring systems cannot optimally detect dynamic start and stop operations of individual container instances initiated by the orchestrator. Instead, they rely on a static rule set, which may be extended by querying orchestrator-specific deployment information. Creating this static rule set requires knowledge of all use cases, or, since this is rarely the case, the rule sets must be defined very broadly.

[0007] US 2018 / 314846 A1 describes a hierarchical arrangement of security policies for a Guest Runtime Environment (GRE) that are implemented at different levels of the execution environment. Different security policies are implemented, for example, in a container, in a virtual machine that can run multiple containers, and on a host that, in turn, hosts multiple virtual machines, and cover different functions. A guest runtime security policy can be specific to the guest runtime environment and can also inherit security policies from higher levels.

[0008] US 2020 / 0218798 A1 discloses a policy interpreter that detects when an application container has been added to a container system, opens the stored manifest for the application container, retrieves information about the running services, and then generates a security policy for the application container. This security policy is loaded into a security container that blocks actions by the application container if they do not comply with the defined actions, and the security policy is then delivered in a graphical user interface container for presentation to the user.

[0009] US 2021 / 0133312 Al discloses an environment type check that determines a tamper-proof validation of the computing environment, the information of which can then be used for policy management to facilitate the exchange of policies between host and container environments.

[0010] It is therefore an object of the present invention to provide a method that can automatically perform integrity monitoring of a node, depending on a runtime configuration defined by the orchestrator, and thus perform a comparison on the target node to determine whether instances were actually started by the orchestrator and whether the runtime configuration specified by the orchestrator for all instances running on the node is identical to the orchestrator's specifications. In particular, it is an object of the invention to achieve the updating of the guest computer-specific integrity policy even when the termination is initiated by the guest computer or occurs due to a crash.

[0011] The problem is solved by the measures described in the independent claims. Advantageous embodiments of the invention are described in the dependent claims.

[0012] According to a first aspect, the invention relates to a method for dynamic integrity monitoring of a container runtime environment executed on a guest computer, on which at least one container is executed and managed by means of an orchestration device, comprising the steps: In the orchestration device, when a container instance is started on the container runtime environment by the orchestration device, an instance-specific integrity rule is created concerning at least one resource of the guest machine that is allocated to run the container instance, the instance-specific integrity rule is added to a guest machine-specific integrity policy, which includes an instance-specific integrity rule for each container instance already running on the container runtime environment of the guest machine and is located in the orchestration device, the guest machine-specific integrity policy is transmitted to the guest machine, on the guest machine, the resources allocated on the guest machine by container instances are checked against the guest machine-specific integrity policy, and an alert message is issued.if a violation of the guest computer-specific integrity policy was detected during the check.

[0013] The instance-specific integrity rule comprises one or more integrity rules, each affecting one or more resources of the guest machine assigned to the container instance. The guest machine-specific integrity policy applies to the entire guest machine. d.h. The guest machine-specific health policy applies to all container instances running in the runtime environment and the resources managed by them on the guest machine. For example, the guest machine-specific health policy is created for each guest machine managed by the orchestration device when the guest machine is assigned to the orchestration device or when a container instance is first started on the guest machine. The guest machine-specific health policy is updated dynamically with each subsequent start of a container instance on the guest machine initiated by the orchestration device. By submitting and verifying the guest machine-specific health policy on the guest machine, container instances not started by the orchestration device or resources that differ from the configuration of the started container instance can be identified throughout the entire runtime of the container instance.By integrating the instance-specific integrity rule, integrity monitoring can also be performed for the guest computer itself.

[0014] According to the invention, the method comprises the following further steps: Receiving a message in the orchestration device when one of the container instances on the guest computer is terminated, and transmitting a guest computer-specific integrity policy updated with respect to the message to the guest computer.

[0015] The guest machine-specific integrity policy is therefore updated not only when the orchestration device causes the container instance to be terminated, but also when the termination is caused by the guest machine or is terminated due to a crash.

[0016] In an advantageous embodiment, the guest computer-specific integrity policy is updated when an event is detected in the orchestration device that changes the composition and / or configuration of the container instances on the guest computer, and the updated guest computer-specific integrity policy is transmitted to the guest computer.

[0017] Thus, the guest computer-specific integrity policy is affected when the composition changes, d.h. The orchestration device adjusts which and how many container instances are used, as well as the configuration of the container instances running on the guest computer, for example, when the resources are changed.

[0018] In an advantageous embodiment, the event is at least one of the following actions: a failure of a container instance on the guest computer, a starting of a new container instance on the guest computer, an update of the container instance according to a changed container image, detection of an application crash and restart of affected container instances on the guest computer.

[0019] In an advantageous embodiment, the instance-specific integrity rule is created depending on information about a container image from which the container instance is built.

[0020] The instance-specific integrity rule allows for integrity checks to be performed on the guest machine itself. The advantage of an instance-specific integrity rule that depends on information about the container image is that it can simply be duplicated and reused for other container instances using the same container image.

[0021] In an advantageous embodiment, the instance-specific integrity rule is created depending on information from a provisioning information that specifies the configuration of the container instance when the container instance is started on the respective container runtime environment.

[0022] This is particularly advantageous when the configuration of the service defined within the container image or the target of write operations is defined outside the container image, and especially via deployment-specific variables or configuration files. A concrete example is the deployment of an advertising server that is used multiple times in different contexts within a micro-segmented application. For example, .There are container instances for the frontend component that are exposed externally, and non-exposed container instances in the backend that supply information for the overall application and, for example, provide performance data of a control system that is displayed in the frontend.

[0023] In an advantageous embodiment, the guest computer-specific integrity policy and / or the individual instance-specific integrity rules contained therein are protected by means of a digital signature of the orchestration device.

[0024] The guest computer knows the associated public key of the orchestration device and can therefore verify the integrity of the policy or rules as well as the signing device. d.h. The orchestration unit can be checked. This allows for the identification of policies or rules modified by an attacker. The signing orchestration unit can then be validated.

[0025] In an advantageous embodiment, checking the guest computer-specific integrity policy relates to the file system resources and / or network connection resources and / or process resources and / or executable program files allocated to the container instances.

[0026] This ensures that all resource types required for running the container instances on the guest computer are checked.

[0027] In an advantageous embodiment, the verification of at least part of the guest computer-specific integrity policies is performed outside the guest computer.

[0028] This allows for easy verification of resources outsourced from the guest computer and used by the container instances, such as outsourced storage capacity.

[0029] In an advantageous embodiment, the alarm message is forwarded to a central alarm device, and alarm actions are carried out by the alarm device according to an alarm policy.

[0030] This allows alarm actions to be easily defined and deployed uniformly for all connected guest computers.

[0031] In an advantageous embodiment, the guest computer-specific integrity policy has a predefined maximum validity period and / or the guest computer-specific integrity policy is updated at cyclical intervals.

[0032] This prevents an attacker from securing old guest computer-specific integrity policies and from blocking further updates by an attacker.

[0033] According to a second aspect, the invention relates to a system for dynamic integrity monitoring of a container runtime environment executed on a guest computer, on which at least one container instance is executed and managed by means of an orchestration device, comprising the guest computer, comprising a container runtime environment, a receiving unit configured to receive a guest computer-specific integrity policy, an integrity detection unit configured to check resources allocated to at least one container instance against the guest computer-specific integrity policy, an output unit configured to issue an alarm message if a violation of the guest computer-specific integrity policy is detected during the check, and the orchestration device, comprising an integrity unit configured to create an instance-specific integrity rule concerning at least one resource of the guest computer allocated for the execution of the container instance when a container instance is started on the container runtime environment by the orchestration device.and to add the instance-specific integrity rule to a guest computer-specific integrity policy, which includes an instance-specific integrity rule for each container instance already running on the container runtime environment of the guest computer and is located in the orchestration device, and an output unit configured to transmit the guest computer-specific integrity policy to the guest computer, characterized in that the system is configured to perform the additional procedure steps: receiving a message in the orchestration device (11) when one of the container instances (18) on the guest computer (12) is terminated, and transmitting a guest computer-specific integrity policy (15) updated with respect to the message to the guest computer (12).

[0034] According to a third aspect, the invention relates to a guest computer comprising a container runtime environment, as well as a receiving unit configured to receive a guest computer-specific integrity policy, an integrity detection unit configured to check resources allocated to at least one container instance against the guest computer-specific integrity policy, and an output unit configured to issue an alarm message if a violation of the guest computer-specific integrity policy is detected during the check. er was mediated.

[0035] According to a fourth aspect, the invention relates to an orchestration device comprising an integrity unit configured to create an instance-specific integrity rule concerning at least one resource of the guest computer allocated for executing the container instance when a container instance is started on the container runtime environment by the orchestration device, and to add the instance-specific integrity rule to a guest computer-specific integrity policy that includes an instance-specific integrity rule for each container instance already running on the container runtime environment of the guest computer and is located in the orchestration device, and an orchestration interface configured to transmit the guest computer-specific integrity policy to the guest computer.

[0036] The system, the guest computer, and the orchestration device are configured to execute the described procedure.

[0037] The system, the orchestration device, and the guest computer offer the same advantages as the method.

[0038] A fifth aspect of the invention relates to a computer program product comprising a non-volatile, computer-readable medium that can be directly loaded into a memory of a digital computer, comprising program code segments which, when executed by the digital computer, cause it to perform the steps of the method.

[0039] Unless otherwise specified in the following description, the terms "start", "create", "add", "transmit", "verify", "output" and the like refer preferably to actions and / or processes and / or processing steps that modify and / or generate data and / or convert the data into other data, wherein the data may be represented or exist in particular as physical quantities, for example as electrical impulses.

[0040] The system and any optional components it may contain, such as the orchestration device, the guest computer, and the like, may include one or more processors. A processor may be, in particular, a central processing unit (CPU), a microprocessor, or a microcontroller, for example, an application-specific integrated circuit or a digital signal processor, possibly in combination with a memory unit for storing program instructions, etc.

[0041] A computer program product, such as a computer program tool, can be provided or delivered from a server in a network, for example, as a storage medium such as a memory card, USB stick, CD-ROM, DVD or as a downloadable file.

[0042] Exemplary embodiments of the method and the device according to the invention are shown in the drawings and are explained in more detail below. The drawings show: Fig. 1 shows an embodiment of the method according to the invention as a flowchart; Fig. 2 shows an embodiment of a system according to the invention in schematic representation; Fig. 3 shows an embodiment of an orchestration device according to the invention in schematic representation; and Fig. 4 shows an embodiment of a guest computer according to the invention in schematic representation.

[0043] Corresponding parts are marked with the same reference symbols in all figures.

[0044] Existing integrity monitoring systems are not ideally suited to detecting dynamic start and stop operations of individual container instances initiated by the orchestrator. Instead, they rely on a static rule set, which may be extended by querying orchestrator-specific deployment information. These methods monitor operations or file system changes on the orchestrated nodes, but operate independently of the orchestrator's runtime configuration. Therefore, existing instances not started by the orchestrator can only be detected if an anomaly detection component has runtime access to, for example, the orchestrator's metadata.If the connection between the orchestrator and the node is interrupted, or if the attacker is able to generate identical deployment information for a container instance without using the orchestrator, this cannot be detected with existing methods. The same applies to a potential licensing use case, for example, where it should be ensured that containers for an application are installed exclusively via the orchestrator and not manually on the device.

[0045] The basic idea of ​​the invention is that an orchestration device or management system of one or more nodes, in addition to orchestrating the container instance to be run on the nodes, dynamically creates device-specific integrity policies based on the runtime configuration specified by the orchestration device, and optionally performs integrity assurance for these policies using a signature. Hereinafter, a node managed by the orchestration device is referred to as a guest computer.

[0046] Based on the flowchart in Fig. 1 The inventive method for dynamically monitoring the integrity of a container runtime environment running on a guest computer, on which at least one container is executed and managed by means of the orchestration device, will now be described in more detail. For this purpose, a guest computer-specific integrity policy is created depending on the individual container instances running on the device or on the container runtime environment of the guest computer. The guest computer-specific integrity policy comprises a static part containing integrity rules for the overall operating system of the guest computer, which is extended to include instance-specific aspects. The static part of the guest computer-specific integrity policy performs integrity monitoring for the guest computer itself or for the guest computer's operating system.

[0047] For individual container instances, instance-specific integrity rules are first defined in isolation. The orchestration device performs the following steps for this purpose. In the first process step S1, when a container instance is started on the container runtime environment, the orchestration device creates an instance-specific integrity rule concerning at least one resource of the guest computer that is allocated for running the container instance.

[0048] The instance-specific integrity rule is created based on information about the container image from which the container instance is built. This information can be obtained, for example, from the container image's metadata. Alternatively or additionally, the instance-specific integrity rule can be created based on information from a provisioning file that specifies the container instance's configuration when it starts on the respective container runtime environment. The provisioning file-based approach is preferable if, for example, a target for write operations or a configuration of services defined within the container image is defined outside the container image, particularly via provisioning-specific variables or configuration files.In both variants, multiple instance-specific integrity rules can be linked together using one or more digital signatures of the orchestration device. The guest machine-specific integrity policy is protected by a digital signature of the orchestration device.

[0049] Next, at least one instance-specific integrity rule is added to a guest machine-specific integrity policy, see step S2. The guest machine-specific integrity policy is located in the orchestration device and includes at least one instance-specific integrity rule for each container instance already running on the guest machine's container runtime environment. A guest machine-specific integrity policy is created in the orchestration device, for example, when a guest machine is assigned to the orchestration device or when the first container instance is started on the guest machine. The guest machine-specific integrity policy is then passed from the orchestration device to the guest machine, see S3 and the containers.

[0050] When creating the dynamic part of the guest machine-specific integrity policy, the orchestration mechanism ensures that the instance-specific integrity rules specified by the container image and / or the deployment information apply exclusively to the resources defined in the container instance or deployment information, and do not apply to the guest machine itself or to the resources of other deployments—that is, applications running by container instances on the same guest machine. This is because the creator of an integrity rule set should only be able to create integrity rules or policies for their own application. This can be achieved by verifying whether the integrity rules associated with the deployment apply exclusively to resources of the deployment or to the image or the instance created from it itself.

[0051] The guest machine checks the resources allocated to the container instances running on it against the guest machine's specific integrity policy (see step S4). If the allocated resources do not match the specifications of the guest machine's specific integrity policy, an alert message is issued (see step S5). If the allocated resources do match the specifications of the guest machine's specific integrity policy, the check is terminated without further action (see step S6). Optionally, the check, its time, and the check result can be logged and saved. This allows for the chronological classification of any discrepancies between the actually allocated resources and the guest machine's specific integrity policy.

[0052] To create a guest machine-specific integrity monitoring policy based on the container instances currently running for an application, the orchestration device updates the guest machine-specific integrity policy whenever a change occurs on the guest machine. To do this, the orchestration device receives a notification from the guest machine when one of the container instances on the guest machine is terminated. The orchestration device then updates the guest machine-specific integrity policy according to the notification and sends it to the guest machine.

[0053] If one of the container instances terminates or fails, the guest computer actively sends a notification to the orchestration device. Alternatively or additionally, the orchestration device sends a status query to the guest computer. If the orchestration device manages multiple guest computers, it performs the described steps with each of the managed guest computers. A detected failure of one or more of the container instances results in the orchestration device removing the instance-specific integrity rules for the no-longer-existing container instances from the guest computer-specific integrity policy and generating an updated, new guest computer-specific integrity policy, which is then sent to the guest computer.

[0054] The guest machine-specific integrity policy is updated whenever an event that changes the composition and / or configuration of the container instances on the guest machine is detected in the orchestration device, and the updated guest machine-specific integrity policy is sent to the guest machine.Relevant events that lead to an update of the guest machine-specific integrity policy include starting at least one new container instance, for example through up- / downscaling to provide larger resources for an application; deploying at least one updated container image by adjusting the deployment configuration on the orchestration device, provided this deployment has changes on the desired guest machine; and detecting application crashes and restarting them by the orchestration device, possibly on a different guest machine according to the scheduling policy.

[0055] For integrity assurance, the dynamically generated guest-host-specific integrity policy should also have a maximum validity period and not only be updated based on events. The guest-host-specific integrity policy has a predefined maximum validity period. Alternatively and / or additionally, the guest-host-specific integrity policy is updated at cyclical intervals.

[0056] Fig. 2 Figure 1 shows an application example of the method in a system 10 according to the invention, comprising an orchestration device 11 and a guest computer 12. The system 10 can include further guest computers, here guest computers 13, which are managed by the orchestration device 11. The orchestration device 11 creates and updates a guest computer-specific integrity policy for each of these guest computers 12, 13, for example, the guest computer-specific integrity policy 15 for guest computer 12 and the guest computer-specific integrity policy 17 for guest computer 13. The guest computer-specific integrity policy 15 includes an instance-specific integrity rule 16 for each container instance 18 running on the guest computer 12.

[0057] System 10 describes the deployment of a container instance by a user 19. After the orchestration device 11 has selected the guest computer 12 for execution of the container instance, the orchestration device 11 receives an instance identifier of the container instance 18 to be monitored from the container runtime environment on the guest computer 12 and creates the associated instance-specific integrity rule 16 from the deployment information of the container instance 18 and / or a dynamic part of the guest computer-specific integrity policy 15 from the container image signature. The instance identifier can be further supplemented by the orchestration device with an identifier that identifies the guest computer.The dynamic part and a static part containing integrity rules for the guest computer's operating system form the guest computer-specific integrity policy, which is signed with a cryptographic key of the orchestration device 11. The guest computer-specific integrity policy 15 is then transmitted to the guest computer 12. In the next step, for example, container instance 18 is started.

[0058] The instance-specific assignment, i.e. the associated instance-specific integrity rule 16, ensures that an alert can be triggered as soon as container instances started outside the orchestration device 11 are detected.

[0059] Checking the guest computer-specific integrity policy 15 concerns the file system resources and / or network connection resources and / or process resources of the guest computer 12 that are assigned to the container instance en 18. Such a procedure is carried out, for example, by a "catch-all" rule, in which processes of all unknown container instances trigger an alarm by default.

[0060] The integrity of the guest computer's file system can thus be checked using the device-specific integrity policy 15. If its integrity is determined cyclically, a reference database is typically established for the files and directories to be monitored, as well as their metadata. Alternatively, integrity violations can be detected directly using appropriate dynamically generated audit rules or eBPF (extended Berkeley Packet Filter) programs. If detection is performed via reference databases, integrity monitoring must be disabled for each non-exclusive file system resource, both inside and outside the container instance 18.If a resource is no longer used because a container instance 18 is deleted, fails, or is terminated as planned, the status of the container instance is communicated either directly through an active notification by the guest computer 12 or through cyclical monitoring of the guest computer 12 by the orchestration device 11. The orchestration device 11 can recalculate the entries in the integrity database defined for the terminated container instance and does not need to recalculate the entire reference database.

[0061] Integrity checks for processes can be performed both within the process namespaces of individual container instances and for processes started on the underlying guest machine. To perform integrity monitoring on a container instance and guest machine level, the integrity monitor must be able to determine whether a process belongs to a container instance. This is achieved using at least one eBPF program or at least one kernel module that identifies the generated system calls and their parameters.

[0062] Integrity rules for network connections can be used to monitor which network connections are expected for each instance and trigger an alarm in case of policy violations. This data collection can also be performed using appropriate eBPF programs or kernel modules that capture specific system calls and analyze their parameters.

[0063] As soon as an integrity violation is detected on guest computer 12, an alarm message is generated and transmitted to an alerting device 14, which is preferably centrally located and processes alarm messages from multiple guest computers 12, 13, or even for multiple orchestration devices 11. The alerting device executes alarm actions according to an alerting policy and forwards them to the orchestration device 11. Depending on the alarm actions specified in the alerting policy, a final operation is performed on the orchestration device 11. For example, guest computer 12 is excluded from a scheduling for container instances of a predefined container type.

[0064] Fig. 3 Figure 20 shows an embodiment of an orchestration device 20 according to the invention. The orchestration device 20 comprises a user interface 21 through which a container instance is received from a user. The orchestration device 20 comprises an orchestration interface 22 through which the guest computer-specific integrity policy is transmitted to a guest computer managed by the orchestration device 20. The orchestration device 20 further comprises a storage unit 24 in which the guest computer-specific integrity policies of the managed and integrity-monitored guest computers are stored. The orchestration device 20 comprises an integrity unit in which instance-specific integrity rules for each container instance are created and inserted into the guest computer-specific integrity policy.

[0065] Fig. 4Figure 1 shows a guest computer 30. The guest computer 33 includes an input unit configured to receive a device-specific integrity policy from an orchestration device. The guest computer includes an integrity detection unit 33 for checking and detecting integrity violations and generating an alarm message. For individual aspects, such as file system integrity monitoring, a reference database can be configured on a separate, external device, which monitors the secured guest computer from there via issued commands.

[0066] The integrity detection unit 32 is designed to generate alarm messages and forward them via an output unit 21 to a central alarming device.

[0067] If the device-specific integrity policy is integrity-protected by means of a signature, the integrity detection unit 33 running on the guest computer can check whether the device-specific integrity policy has been compromised. If the integrity detection unit 33 detects a compromised device-specific integrity policy, an alert is also triggered. From this point on, the entire guest computer 30 is also considered compromised.

[0068] The device-specific integrity policy is dynamically adjusted for the managed guest machines by the orchestration device whenever a configuration change is made to running container instances, and applies to the entire guest machine. This dynamic creation of the integrity policy on a guest machine basis allows the orchestration device to detect when container instances managed outside of the orchestration device are running in addition to the container instances it defines. Guest machines identified as compromised can be excluded from the orchestration device's scheduling of defined or all container instances by means of an alert policy.

[0069] All process steps can be implemented by the appropriate devices suitable for executing the respective process step. All functions that can be performed by the features described can constitute a process step of the process. All described and / or drawn features can be advantageously combined within the scope of the invention. The invention is not limited to the described embodiments.

Claims

1. Method for dynamic integrity-monitoring of a container runtime environment executed on a host computer (12), in which environment at least one container instance (18) is executed and is managed by means of an orchestration device (11), comprising the steps: in the orchestration device (11), - creating (S1), in the course of the starting of the container instance (18) in the container runtime environment by the orchestration device (11), an instance-specific integrity rule (16) concerning at least one resource of the host computer (12) that has been allocated for the purpose of executing the container instance (18), - adding (S2) the instance-specific integrity rule (16) to a host-computer-specific integrity guideline (15) which comprises an instance-specific integrity rule (16) for each container instance already being executed in the container runtime environment of the host computer (12) and which is arranged in the orchestration device (11), - communicating (S3) the host-computer-specific integrity guideline (15) to the host computer (12), in the host computer, - checking (S4) the resources allocated on the host computer (12) by container instances (18) against the host-computer-specific integrity guideline (15), and - outputting (S5) an alarm message if a violation of the host-computer-specific integrity guideline (15) was ascertained in the course of the checking, characterized by the additional method steps: - receiving a notification in the orchestration device (11) if one of the container instances (18) on the host computer (12) is terminated, and - communicating a host-computer-specific integrity guideline (15), updated with respect to the notification, to the host computer (12).

2. Method according to Claim 1, wherein the host-computer-specific integrity guideline (15) is updated if an event that changes the composition and / or configuration of the container instances (18) on the host computer (12) is detected in the orchestration device (11), and the updated host-computer-specific integrity guideline (15) is communicated to the host computer (12).

3. Method according to Claim 2, wherein the event is at least one of the following actions: a failure of a container instance on the host computer (12), starting of a new container instance (18) on the host computer (12), updating of the container instance (18) in accordance with an amended container image, detection of an application crash and restart of affected container instances (18) on the host computer (12).

4. Method according to one of the preceding claims, wherein the instance-specific integrity rule (16) is created in a manner depending on information relating to a container image from which the container instance (18) is constructed.

5. Method according to one of the preceding claims, wherein the instance-specific integrity rule (16) is created in a manner depending on information from an item of provisioning information that specifies the configuration of the container instance (18) at the start of the container instance (18) in the respective container runtime environment.

6. Method according to one of the preceding claims, wherein the host-computer-specific integrity guideline (15) and / or the individual instance-specific integrity rules (16) contained therein is / are protected by means of a digital signature of the orchestration device (11).

7. Method according to one of the preceding claims, wherein the checking of the host-computer-specific integrity guideline (15) concerns the resources of a file system allocated to the container instances (18), and / or concerns network-connection resources and / or process resources.

8. Method according to one of the preceding claims, wherein the checking of at least a part of the host-computer-specific integrity guideline (15) is carried out outside the host computer (12).

9. Method according to one of the preceding claims, wherein the alarm message is forwarded to a central alarm-triggering device (14), and alarm actions are executed by the alarm-triggering device (14) in accordance with an alarm-triggering guideline.

10. Method according to one of the preceding claims, wherein the host-computer-specific integrity guideline (15) has a predetermined maximum period of validity, and / or the host-computer-specific integrity guideline (15) is updated at cyclic time intervals.

11. Host computer (12, 30) including a container runtime environment and also - a receiving unit (31) which is designed to receive a host-computer-specific integrity guideline (15), - an integrity-detection unit (33) which is designed to check resources allocated to at least one container instance (18) against the host-computer-specific integrity guideline (15), and - an output unit (32) which is designed to output an alarm message if a violation of the host-computer-specific integrity guideline (15) was ascertained in the course of the checking, characterized in that the host computer is configured to carry out the additional method steps: - communicating a notification to the orchestration device (11) if one of the container instances (18) on the host computer (12) is terminated, and - receiving a host-computer-specific integrity guideline (15), updated with respect to the notification, in the host computer (12).

12. Orchestration device (11, 20) including an integrity unit (23) which is designed - to create, in the course of the starting of a container instance (18) in the container runtime environment by the orchestration device (11, 20), an instance-specific integrity rule (16) concerning at least one resource of the host computer (12) that has been allocated for the purpose of executing the container instance (18), and - to add the instance-specific integrity rule (16) to a host-computer-specific integrity guideline (15) which comprises an instance-specific integrity rule (16) for each container instance (18) already being executed in the container runtime environment of the host computer (12, 30) and which is arranged in the orchestration device (11, 20), and an orchestration interface (22) which is designed to communicate the host-computer-specific integrity guideline (15) to the host computer (12, 30), characterized in that the orchestration device (11, 20) is configured to carry out the additional method steps: - receiving a notification in the orchestration device (11) if one of the container instances (18) on the host computer (12) is terminated, and - communicating a host-computer-specific integrity guideline (15), updated with respect to the notification, to the host computer (12).

13. System (10) for dynamic integrity-monitoring of a container runtime environment executed on a host computer (12, 30), in which environment at least one container instance (18) is executed and is managed by means of an orchestration device (11), including the orchestration device (11, 20) according to Claim 12 and a host computer (12, 20) according to Claim 11.

14. Computer program product comprising a non-volatile computer-readable medium which is directly loadable into a memory of at least one digital computer, comprising program code parts that, upon execution of the program code parts by the at least one digital computer, cause the latter to carry out the steps of the method according to one of Claims 1 to 10.