WO2021107759A1

WO2021107759A1 - System and method for managing access to container volume

Info

Publication number: WO2021107759A1
Application number: PCT/MY2020/050116
Authority: WO
Inventors: Rajendar KANDAN; Sharipah Setapa; Mohammad Fairus Khalid; Hong Hoe ONG
Original assignee: Mimos Berhad
Priority date: 2019-11-29
Filing date: 2020-10-21
Publication date: 2021-06-03

Abstract

The present invention discloses a system and a method for managing access to a container volume that mounts data accessible by a plurality of containers residing in a host machine. The invention provides a comprehensive orchestration of the volume to avoid risk of data manipulation and unconditional exposure as well as authorization with minimum interference to load balancing. The system comprises a persistent volume module (100), a mount path module (101), a path transformation module (102), a path consistency module (103), a volume detection module (104) and a volume validator module (105).

Description

SYSTEM AND METHOD FOR MANAGING ACCESS TO CONTAINER VOLUME

FIELD OF THE INVENTION

The present invention relates generally to container volumes. More particularly, the present invention relates to an improved system and method for managing access to a container volume that mounts data accessible by a plurality of containers residing in a host machine.

BACKGROUND OF THE INVENTION

Volumes are the preferred mechanisms for persisting data that is generated by and used by Docker containers. Docker adopts volumes for containers to store files in a host machine so that the files are persisted even after the container stops. A volume does not increase the size of the container and it exists outside of the container. When a volume is created, it is stored within a directory on the host machine. When the volume is mounted into a container, the directory is what is mounted into the container. The volume also allows data sharing among multiple running containers. Multiple containers can mount the same volume simultaneously, either read-write or read only. One problem that may arise from this is the risk of data manipulation that can affect running applications due to concurrent access to the volume and data by different containers. Another problem is the sizable unconditional exposure of the volume.

By way of background, United States Patent Publication No. 2017/0126506 A1 (hereinafter “the ‘506 publication”) discloses a system that has host machines forming a cluster. Each host machine runs containers, where each container includes a segment of hardware resources associated with the host machine, a segment of an operating system utilized by the host machine, and at least one application. According to the ‘506 publication, host agents operate on the host machines. Each host agent collects operational parameters associated with the containers on each host machine. A management platform is operative to divide the cluster into container pools, where each container pool includes a sub-set of computation resources in the cluster and has associated container pool metrics including a priority level and computation resource limits. Operational parameters are collected from the host agents. The operational parameters are evaluated in accordance with the container pool metrics.

It would therefore be advantageous to provide a solution that would overcome the deficiencies of the prior art by providing an improved system and method for managing access to the volume that provides comprehensive orchestration of the volume and authorization with minimum interference to load balancing. Although there are systems and methods for the same in the prior art, for many practical purposes, there is still considerable room for improvement.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

Accordingly, the present invention provides a system for managing access to a container volume that mounts data accessible by a plurality of containers residing in a host machine.

The system of the present invention may be characterized by a persistent volume module configured for conducting validation on the container volume being requested for access against a database of the host machine, wherein the validation is performed over a volume name and a classification policy associated with a data category and a security level of the data in the container volume thereof; a mount path module configured for identifying a mount path at which the container volume mounts, wherein the mount path indicates a data path classification defining access restriction to the container volume thereof; a path transformation module configured for determining a role associated with the mount path and assigning a corresponding classification policy to the role based on the data path classification, wherein the path transformation module disables the mount path upon detection of any invalid path between the host machine and the container volume; a path consistency module configured for verifying the role against the data of the container volume; a volume detection module configured for monitoring and recording data and activity relating to the container volume thereof, wherein the volume detection module identifies a running container accessing the container volume, read activity and write activity performed on the container volume; and a volume validator module configured for providing a decision to grant or decline the access to the container volume based on the classification policy, the data path classification and the role retrieved thereof.

Preferably, the volume detection module establishes a container volume ranking to identify a rank position of the container volume in respect to other container volumes.

Preferably, the volume detection module detects addition and removal of containers from the container volume and updates the database thereof.

Preferably, the database of the host machine includes a record of the volume validator module.

Preferably, the persistent volume module is communicatively connected to the volume validator module.

Preferably, the persistent volume module inspects a corresponding sharing volume data residing in a neighboring container to determine the security level of the data.

In accordance with another aspect, the present invention provides a method for managing access to a container volume that mounts data accessible by a plurality of containers residing in a host machine.

