Method and system for handling at least one unauthorized access of at least one container instance to at least one common resource

Abstract

The invention claims a computer-implemented method for handling at least one unauthorized access of at least one first container instance (I2) to at least one common resource (R), in which the at least one first container instance and at least one second container instance (I1) are executed on a common runtime environment (L) of a host system (H), the at least one second container instance uses the at least one common resource, comprising the following method steps: specifying and providing at least one access authorization criterion (ZA, ZD) for one of the second container instances, the access authorization criterion specifies which operations including access of the at least one first container instance to the common resource are authorized or unauthorized; upon starting a new first container instance, checking whether at least one access authorization criterion has been provided for the second container instance; -when the check result is positive, monitoring the operations of the first container instance during the execution thereof to determine if the operations are unauthorized according to the at least one access authorization criterion; and-if at least one operation is identified as unauthorized during the monitoring, introducing a process to counteract access to the common resource by means of an alarm message for the second container instance or by stopping the execution of the second container instance.

Description

Technical Field

[0001] The present invention relates to a method and an apparatus as well as related devices and related computer program products. Background Art

[0002] Since industrial systems (control devices, industrial PCs, IoT (Internet of Things) and edge devices, cloud servers) are often used on site for a long time, they are subject to constantly changing premises (Voraussetzungen) and dynamic environments. To cope with these situations, new devices are developed mainly so that they can be flexibly adjusted during their use, for example through the support of downloadable applications or apps. Software containers (Software Containers), hereinafter referred to as containers, are suitable for this. Containers therefore constitute a virtualization of the runtime environment on a client computer (also called a host system) and encapsulate the applications of the underlying host system that run in the container. Currently, applications (also called applications) are implemented with the help of containers in many areas, such as in industrial automation and process control, as well as in transportation systems or vehicles.

[0003] To launch a container on a host system, a container image (also called a container image) is required. This container image contains, in addition to the application (also called application software), the binaries and libraries required by the application. A container image itself may consist of multiple layers built on top of each other, which can be protected (encrypted, memory-protected, etc.). Container images are typically portable and can be stored in a repository (also called a container registry) and shared with other users. On the host system, a container instance (in short, container) is created based on this container image and executed in a (container) runtime environment such as "Docker." As needed, for example, as user calls for an application increase, additional container instances can be generated and executed from the same container image on the same or different host systems, which can also be designed to virtualize hardware resources. The root file system of the container instance is formed from the image layers and another volatile layer. This allows multiple container instances ("clients") to use the host system's operating system kernel (also called the kernel) in isolation from each other. Hereinafter, the terms "container instance" and "container" are used synonymously.

[0004] When a container instance is started, execution rights, also called privileges, are assigned to the processes mentioned in the container instance, and agreements are also made regarding device resources or other file system resources of the underlying device or system. In order to prevent the application from launching attacks on the host system, these execution rights can be restricted (=constrained) so that only the rights required to run the application are assigned to the container. Containerized applications usually do not consist of a single independent container instance, but are provided as a whole application in conjunction with other container instances based on a microservice architecture. The mutual coordination of multiple container instances, or the mutual coordination of the virtual infrastructure of these container instances and in particular the runtime and process rights of these container instances, is defined in particular in the deployment information (also called deployment configuration). For this purpose, in a non-orchestration context, for example, the "docker-compose" format specified by Docker can be used.

[0005] In this mutual cooperation of multiple container instances, it is particularly critical that different container instances that are executed in isolation share the same operating system kernel.

[0006] Container instances equipped with corresponding privileges can perform actions in other container instances. In this case, the actions can be, for example: tracing a process; sending a process signal (such as kill); performing a write operation in a file system area assigned to another instance; or starting another process in the container. The runtime environment can only prevent such a container instance from performing such actions on another container instance by allowing or restricting certain permissions when the runtime environment starts the container instance. Certain runtime parameters need to be disabled in the configuration of the runtime environment. Under standard circumstances, containers are not allowed to use the namespaces of other containers. However, within the deployment configuration, it can be indicated that a container instance is allowed to use the namespace of another container instance. Namespaces provide options such as providing isolated areas of the operating system kernel for network connections, file system areas, or processes, and not all resources of the underlying system are visible to processes started in the namespace. In containerization technology, the use of namespaces is a fundamental component of the isolation of individual instances.

