Method for the computer-supported restricting of persistent memory for a container-based application

Abstract

The invention relates to a method for the computer-supported restricting of persistent memory for a container-based application (AP), wherein a number of container instances (CIN1, CIN2) are assigned to the application (AP), wherein a number of first users (UC1, UC2) are contained in the number of container instances (CIN1, CIN2), wherein a respective first user (UC1, UC2) is a container-specific user in a corresponding container instance (CIN1, CIN2), wherein: - to configure the number of container instances (CIN1, CIN2) a piece of configuration information (CO) is provided that defines, for each first user (UC1, UC2), a storage limit of persistent memory on at least one memory partition of the specified operating system (OS); - during configuration of the number of container instances (CIN1, CIN2) a user assignment (UAS) is defined, according to which another second user (UOS1, UOS2) is assigned to each first user (UC1, UC2) in the specified operating system (OS), which second user is unique across the number of container instances (CIN1, CIN2) and for which the storage limit of the respective first user (UC1, UC2) is valid; - the number of container instances (CIN1, CIN2) are started based on the user assignment (UAS), wherein with the aid of the second user or users (UOS1, UOS2) the storage limit for each first user (UC1, UC2) is adhered to.

Description

[0001] Description

[0002] Method for computer-assisted restriction of persistent memory for a container-based application

[0003] The invention relates to a method for computer-aided restriction of persistent memory for a container-based application as well as a corresponding computer program product and a corresponding computer program.

[0004] It is known from the state of the art to store executable programs in the form of applications in one or more containers, thereby achieving appropriate encapsulation of the application. Containerization technologies exist for this purpose, such as the "Docker" software for the Linux operating system.

[0005] To run a container-based application from one or more containers, corresponding container instances are configured for the respective containers, which are started when the application is executed.

[0006] There is often a need to persist the data generated by a container-based application, i.e. to store it in a non-volatile memory so that the data is available for certain devices (such as sensors) or other applications.

[0007] To persist data within a container instance during the runtime of an application, a persistent storage partition of the underlying operating system can be integrated or mounted into the container so that the associated container-based application can perform modification operations on the persistent storage partition. Typically, the persistent storage partition is shared between different container instances. By using source directories within the storage partition, to which only a single container instance has access, it is possible to prevent the container instances from writing to the same directory.Nevertheless, the problem remains that one or more container instances can continue to allocate the entire memory partition and then no persistent storage space is available for other container instances, which therefore can no longer persist data.

[0008] Currently, there are no adequate solutions for limiting persistent storage for container instances of an application. While it is possible to define separate storage partitions for individual container instances, this has the disadvantage that the number of storage partitions that can be created is limited and the processes for creating the storage partitions are very complex.

[0009] From US 2022 / 083383 Al it is known to configure resource limits for containers in the Linux operating system with the help of Linux Security Modules LSM and Extended Berkeley Program Format (eBPF) programs, including the memory allocation SGX EPC.

[0010] Furthermore, the current state of the art allows for regulating the storage requirements on a storage partition using so-called disk quotas, which define storage limits for users or user groups on an operating system's file system. However, disk quotas are not intended to limit persistent storage for container instances.

[0011] The object of the invention is to create a method with which persistent memory for a container-based application can be restricted in a simple manner.

[0012] This object is achieved by the method according to patent claim 1 or the computer program product according to patent claim 7 or the computer program according to patent claim 8. Further developments of the invention are defined in the dependent claims. The method according to the invention serves for the computer-aided restriction of persistent memory for a container-based application. Container-based applications are known per se from the prior art. A container-based application is assigned a number of container instances (i.e. one or more container instances), which are configured within the framework of the method according to the invention and subsequently started to execute the application on a predetermined operating system. If, for example, Linux is used as the predetermined operating system, the container instances can be created using the known containerization technology "Docker".

[0013] The number of container instances includes a number of first users (i.e., one or more first users), each of which is used to execute at least one process in the number of container instances after their start. A respective first user is a container-specific user in a corresponding container instance from the number of container instances. The definition of container-specific users with corresponding user identities, which are responsible for executing one or more processes in a container instance, is known per se from the prior art. The first user is a (non-human) technical user who is given corresponding authorization to execute one or more processes of the corresponding container instance.