The method of the present invention may be characterized by conducting validation on the container volume being requested for access against a database of the host machine, wherein the validation is performed over a volume name and a classification policy associated with a data category and a security level of the data in the container volume thereof; identifying a mount path at which the container volume mounts, wherein the mount path indicates a data path classification defining access restriction to the container volume thereof; determining a role associated with the mount path and assigning a corresponding classification policy to the role based on the data path classification, wherein the step of determining includes disabling the mount path upon detection of any invalid path between the host machine and the container volume; verifying the role identified thereof against the data of the container volume; monitoring and recording data and activity relating to the container volume thereof, wherein the step of monitoring and recording includes identifying an active container accessing the container volume, read activity and write activity performed on the container volume; and providing a decision to grant or decline the access to the container volume based on the classification policy, the data path classification and the role retrieved thereof.

The foregoing and other objects, features, aspects and advantages of the present invention will become better understood from a careful reading of a detailed description provided herein below with appropriate reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the invention and many of the attendant advantages thereof will be readily as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

Figure 1 illustrates a system for managing access to a container volume that mounts data accessible by a plurality of containers residing in a host machine according to one embodiment of the present invention;

Figure 2 is a flow diagram of a method for managing access to a container volume that mounts data accessible by a plurality of containers residing in a host machine according to one embodiment of the present invention;

Figure 3 is a flow diagram depicting an overall flow for registering a container volume to the system illustrated in Figure 2 according to one embodiment of the present invention; Figure 4 is a flow diagram showing the steps involved for establishing behavior of container volume according to one embodiment of the present invention;

Figure 5 is a flow diagram showing the steps involved for classifying data type and classification policy according to one embodiment of the present invention;

Figure 6 is a flow diagram showing the steps involved for providing a role relation with a mount path according to one embodiment of the present invention; and

Figure 7 is a flow diagram showing the steps involved for exploring a detection and alert according to one embodiment of the present invention.

It is noted that the drawings may not be to scale. The drawings are intended to depict only typical aspects of the invention, and therefore should not be considered as limiting the scope of the invention. In the drawings, like numberings represent like elements between the drawings.

DETAILED DESCRIPTION OF THE INVENTION

Essentially, the present invention discloses a system and a method for managing access to a container volume that mounts data accessible by a plurality of containers residing in a host machine. The present invention provides a comprehensive orchestration of the container volume and authorization with a minimum interference to load balancing. More specifically, the present invention proposes to categorize creation of container volume, initialize policy-based authorization for each volume created, analyze data accessibility path, match with role of data with mount path, create alert for volume data detection, monitor data consistency and transform path into disable when an invalid path between the host machine and the container volume is detected.

According to one embodiment of the present invention, the system comprises a persistent volume module 100, a mount path module 101 , a path transformation module 102, a path consistency module 103, a volume detection module 104 and a volume validator module 105, as schematically shown in Figure 1 and the enabling method for the same is provided in Figure 2.

The persistent volume module 100 of the present invention is employed for conducting validation on the container volume being requested for access. The container volume is validated or compared against a database of the host machine. Preferably, the database of the host machine includes a record or another database thatis attached to the volume validator module 105. It is preferred that the validation is performed over a volume name and a classification policy associated with a data category and a security level of the data in the container volume thereof. The persistent volume module 100 preferably inspects a corresponding sharing volume data residing in a neighboring container to determine the security level of the data. It is preferred that the persistent volume module 100 is communicatively connected to the volume validator module 105. An example of data in volume classification is provided below.

Table 1 : Data Type Categorization for Organization

Note: Security level is related to mount path with policy (level of mount).

According to Table 1 , each example data will be assigned to its data category. The format for classification policy will be developed for each data, where security level is identified. The mount location of data usage will be monitored and verified accordingly. The mount path module 101 can be configured for identifying a mount path at which the container volume mounts. It is preferred that the mount path indicates a data path classification defining access restriction to the container volume thereof. The data path classification is preferably derived from the level of mount determined thereof. In one embodiment, the data path classification comprises “restricted”, “confidential (internal use)” and “public”. An example of level of mount and data path classification is provided below.

Table 2: Level of Mount and Data Path Classification

The mount path will be assigned based on the data path classification thereof.

The path transformation module 102 is configured for determining a role associated with the mount path. The path transformation module 102 checks the role every time a mount path is created. The following table provides an example of types of user and roles associated thereof. If the role to the path is designated for a specific user, then assigns a corresponding classification policy to the same and identifies as a specific user (read). The path transformation module 102 will also apply appropriate policy and security such as private access control of volume.

Table 3: Type and Role

No explanation about table 3.

As mentioned above, the path transformation module 102 is also adapted for assigning a corresponding classification policy to the role based on the data path classification. It is preferred that the path transformation module 102 disables the mount path upon detection of any invalid path between the host machine and the container volume.

The path consistency module 103 is configured for verifying the role against the data of the container volume.