[0007] If a container instance cannot make any assumptions about what restrictions are enforced on the platform, then the container instance itself cannot assume that it is adequately isolated from other container instances, and therefore cannot assume that another container instance will not perform unauthorized reads or modifications.

[0008] For example, in the application example of the Industrial Edge (described, for example, at https: / / new.siemens.com / de / de / produkte / automatisierung / themenfelder / ind ustrial-edge.html), there is the option of different manufacturers offering different apps, for example in an App Store, which consist of multiple different containers and are installed on the device by the device operator in a similar way to smartphone apps. While the operator of the edge platform can define security requirements in this context, these may vary from application to application, so that an app or a first container instance running within an app would not be notified if a second / other container instance of another app accesses resources provided to the app.

[0009] A method has been disclosed in EP 21211418.5 for enforcing integrity conditions for a first container-based application relative to all second container-based applications executed on a common runtime environment of a host system. The technical solution is based on the assumption that the container runtime environment enforces the required restrictions on the entire host system and that these restrictions remain valid even when the corresponding App is running. Compliance with the guidelines defined by the application is only checked at deployment time. However, no further checks are performed at runtime. Containers running in the App to be protected will not be notified when containers of other Apps access these container instances and monitor processes, start new processes, or perform write operations in their namespaces. In addition, violations of guidelines (also called policies) cannot be handled in an application- or container-instance-specific manner. If the requirements are not met, the deployment of the application will be rejected.

[0010] Integrity monitoring systems such as Falco (https: / / falco.org / ) are known. With the help of such solutions, integrity requirements for the container itself can be checked on the underlying host system using static rules. However, with Falco-based solutions, it is not possible to check, for example, whether processes in the underlying host namespace are being tracked by other containers with corresponding privileges, or whether so-called sidecar containers that modify the network configuration of the container instance have been started. A "sidecar" is another container that shares resources, such as the network namespace or the container file system. In addition, Falco only issues alerts outside the container and does not directly notify the container instance, so that error handling (such as re-reading the configuration or disabling before recognizing that a permitted operation has been performed) may be performed within the app or container instance.

[0011] Therefore, while platform operators can receive alerts, app developers who create deployment configurations and container images cannot define independent integrity requirements and create runtime-related operational instructions derived from them. Summary of the Invention

[0012] The present invention is therefore based on the object of designing a method and a system that ensure improved handling of at least one unauthorized access to one or more common resources by a container instance that is executed in a runtime environment together with other container instances that use the common resources and in which an application runs.

[0013] This object is achieved by the features according to the independent claim. Advantageous embodiments of the invention are described in the dependent claims.

[0014] The present invention claims a computer-implemented method for handling at least one unauthorized access to at least one common resource by at least one first container instance, wherein the at least one first container instance and at least one second container instance are executed on a common runtime environment of a host system, wherein the at least one second container instance uses the at least one common resource, the method comprising the following method steps:

[0015] - defining and providing at least one access authorization criterion for one of the second container instances, the access authorization criterion defining which operations, including access to or influence on the public resource by the at least one first container instance, are authorized or permitted or unauthorized or prohibited;

[0016] - when starting a new first container instance, checking whether at least one access authorization criterion has been provided for the second container instance;

[0017] - when the result of the check is positive, the operations of the first container instance are monitored during their execution to determine whether these operations are unauthorized according to the at least one access authorization criterion; and - if at least one operation is identified as unauthorized during the monitoring, a process of resisting or preventing access to the common resource is introduced by means of an alarm message to the second container instance or by stopping the execution of the second container instance.

[0018] In this context, cease and desist may mean interruption or termination.

[0019] When the check result is negative, the operation of the first container instance can be monitored, and if all operations that access or affect public resources are considered unauthorized from the perspective of the runtime environment (deny by default), then when such unauthorized operations are performed, a process of resisting or preventing access to public resources is introduced with the help of an alarm message to the second container instance or by stopping the execution of the second container instance.