[0014] Within the scope of the method according to the invention, configuration information is or is provided for configuring the number of container instances, which configuration information defines a memory limit on persistent memory on at least one memory partition of the specified operating system for each first user. The term memory limit is to be understood broadly. The memory limit can, for example, be given by directly specifying a maximum memory size. The memory limit can also be defined indirectly, for example by only a certain number of files and / or only files up to a certain size being allowed to be written to the corresponding persistent memory. A memory limit can, if necessary, also be defined for a respective first user via a user group. The memory is limited for all first users who belong to the same user group.

[0015] In the method according to the invention, when configuring the number of container instances, a user assignment is defined, according to which each first user is assigned a different second user, which is unique across the number of container instances and for whom the memory limit of the respective first user applies. A respective second user is a user with a corresponding user identity in the predetermined operating system, who was not used or was assigned in this operating system before being assigned to the first user. Such second users can be defined at the operating system level, e.g. using the disk quota mechanism described above.

[0016] The number of container instances is finally started based on the user allocation described above. In this case, the memory limit for each first user is respected for the number of started container instances by means of the second user(s). In other words, when the corresponding container instances are started, the user allocation is taken into account when mounting the file systems of the container instances into the file system of the specified operating system, so that the memory limit for a respective second user is applied when a process is executed by the corresponding first user. Consequently, a first user is not allowed to write to the corresponding memory partition if the memory limit for this user is exceeded.The method according to the invention has the advantage that the persistent memory for a container-based application can be easily limited by clearly assigning container-specific users to operating system users. The memory limits can be flexibly changed by appropriate adjustments to the configuration information.

[0017] In a preferred variant of the method according to the invention, in the configuration information at least some of the first users of the number of first users are assigned to one or more user groups, wherein each user group is assigned the same memory limit for all first users contained therein. In other words, each first user of at least some of the first users belongs to a corresponding user group, wherein there can be one or more user groups. With this embodiment the configuration information can be structured in a simple way since first users with the same memory limit are combined into a group and thus the memory limit no longer has to be specified separately for these users.

[0018] In a further preferred embodiment of the method according to the invention, the memory limit for a respective first user of the number of first users for one or more directories of a container-specific file system is specified in the configuration information, i.e. the memory limit relates to one or more directories within the corresponding container to which the respective first user is permitted to access. The configuration information also specifies the at least one memory partition of the predetermined operating system that corresponds to the directory or directories of the container-specific file system. In an alternative variant, it is also possible for the memory limit for a respective user to directly specify the at least one memory partition of the predetermined operating system in the configuration information.

[0019] The method according to the invention can be used for different operating systems. However, in a preferred variant, Linux is used as the default operating system. When using Linux, the user assignment described above can be determined based on the user namespace mechanism known from this operating system. The use of user namespaces is known per se. These user namespaces will be discussed in more detail in the detailed description.

[0020] In a further preferred embodiment, the configuration information is provided as default configuration information if no other configuration information is provided for the container-based application. This ensures that an application is started with default memory limits, even if no application-specific configuration information is available.

[0021] In a further preferred embodiment of the method according to the invention, when determining the user assignment, it is checked whether the memory limit is permissible for a respective first user of the number of first users, wherein the admissibility can be determined based on any admissibility criteria. If one or more inadmissible memory limits exist, these inadmissible memory limits are rejected in one variant, i.e. the method is continued without taking the inadmissible memory limits into account. Alternatively, the inadmissible memory limits can also be replaced by permissible memory limits. In a further alternative, it is also possible for the method to be aborted due to the inadmissible memory limits.If the configuration information contains storage limits based on directories of a container-specific file system, as described above, invalid storage limits exist, for example, if different storage limits are specified for two container-specific directories, even though the directories are located on the same storage partition.

[0022] In a further preferred embodiment, the user assignment, which is determined during the configuration of the number of container instances, is stored beyond the termination of the inventive method. In this way, it is achieved that the defined user assignment can be accessed when the method is carried out again without it having to be determined or specified again. Nevertheless, it is also possible for the user assignment to be re-implemented each time the inventive method is carried out again. This ensures that any changes to the operating system that have occurred in the meantime are appropriately taken into account.

[0023] In a further preferred embodiment, the container-based application is executed in a data network, wherein the data network is preferably intended for controlling an automation system. The invention is thus preferably used in an industrial environment.