The volume detection module 104 is employed for monitoring and recording data and activity relating to the container volume thereof. It is preferred that the volume detection module 104 identifies a running or active container accessing the container volume, read activity and write activity performed on the container volume. Each container can be detected whether the container runs or stops based on a specific command. Each container is preferably monitored against the role on the data of the volume thereof. Volume accessibility and ownership of the volume can be verified during a change in a state of the container, e.g. whether it is stopped or shut down. Prediction of characteristics of the container is preferably evaluated based on a historical action and the prediction will be transmitted as an alert to the user.

In one embodiment, the volume detection module 104 is adapted to establish a container volume ranking. The container volume ranking is preferably employed for identifying a rank position of the container volume in respect to other container volumes in the host machine. An example of the container volume ranking is provided below.

Table 4: Container Volume Ranking

Table 4 describes the sample possible volume action monitor and ranking system. It is suggested by the present invention that write activity is graded higher and more than the read activity. The rank position is established based on the number of write activity and read activity.

Further, the volume detection module 104 can be used to detect addition and removal of containers from the container volume and updates the database thereof.

The volume validator module 105 is configured for providing a decision to grant or decline the access to the container volume based on the classification policy, the data path classification and the role retrieved thereof.

The method of the present invention is preferably summarized by Figure 2. In summary, based from the preceding paragraphs, the method begins with the step S200 of conducting validation on the container volume being requested for access against a database of the host machine. The validation in S200 is performed over the volume name and the classification policy associated with the data category and the security level of the data in the container volume thereof. Subsequently, the step S201 pertaining to identifying a mount path at which the container volume mounts will be initiated. The mount path, as mentioned, indicates the data path classification that defines access restriction to the container volume. In the following step S202, the method initiates the step of determining the role associated with the mount path and assigning the corresponding classification policy to the role based on the data path classification thereof. It is preferred that the step S202 includes disabling the mount path upon detection of any invalid path between the host machine and the container volume. The role identified thereof will be verified against the data of the container volume in step S203. Following that, the step of monitoring and recording data and activity relating to the container volume will be initiated (see S204). The step S204 preferably includes identifying an active container accessing the container volume, read activity and write activity performed on the container volume. The method finally will provide a decision to grant or decline the access to the container volume based on the classification policy, the data path classification and the role retrieved thereof, as outlined in step S205. The present invention will be specifically described by the following examples, but it should be understood that the invention is not limited in any way to these examples.

Example 1

Figure 3 is a flow diagram depicting an overall flow for registering a container volume to the system. The overall flow begins with establishment of behavior of container volume where it includes listing out the volume and scanning path of the volume (S300). In the subsequent step of S301 , the data type and policy level will be classified for each data. A format for classification policy will be developed at this step.

Following that, a role relation with a mount path will be provided (S302). If the mount path is mounted or a folder is created, then, assigns a specific role with regards to the said mount path. In the final step of S303, a detection and alert will be explored. At this step, a detection of modification or change pertaining to the container volume will be obtained and ranked accordingly. The user will be alerted if any modification is detected and triggered as contaminated if the data is viewed by other users.

Example 2

Figure 4 is a flow diagram showing the steps involved for establishing behavior of container volume. Creation of characteristics for the volume and the container is the first step (S400) in the flow diagram. The behavior of the volume will be obtained when a same data is attached to a different container (S401). Subsequently in step S402, the behavior and characteristics obtained thereof will be subject to the same shell bash but in a different container. The identification or ID of the container will be checked to identify other containers compared with the volume (S403). Upon detection of similarity between the volumes in step S404, the same will be consolidated and migrated to a different container. The container’s ID will be verified to confirm that same data will be utilized in the different container (S405). Example 3

Figure 5 is a flow diagram showing the steps involved for classifying data type and classification policy. Firstly, in step S500, data type will be categorized based on a specification level. A checking on the security level is subsequently conducted in step S501. If the data is accessed by various type of containers, then, a security level is required (S502). In this regard, a format for classification policy will be developed. Security level of the said data will be identified and classified appropriately in step S503 before being embedded with a role to reflect with the security level of the data in step S504. If no security level is required, then a verification as to whether the data needs to be isolated from the neighboring container will be conducted (S505). Upon verification, in step S506, the user will be limited to a security level “internal use”, i.e. confidential, if the data is prepared for internal only.

Example 4

Figure 6 is a flow diagram showing the steps involved for providing a role relation with a mount path. When creating a mount path, in a preliminary identification (S600), the role associated thereto will be checked. If the mount path is mounted or the folder is created, then, assigns a specific role with regards to the said mount path. The mount path is only eligible for the specific role unless the role is appended to other type of mount path (e.g. multiple paths for one role).