[0020] In this context, on the one hand, common resources are understood to be common namespaces shared by multiple container instances. On the other hand, common resources are understood to be the parent namespace used by the host system, from which, when multiple container instances are started, multiple child namespaces are generated for the corresponding container instances. These child namespaces run independently for each container instance, without the situation where a container instance shares the corresponding child namespace with another container instance. However, common resources may also be file system objects and device files, which are typically files or directories / folders. If such objects or files are designed in virtual form, a parent-child relationship similar to that of namespaces applies. If these objects or files are designed in physical form, they are located on the host system. If necessary, multiple container instances access them through the runtime environment.

[0021] In this way, container instances can be isolated from each other by running their processes in separate namespaces. The namespace concept enables the isolation of networks, processes or mounted file systems. Separate namespaces exist for the respective application cases. Furthermore, namespaces typically have a hierarchical structure, so that when a container instance is started, a child namespace of the respective host namespace is generated. When started, container instances can run completely in their own namespace or together in a shared namespace. In this case, it is not necessary for all container instances to share all namespaces, but rather individual types of namespaces; for example, only the network namespace. The latter is used for so-called sidecar containers, which, for example, implement transparent proxies (delegates) for workload containers. For containers with corresponding privileges, these can also run in the host namespace and therefore in the parent namespace of other container instances.

[0022] In other words, other container instances, here the first container instance, are monitored when they access common resources of the container instance to be protected (here the second container instance) and there is at least one corresponding access authorization criterion.

[0023] Therefore, in the event of unauthorized access, the "external" container instance (here, the first container instance that has been started) is not protected, but the corresponding processing or measures at its disposal are used to protect its own container instance (here, the second container instance).

[0024] The at least one access authorization criterion may be included in a container image belonging to the second container instance and / or referenced in deployment information (deployment configuration) that can be used in the runtime environment to execute the at least one second container instance.

[0025] Authorization criteria can be designed so that corresponding tags / labels are used to identify operations as permitted or unauthorized / prohibited. The at least one authorization criterion can be designed as a rule set, which can be integrity-protected along with the deployment configuration or container image via a signature. This prevents unauthorized modification. The signature can be verified by the runtime environment at deployment time. Whether an alarm message should be issued or execution of the second container instance to be protected should be halted can be derived from the at least one access authorization criterion.

[0026] The method is preferably designed as a computer / computer-aided or computer-implemented method, or is preferably implemented as a computer / computer-aided or computer-implemented method. The steps of the method can be repeated as often as desired and, if necessary, the repetition can be terminated according to defined conditions (whether event-oriented or time-limited).

[0027] The monitoring function can be designed as a reporting client for the container instance; the monitoring function can be integrated on the device / host system (eg, a plug-in / agent), but can also run on a remote system outside the host system.

[0028] Another aspect of the present invention is a system adapted to handle at least one unauthorized access to at least one common resource by at least one first container instance, wherein the at least one first container instance and at least one second container instance are executable on a common runtime environment of a host system, wherein the at least one second container instance uses the at least one common resource, the system comprising a provision unit and a monitoring unit, wherein the provision unit and the monitoring unit are designed such that:

[0029] - defining and providing, by the providing unit, at least one access authorization criterion for one of the second container instances, the access authorization criterion defining which operations, including access to the public resource by the at least one first container instance, are authorized or unauthorized; and

[0030] - by the monitoring unit, when starting a new first container instance, checking whether at least one access authorization criterion has been provided for the second container instance; and

[0031] - if the result of the check is positive, the operations of the first container instance are monitored by the monitoring unit during their execution to determine whether these operations are unauthorized according to the at least one access authorization criterion; and

[0032] If at least one operation is identified as unauthorized during this monitoring, a blockade of access to the common resource is initiated by means of a warning message to the second container instance or by stopping the execution of the second container instance.