[0024] In a preferred variant, the data network in which the container-based application is executed is a so-called edge computing network with a large number of edge nodes or edge devices, wherein the container-based application is executed on one edge device of the large number of edge devices and the at least one memory partition is provided on the edge device. Edge computing networks are known per se from the prior art. Such networks are frequently used in industrial applications. Nevertheless, the invention is not limited to edge computing networks and can also be used in other data networks, such as cloud-based networks.

[0025] In addition to the method described above, the invention relates to a computer program product with a program code stored on a machine-readable carrier for carrying out the method according to the invention or one or more preferred variants of the method according to the invention when the program code is executed on a computer.

[0026] Furthermore, the invention relates to a computer program with a program code for carrying out the method according to the invention or one or more preferred variants of the method according to the invention when the program code is executed on a computer.

[0027] An exemplary embodiment of the invention is described in detail below with reference to the attached Fig. 1. This figure shows a schematic representation illustrating the sequence of a variant of the method according to the invention.

[0028] The embodiment of the invention explained below with reference to Fig. 1 relates to the restriction of persistent memory for a container-based application AP, which, for example, contains the software containers CI and C2. The application AP is executed with a known container runtime environment on the operating system OS. For this purpose, a container instance CIN1 of the container CI and a container instance CIN2 of the container C2 are started using the container runtime environment CE. Without loss of generality, it is assumed below that the operating system OS is Linux.

[0029] The container-based application can be based on a known containerization technology. Preferably, the software "Docker" is used as the containerization technology. The container-based application AP can, for example, be an application in a cloud computing network. However, the application preferably runs in an edge computing network, where – in contrast to a cloud computing network – operations are performed locally at the edge of the network in so-called edge nodes or edge devices, with the application AP running on one of the edge devices.

[0030] In a manner known per se, a user UC1 is assigned to the container instance CIN1 and a user UC2 is assigned to the container instance CIN2, whereby the users are technical (non-human) users for whom appropriate authorization to run the associated container instances CIN1 or CIN2 is stored. The users UC1 and UC2, which represent first users within the meaning of claim 1, are container-specific users that are defined locally or encapsulated for the container instances CIN1 and CIN2. This means that the user UC1 is a container-specific user for the container C1 or the corresponding container instance CIN1 and the user UC2 is a container-specific user for the container C2 or the corresponding container instance CIN2.If necessary, a respective container instance can also contain several users, each of whom is separately assigned one or more processes that are executed by the respective container instance.

[0031] Before running the application AP or starting the corresponding container instances CIN1 and CIN2, the container instances are configured based on the underlying containers. For configuration, configuration information CO is used in the form of a corresponding configuration file, which, in addition to known configuration settings, also contains limit information QI, which defines a corresponding limit for the respective container-specific users UC1 and UC2 on their usable persistent storage space on a storage partition of a physical storage ST in the underlying operating system OS. In the embodiment of Fig. 1, a known orchestrator OR (e.g. Kubernetes) is used, which manages several container runtime environments and selects the runtime environment that executes the application AP according to certain criteria. In Fig.1, this is the runtime environment CE (CE = Container Engine) shown. According to step S1 in Fig. 1, indicated by an arrow, the configuration information CO is passed along with the boundary information QI to the orchestrator OR, which passes the boundary information QI along with a unique identifier for the container instances CIN1 and CIN2 to be configured to a configuration component AQC, as illustrated by step S2, indicated by an arrow. The unique identifier for the respective container instance can be composed of the name of the application and the container. For example, if the well-known orchestrator Kubernetes is used, the unique identifier can be formed from a combination of namespace, pod name, and container name.

[0032] In an alternative embodiment, the orchestrator OR can also be omitted, in which case the container runtime environment CE is predefined for executing the application AP. Without an orchestrator, the configuration information CO, along with the boundary information QI, is passed directly to the container runtime environment CE (step S1'), which then passes the boundary information QI, along with a unique identifier of the container instances CIN1 and CIN2 to be configured, to the component AQC (step S2').

[0033] As mentioned above, the limitation information QI contains a memory limit for each of the existing container-specific users UC1 and UC2. In the embodiment described here, the memory limits are defined based on maximum memory sizes for container-specific directories of the respective users, wherein the container-specific directories are each linked to the persistent storage of a corresponding storage partition in the memory ST. Thus, for the user UC1, there exist one or more directories specific to the container instance CIN1, which are assigned to a storage partition of the operating system OS. Similarly, for the container-specific user UC2, there exist one or more directories specific to the container instance CIN2, which are assigned to a storage partition of the operating system OS.In other words, the limit information QI defines which target containers with corresponding users should have persistent directories mounted from which source directories of the storage partition into which container directories. As mentioned, in the implementation described here, the storage limits for the container-specific users specify a maximum storage size; however, the storage limit can also be defined in other ways, e.g., based on the maximum number of files that can be written to the corresponding storage partition.