In step S601 , data type for the data will be categorized as data category “sensitive”, “private” and “public”. Then, a format for classification policy will be developed for each data (S602). A security level of the data will be determined and classified appropriately in step S603. A mount location will next be discovered and verified, in step S604, repetitively through detection of curiosity, especially, after the first time mounting to a specific container. Finally, in step S605, the detection can be made in a predefined period of time and afterwards, changing the level of mount period. Example 5

Figure 7 is a flow diagram showing the steps involved for exploring a detection and alert. A potential model reasoning, particularly, data volume behavior reasoning will be established in step S700. The potential model reasoning is preferably prepared for both remove container and non-remove container. Next, in step S701 , active and non-active container will be linked with the data in the volume. Each link has a tag or linkage for any possibility or the volume will be unauthorized by a container which runs previously.

Following on that, all potential possible actions of the data will be listed out and updated (e.g. viewed, non-viewed or modified) as outlined in step S702. These actions will be used to predict possible risk of data manipulation in the following step S703. A checking will be made whether a prediction is necessary (S704). If a prediction is made, then the predictions resulting therefrom will be arranged in an order from high to low (S705). Then, in the same step S705, based on the order, a ranking will be established. The role will be used to predict for future for raising an alert (S706). If no prediction is made, then it will go back to the potential model reasoning (S707). The model will be updated if different unconditional exposure or action is detected.

Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.

Although an overview of the inventive subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of embodiments of the present disclosure. Such embodiments of the inventive subject matter may be referred to herein, individually or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single disclosure or inventive concept if more than one is, in fact, disclosed.

The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present disclosure as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

The foregoing description, for the purpose of explanation, has been described with reference to specific example embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the possible example embodiments to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The example embodiments were chosen and described in order to best explain the principles involved and their practical applications, to thereby enable others skilled in the art to best utilize the various example embodiments with various modifications as are suited to the particular use contemplated.

It will also be understood that, although the terms “first,” “second,” and so forth may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, without departing from the scope of the present example embodiments. The first contact and the second contact are both contacts, but they are not the same contact.

The terminology used in the description of the example embodiments herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used in the description of the example embodiments and the appended examples, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” may be construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event],” depending on the context.

Claims

1. A system for managing access to a container volume that mounts data accessible by a plurality of containers residing in a host machine, characterized in that, the system comprising: a persistent volume module (100) configured for conducting validation on the container volume being requested for access against a database of the host machine, wherein the validation is performed over a volume name and a classification policy associated with a data category and a security level of the data in the container volume thereof; a mount path module (101) configured for identifying a mount path at which the container volume mounts, wherein the mount path indicates a data path classification defining access restriction to the container volume thereof; a path transformation module (102) configured for determining a role associated with the mount path and assigning a corresponding classification policy to the role based on the data path classification, wherein the path transformation module disables the mount path upon detection of any invalid path between the host machine and the container volume; a path consistency module (103) configured for verifying the role against the data of the container volume; a volume detection module (104) configured for monitoring and recording data and activity relating to the container volume thereof, wherein the volume detection module identifies a running container accessing the container volume, read activity and write activity performed on the container volume; and a volume validator module (105) configured for providing a decision to grant or decline the access to the container volume based on the classification policy, the data path classification and the role retrieved thereof.

2. The system according to Claim 1 , wherein the volume detection module (104) establishes a container volume ranking to identify a rank position of the container volume in respect to other container volumes.

3. The system according to Claim 1 , wherein the volume detection module (104) detects addition and removal of containers from the container volume and updates the database thereof.

4. The system according to Claim 1 , wherein the database of the host machine includes a record of the volume validator module (105).

5. The system according to Claim 1 , wherein the persistent volume module (100) is communicatively connected to the volume validator module (105).

6. The system according to Claim 1 , wherein the persistent volume module (100) inspects a corresponding sharing volume data residing in a neighboring container to determine the security level of the data.

7. A method for managing access to a container volume that mounts data accessible by a plurality of containers residing in a host machine, characterized in that, the method comprising the steps of: conducting validation on the container volume being requested for access against a database of the host machine (S200), wherein the validation is performed over a volume name and a classification policy associated with a data category and a security level of the data in the container volume thereof; identifying a mount path at which the container volume mounts (S201), wherein the mount path indicates a data path classification defining access restriction to the container volume thereof; determining a role associated with the mount path and assigning a corresponding classification policy to the role based on the data path classification (S202), wherein the step of determining includes disabling the mount path upon detection of any invalid path between the host machine and the container volume; verifying the role identified thereof against the data of the container volume (S203); monitoring and recording data and activity relating to the container volume thereof (S204), wherein the step of monitoring and recording includes identifying an active container accessing the container volume, read activity and write activity performed on the container volume; and providing a decision to grant or decline the access to the container volume based on the classification policy, the data path classification and the role retrieved thereof (S205).