[0033] The monitoring unit may be designed as a reporting client for the container instance; the monitoring function may be integrated on the host system (eg, a plug-in / agent), but may also run outside the host system on a remote system.

[0034] The provisioning unit can also be integrated into the host system (e.g., as a plug-in / agent). The runtime configuration is generated, for example, by a deployment configuration provided by the provisioning unit and previously specified, for example, by an app developer or app provider, such as starting / stopping a container instance, by the runtime environment, and optionally by updates, and by external tools for controlling access to common resources by other container instances. This deployment configuration can also be automatically specified by corresponding software tools and particularly includes so-called default configurations.

[0035] A computer program product can also be used, which includes 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 a device according to one of the above-mentioned embodiments, or in a distributed manner in multiple devices according to one of the above-mentioned embodiments.

[0036] Additionally, protection is claimed for a variant of the computer program product having program instructions for configuring a construction device, such as a 3D printer, a computer system, or a manufacturing machine suitable for constructing processors and / or devices, wherein the construction device is configured using these program instructions so that the execution environment can be created.

[0037] A system or device, unit or apparatus and a computer program (product) that may include a loadable and executable program code or a distributively loadable and distributively executable program code module may be designed according to the extended schemes / implementations of the above-mentioned methods and their extended schemes / implementations, and vice versa.

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

[0039] The processor or processor unit can be, in particular, a central processing unit (CPU), a microprocessor or microcontroller, such as an application-specific integrated circuit or a digital signal processor, etc., which may be combined with a memory unit for storing program instructions. The processor can also be, for example, an IC (Integrated Circuit) or a multi-chip module, in particular an FPGA (Field Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit), an SoC (System on Chip), a graphics processing unit (GPU), a processor for evaluating neural networks, such as a TPU (Tensor Processing Unit) or a DSP (Digital Signal Processor). The processor can have one or more computing cores (multi-core). The processor can also be understood as a virtual processor, a virtual machine, or a soft CPU. For example, it can also be a programmable processor that is equipped to implement the configuration steps of the method according to the present invention, or the programmable processor is configured using configuration steps so that the programmable processor implements the method, other aspects of the present invention, and / or partial aspects of the features according to the present invention. The processor may have tamper protection to prevent physical tampering, such as a tensor sensor to detect physical attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Exemplary embodiments of the method and the transmission device according to the invention are shown by way of example in the drawings and are explained in more detail in the following description.

[0041] The FIGURE shows an exemplary arrangement in which the method according to the invention can be applied. DETAILED DESCRIPTION

[0042] The figure shows a host system H with a runtime environment L, which includes a monitoring unit W and a provisioning unit B. These two units W and B can also be combined into a single unit. At the operating system level, the runtime environment exchanges instructions or commands with the kernel K. The kernel ultimately controls operations. When developing an application or app that can run in a container instance, before launching a container instance I1 for the application, a deployment configuration DK is specified for the application or for the container image A from which the container instance to be launched is generated using the runtime environment. This deployment configuration (also known as deployment information) can also be specified by the app provider via an app store. The deployment configuration specifications can also be automatically generated based on the app type, using standard values ​​(default values) if necessary. In addition, at least one access authorization criterion can be specified, if necessary, during development or automatically (see above), and provided via an app store or other download platform if necessary. The following variations of the at least one access authorization criterion can also be used in combination. Deployment-based access rules ZD are provided for the container instance I1 to be protected and / or image-based access rules ZA are provided for the container instance. In this example, these access rules are loaded from provisioning unit B in step 2. In step 1, runtime environment L generates at least one resource R for container instance I1, and in step 3, also starts container instance I1, which uses the generated at least one resource R. In step 4, another container instance I2 is started. Because container instance I2 performs an operation on resource R (referred to as a public resource) in step 5, container instance I2 is monitored according to the present invention. The public resource may include: a namespace used by each container instance and / or a namespace used by the host system and / or a file system object and / or a device file. In this example, a namespace is used as the public resource. The present invention can be applied to file system objects or device files in a similar manner.