[0034] In the previous section, the memory limit for users of individual container instances was defined based on container directories, each of which is assigned a limited amount of persistent storage on a storage partition of the operating system (OS). If necessary, the memory limit can also be defined by directly specifying the operating system storage partition to be limited for each container instance.

[0035] In the embodiment described here, after receiving the limitation information QI, the AQC component first checks whether the corresponding memory limits in the limitation information QI are actually permissible according to certain admissibility criteria. One admissibility criterion is that all container-specific directories must be the same size in the memory limits of the container-specific users, provided the directories belong to the same memory-limited storage partition. Thus, memory limits are not permissible for container-specific directories whose memory sizes are specified for different storage sizes if the directories are mounted on the same storage partition of the operating system OS.

[0036] If certain memory limits are deemed to be inadmissible, these inadmissible memory limits are not implemented in the embodiment described here. Alternatively, it is also possible for the inadmissible memory limits to be adjusted in such a way that they become permissible again. For example, if for two memory limits the corresponding container-specific directories that are assigned to the same memory partition of the operating system have different maximum memory values, all directories can be set to the same memory value, for example the largest memory value of all directories, whereby the corresponding memory limits become permissible again. In a further variant, it is also possible for the process to be aborted in the event of inadmissible memory limits. This means that no container instances are started and the application is not executed.

[0037] After performing the admissibility check described above, the AQC component now sets up the memory limits according to the limit information QI with reference to the operating system OS. In doing so, a common user namespace is set up for the container instances CIN1 and CIN2, whose users 0C1 and 0C2 are to be subject to a corresponding memory limit. User namespaces represent a mechanism known per se from the Linux operating system. A user namespace describes a unique mapping of container-specific users to corresponding users with user identities in the Linux operating system. According to the invention, the mapping is selected such that the user identities in the Linux operating system OS are not otherwise assigned to processes of the operating system. The creation of the user namespace is indicated in Fig. 1 in step S3.According to this step, a user mapping UAS is defined in the form of a user namespace in which the container-specific user UC1 is mapped to the operating system user UOS1 and the container-specific user UC2 is mapped to the operating system user UOS2.

[0038] With the help of the user namespace, the container-specific users of a container instance are shifted by an offset. This means, for example, that write operations with the container-specific user identity 0 within a user namespace on the underlying operating system are performed with the user identity of the offset. The offset is appropriately specified by the AQC component when the user namespace is created. For this purpose, the AQC component uses the boundary information QI passed by the orchestrator OR in step S2 or by the runtime environment CE in step S2'. The interaction between the runtime environment or the orchestrator and the AQC component can occur, for example, with the help of plugins. The above offset is determined by the AQC component evaluating the container-specific user identities and using this to calculate how large the distance to the next user namespace must be.In a modified version, user groups can also be defined for individual container-specific users, meaning that each user is assigned to a user group. A corresponding memory limit is defined uniformly for a user group, which then applies to all container-specific users in the user group, thus simplifying the process.

[0039] In a next step S4, the user namespace or the user assignment UAS, which was determined in step S3 by the component AQC, is passed to the runtime environment CI, which then implements the corresponding memory limits according to the limit information QI using the user namespace. The memory limits are not assigned based on the container-specific users UC1, UC2 within the user namespace and thus in the container, but rather based on the actual users or user identities UOS1, UOS2 of the underlying operating system OS. For example, with an offset in the user namespace of 2000 for the container-specific user with the user identity 0, a memory limit is assigned to the user identity 2000 of the operating system OS and not to the user identity 0.

[0040] As part of the implementation of the user namespace, the container-specific file systems are mounted or included using the user namespace. The container instances CIN1 and CIN2 are then started, as indicated by two dashed arrows in Fig. 1. The corresponding memory limits in the operating system OS are implemented using the user namespace. In other words, write operations of the corresponding container instances CIN1 and CIN2, which are indicated in Fig. 1 by double arrows between the instances and the operating system OS, are limited according to the memory limits in the limit information, i.e. it is ensured that the persistent memory on the corresponding memory partition of the physical memory ST is not written to beyond the memory limit by the container-specific users, who in turn are assigned to operating system users.Write operations that exceed a memory limit are therefore not permitted for the respective user in the container instance.