[0043] A namespace can be a process namespace, a network namespace, or a mount namespace (a file or directory mount). In this example, the host system has a process namespace HP, a network namespace HN, and a mount namespace HM. In step 1, the runtime environment illustratively generates a process namespace P, a network namespace N, and a mount namespace M belonging to the container instance I1. In this example, these namespaces constitute a common resource R.

[0044] Furthermore, in step 5, monitoring rules are passed to the kernel K in the form of commands. These monitoring rules can be derived from the access rules, provided that, when launching container instance I2, monitoring unit W has checked whether these access rules refer to the launched container instance I1. Such commands can be provided to the kernel, for example, via an eBPF program (eBPF = Extended Berkeley Packet, https: / / ebpf.io / ).

[0045] According to the present invention, for the container instance to be protected (I1 in this example), all operations of other container instances (I2 in this example) are monitored, as long as these operations involve their namespaces. If unauthorized or impermissible access occurs in the namespace of the container instance to be monitored, the container instance is either stopped (terminated or interrupted) by the container runtime environment, or an alarm notification is sent by the container runtime environment to the so-called initialization process with the help of a corresponding process signal (see step 6 in the figure). To this end, in the access rules, it is defined which operations of other container instances are allowed in the namespace of the container instance to be monitored. A default deny (Deny-By-Default) can also be defined for all container instances. The allowed operations are usually system calls and, if necessary, can also be extended to permissions (Capabilities) or so-called Seccomp profiles (https: / / docs.docker.com / engine / security / seccomp / ), because permissions (Capabilities) and Seccomp profiles define a set of allowed system calls. Likewise, in a manner similar to the initially mentioned Falco, the corresponding system call parameters can be checked and, for example, it can be determined therefrom which object (eg, a process ID, a network interface, or an object in the file system) was referenced by the system call.

[0046] The container instances I2 to be monitored are identified by checking which namespaces they share with the container instance I1 to be protected, or whether they are running in the parent namespace of the container instance to be monitored (e.g., the host process namespace HP).

[0047] Access rules are associated with either the image or deployment configuration of the container instance being protected. In access rules, the protected container instance is referenced by its deployment or image tag, or by the corresponding signature assigned by the container runtime. Access rules also define the action to be taken when the access rule set is violated. In this case, the action might be a kill signal or other process signal to be applied to the initialization process of the protected container instance.

[0048] Permitted operations in the process namespace P and / or HP can, for example, be starting a new process, performing a trace, or generally just reading the process namespace. In the mount namespace, embodiments include reading the mount namespace, performing a write operation, or changing a mount point. In the network namespace, in addition to reading the network namespace, embodiments of permitted operations include changing routes, opening new ports, or, for example, activating firewall rules. When starting the container instance to be protected, the container runtime environment or monitoring unit W reads in the access rules associated with the container instance to be protected and loaded by the provisioning unit. The monitoring unit can monitor the operations of the container runtime environment as an extension of the runtime environment (e.g., as a plug-in) or alternatively as an independent server process (similar to Falco). In the case of a server variant, the kernel K can read the startup operation of the container on the runtime environment, for example, through an eBPF program or a correspondingly provided module. The runtime environment can also notify the monitoring unit via a corresponding interface that the container instance to be protected is to be started. In the case of this server variant, the access rules are also read in at the latest when the container instance is started.

[0049] Then, the namespace required by the container instance is generated (see 1 in the figure). Preferably, the container runtime environment is trusted. Only operations on the namespace of the container instance to be protected by other monitored container instances are monitored, and processes managed outside the container runtime environment (such as system services) are not monitored.

[0050] Whether to monitor a container instance to be started depends on whether the container instance directly shares a namespace with the container instance to be protected or runs in a parent namespace on the host system; and whether corresponding access rules are defined and provided for the container instance to be protected.

[0051] First, the following describes the situation where the container instance to be monitored and the container instance to be protected share one or more namespaces:

[0052] When a new container instance is launched, a monitoring unit or a separate server process integrated into the container runtime environment checks whether the container instance is to be monitored. This is done by checking whether at least one access rule applies to the container instance based on the assigned tag / label or signature, and whether the namespace is shared with the newly launched container instance. If so, the monitoring unit automatically generates an eBPF program or a corresponding kernel query using a module. These programs or kernel queries examine the initialization process of the newly launched container instance and all existing child processes, monitoring the relevant system calls and parameters according to the criteria. If a new process is launched within the monitored container instance, it is also newly added and monitored by the same eBPF program. If at least one access rule violation is detected, the kernel reports the violation to the monitoring unit. Based on the measures stored in the access rules, the monitoring unit stops the initialization process of the protected container instance with a kill signal or sends a corresponding alarm process signal to the initialization process. In the latter case, the container image developer can customize the behavior of the application running in the container instance. Through this, the container instance can, for example, restart individual child processes or disable certain functions before the application is restarted as planned. The container instance can also, for example, use write operations on a persistent drive to persist the disallowed access of the container instance to be protected across runtimes, thereby ensuring that the application is provided in a reduced scope or is no longer launched in the container instance to be protected until the user manually resets it.

[0053] If the container instance I2 to be monitored enters the parent namespace of the namespace to be protected, the operation to be monitored is determined in a manner similar to the above-mentioned method for the same namespace. However, in addition, other operations are required: for the process namespace, processes can only be started within the namespace when the container to be monitored is switched to the namespace to be protected with the help of setns (https: / / linux.die.net / man / 2 / setns) or is started in the namespace by the runtime environment with the help of deployment configuration. However, the processes running therein can also be tracked or stopped when the processes of the container instance I2 to be monitored access these processes in the parent namespace and are not switched to its namespace. In this regard, in the case of the process namespace, the monitoring unit must determine: which process IDs the processes to be monitored of the container instance I1 to be protected have in the parent namespace. The same situation applies to the mount namespace. In this case, when launching a container instance to be monitored, the monitoring unit must monitor the path names of the mount namespace in the parent host namespace and monitor operations performed with respect to these paths. Regarding the network namespace, the monitoring unit checks whether changes are made within the network namespace via system calls in the parent node of the container to be monitored, and whether these changes involve the network namespace assigned to the container to be protected.

[0054] By monitoring the container processes of the container instances to be monitored in each namespace, application developers can also avoid: running transparent proxies on the cluster with the help of sidecar containers, which run in the same network namespace as the service mesh.

[0055] The at least one access rule can be integrity-protected along with the deployment configuration or container image by a signature, thereby preventing unauthorized modification. To this end, the signature must be verified by the runtime environment at deployment time.

[0056] Although the present invention has been further illustrated and described in detail by means of preferred embodiments, the present invention is not limited to the disclosed examples and other variations may be derived therefrom by those skilled in the art without departing from the scope of protection of the present invention.

[0057] The implementation of the process or method described above can be implemented according to the following commands, which are stored on a computer-readable storage medium or in a volatile computer memory (hereinafter generally referred to as computer-readable memory). Computer-readable memory includes, for example, volatile memory such as cache, buffer, or RAM; and non-volatile memory such as a removable disk, hard disk, etc.

[0058] Here, the functions or steps described above may be present in / on a computer-readable memory in the form of at least one command statement. These functions or steps are not tied to a specific command statement, a specific form of a command statement, a specific storage medium, a specific memory, or a specific implementation, and may be implemented independently or in any combination via software, firmware, microcode, hardware, a processor, an integrated circuit, or the like. Various processing strategies may be employed, such as serial processing by a single processor, multiprocessing, multitasking, or parallel processing.

[0059] These commands can be stored in a local memory, but it is also possible to store these commands on a remote system and access this remote system via a network.

[0060] In the context of the present invention, "computer / computer-aided" or "computer-implemented" may be understood, for example, to mean an implementation of the method, wherein at least one method step of the method is performed, in particular by a processor, which may be part of a (control / computing) device or unit. In this case, the method may also be implemented in a computer cloud (Cloud), which can execute the method and thereby provide the method results to a (control / computing) device or unit, which can issue corresponding instructions or initiate corresponding measures, in particular to the aforementioned devices.