[0041] In a variant of the procedure just described, the user assignment or the user namespace UAS is saved so that it is available again if the application AP or the corresponding container instances CIN1 and CIN2 is restarted. Alternatively, it is also possible for the user assignment or the user namespace UAS to be recalculated each time the application AP is restarted so that the assignment is adjusted dynamically and any changes in the operating system OS are taken into account appropriately. When the user namespace is reused or recalculated, it is ensured that the offset shift with the user namespace is reversed when the corresponding application is stopped, so that the user namespace is correctly defined again when the application is restarted.

[0042] The embodiments of the invention described above have a number of advantages. In particular, it is possible to suitably limit the amount of available persistent memory for container-specific users of container instances. This prevents a container instance that is started, for example, by an attacker as part of a DoS attack (DoS = Denial of Service), from completely writing out a physical memory, so that other container instances that access the same physical memory are prevented from executing their operations. In a preferred variant, a mechanism known per se is used to implement the corresponding memory limitations in the form of a user namespace of the Linux operating system. The user namespace can, if necessary, be dynamically updated each time the application is restarted.the corresponding container instances. If necessary, a determined user namespace can also be saved for reuse when the application or the associated container instances are restarted.

Claims

Patent claims 1. A computer-implemented method for computer-aided restriction of persistent memory for a container-based application (AP), wherein the application (AP) is assigned a number of container instances (CIN1, CIN2), which are configured and subsequently started to execute the application (AP) on a predetermined operating system (OS) Linux, wherein the number of container instances (CIN1, CIN2) includes a number of first users (UC1, UC2), with each of which at least one process in the number of container instances (CIN1, CIN2) is executed after their start, wherein a respective first user (UC1, UC2) is a container-specific user in a corresponding container instance (CIN1, CIN2), wherein: for configuring the number of container instances (CIN1, CIN2) configuration information (CO) is provided which defines a memory limit of persistent memory on at least one memory partition of the predetermined operating system (OS) for each first user (UC1, UC2);when configuring the number of container instances (CIN1, CIN2), a user assignment (UAS) is specified, according to which each first user (UC1, UC2) is assigned a different second user (UOS1, UOS2), which is unique across the number of container instances (CIN1, CIN2) and for which the memory limitation of the respective first user (UC1, UC2) is valid, wherein the respective second user (UOS1, UOS2) is a user in the specified operating system (OS) that was not used in the specified operating system (OS) before being assigned to the first user (UC1, UC2), and the user assignment is specified based on a Linux user namespace (UAS), the number of container instances (CIN1, CIN2) are started based on the user assignment (UAS), wherein with the help of the second user(s) (UOS1, UOS2) in the; Linux Usernamespace (UAS) the memory limit for each first user (UC1, UC2) is respected.

2. Method according to claim 1, characterized in that in the configuration information (CO) at least a part of the first users (UC1, UC1) of the number of first users (UC1, UC2) is assigned to one or more user groups, each user group being assigned the same memory limit for all first users (UC1, UC2) contained therein.

3. Method according to claim 1 or 2, characterized in that in the configuration information (CO) the memory limit for a respective first user (UC1, UC2) of the number of first users (UC1, UC2) for one or more directories of a container-specific file system is defined, wherein in the configuration information (CO) the at least one memory partition of the predetermined operating system (OS) is further specified which corresponds to the directory or directories of the container-specific file system.

4. Method according to one of the preceding claims, characterized in that the configuration information (CO) is a provided standard configuration information if no other configuration information is provided for the application (AP).

5. Method according to one of the preceding claims, characterized in that when determining the user assignment (UAS) it is checked whether the memory limit is permissible for a respective first user (UC1, UC2) of the number of first users (UC1, UC2), wherein, if one or more inadmissible memory limits are present, the inadmissible memory limits are discarded or replaced by permissible memory limits or the method is aborted.

6. Method according to one of the preceding claims, characterized in that the user assignment (UAS) which is determined during the configuration of the number of container instances (CIN1, CIN2) is stored beyond the termination of the method.

7. Computer program product with a program code stored on a machine-readable carrier for carrying out a method according to one of the preceding claims when the program code is executed on a computer.

8. Computer program with a program code for carrying out a method according to one of claims 1 to 6 when the program code is executed on a computer.

Images