[0061] Unless otherwise stated in the subsequent description, the terms "mapping", "simulation", "receiving", "applying", "outputting", "providing" etc. preferably relate to operations and / or processes and / or processing steps that change and / or generate data and / or convert these data into other data, wherein these data can in particular be presented or exist as physical quantities.

[0062] The terms "processor," "central signal processing unit," "control unit," or "data analysis unit" include processing devices in a broad sense, such as servers, general-purpose processors, graphics processors, 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 developed in the future. A processor may be composed of one or more devices, units, or devices. If a processor is composed of multiple devices, these devices may be designed or configured to process or execute commands in parallel or serially.

Claims

1. A computer-implemented method for handling at least one unauthorized access by at least one first container instance (I2) to at least one public resource (R), wherein: The at least one first container instance and the at least one second container instance (I1) are executed on a common runtime environment (L) of a host system (H), wherein the at least one second container instance uses the at least one common resource, and the method comprises the following method steps: - defining and providing at least one access authorization criterion (ZA, ZD) for one of the second container instances, said access authorization criterion defining which operations, including access to the common resource, by the at least one first container instance are authorized or not authorized; - when starting a new first container instance, checking whether at least one access authorization criterion has been provided for the second container instance; - if the result of the check is positive, the operation of the first container instance is monitored during its execution to determine whether the operation is unauthorized according to the at least one access authorization criterion; and If at least one operation is identified as unauthorized during said monitoring, introducing a blockade of access to said common resource by means of a warning message to said second container instance or by stopping the execution of said second container instance.

2. The method according to the preceding claim, It is characterized by: When the check result is negative, the operation of the first container instance is monitored, and if all operations that access or affect the public resource are considered unauthorized from the perspective of the runtime environment, when such unauthorized operations are performed, a process of resisting access to the public resource is introduced by means of an alarm message to the second container instance or by stopping the execution of the second container instance.

3. The method according to any one of the preceding claims, It is characterized by: The at least one common resource includes: a namespace used by each container instance and / or a namespace used by the host system and / or a file system object and / or a device file.

4. The method according to any one of the preceding claims, It is characterized by: The at least one access authorization criterion is contained in a container image (A) belonging to the second container instance and / or is referenced in deployment information (DK) that can be used by the runtime environment to execute the at least one second container instance.

5. The method according to any one of the preceding claims, It is characterized by: From the at least one access authorization criterion it can be derived whether a warning message should be issued or the execution of the second container instance should be stopped.

6. A system adapted to handle at least one unauthorized access by at least one first container instance (I2) to at least one public resource, wherein: The at least one first container instance (I2) and the at least one second container instance (I1) are executable on a common runtime environment (L) of a host system (H), wherein the at least one second container instance uses the at least one common resource (R), and the system comprises a providing unit (B) and a monitoring unit (W), wherein the providing unit and the monitoring unit are designed such that: - defining and providing, by the provisioning unit, at least one access authorization criterion (ZA, ZD) for one of the second container instances, said access authorization criterion defining which operations, including access to the common resource, by the at least one first container instance are authorized or not authorized; and - checking, by the monitoring unit, when starting a new first container instance, whether at least one access authorization criterion has been provided for the second container instance; and - if the result of the check is positive, the operation of the first container instance is monitored by the monitoring unit during its execution to determine whether the operation is unauthorized according to the at least one access authorization criterion; and If at least one operation is identified as unauthorized during said monitoring, introducing a blockade of access to said common resource by means of a warning message to said second container instance or by stopping the execution of said second container instance.

7. System according to the preceding claim, It is characterized by: When the check result is negative, the operation of the first container instance is monitored, and if all operations that access or affect the public resource are considered unauthorized from the perspective of the runtime environment, when such unauthorized operations are performed, a process of resisting access to the public resource is introduced by means of an alarm message to the second container instance or by stopping the execution of the second container instance.

8. A computer program product comprising a non-volatile storage medium, on which is stored a loadable and executable program code or a distributively loadable and distributively executable program code module, wherein the program code or the program code module executes the method according to any one of the above method claims in a system according to the above system claim.

Images