Access Control Method and Electronic Device

Abstract

The present application discloses an access control method and an electronic device. The present application pre-stores the target metadata of the remote storage device to be accessed by a first container running on a virtual machine in the physical machine of the electronic device. On this basis, in response to a start request instructing to start the first container, the target metadata pre-stored in the physical machine of the electronic device is obtained, and according to the obtained target metadata, the remote storage device to be accessed by the first container is mounted to the virtual machine corresponding to the first container, so that the virtual machine corresponding to the first container obtains the mounting information of the remote storage device. Thereby, the application in the first container running on the virtual machine can directly access the remote storage device in a direct pass-through manner based on the mounting information of the remote storage device in the virtual machine, avoiding cross-physical machine access.

Description

Technical Field

[0001] This application belongs to the technical field of storage access, and particularly relates to an access control method and an electronic device. Background Art

[0002] When a secure container in the current container management tool kubernetes accesses a remote storage device with a virtual kernel (virtual guest kernel) as a sandbox, it is necessary to first mount the remote storage device to the physical machine where kubernetes is located through the semantics of PV (Persistent Volume) and PVC (Persistent Volume Claim). The host kernel device driver on the physical machine first takes over the control, and then further maps the local device to the virtual kernel through a device simulator. Finally, the device driver in the virtual kernel takes over the control and provides it for the application in the container to access.

[0003] Since the remote storage device needs to be controlled by the above two layers of device drivers and pass through the simulation layer, the application in the secure container needs to access the remote storage device across physical machines, resulting in a relatively high performance loss in the existing access mode of the secure container to the remote storage device. Summary of the Invention

[0004] For this reason, the present application discloses the following technical solutions:

[0005] An access control method, applied to a container management tool, includes:

[0006] Obtaining a startup request for starting a first container on an electronic device; the first container is a container running on a virtual machine;

[0007] Obtaining target metadata of a physical machine of the electronic device stored in advance, where the target metadata is metadata of a remote storage device to be accessed by the first container;

[0008] According to the target metadata, mounting the remote storage device to the virtual machine corresponding to the first container to obtain mounting information of the remote storage device in the virtual machine; the mounting information in the virtual machine can be used to enable an application in the first container to access the remote storage device in a direct pass-through manner in the virtual machine;

[0009] Starting the first container to enable the application in the first container to access the remote storage device.

[0010] Optionally, the process of storing the target metadata in the physical machine of the electronic device in advance includes:

[0011] Create a storage volume claim on the physical machine, where the storage volume claim includes the applied storage capacity;

[0012] On the physical machine, transmit the claim information of the storage volume claim to the remote storage server through the remote storage interface, so that the remote storage server creates a matching remote storage device according to the received claim information and generates corresponding metadata for the created remote storage device;

[0013] Obtain the metadata fed back by the remote storage server and store the metadata as the target metadata on the physical machine.

[0014] Optionally, the storage volume claim is a claim in the form of a local file; the target metadata includes the device identifier, device address, and access password of the remote storage device; the target metadata is stored in the claim file of the storage volume claim in the physical machine;

[0015] Among them, through the container storage interface plug-in integrated into the container management tool, a storage volume claim is created on the physical machine of the electronic device in advance, and the target metadata is stored in the claim file of the storage volume claim.

[0016] Optionally, the application in the first container accesses the remote storage device in a direct pass-through manner, including:

[0017] The application in the first container uses the mounting information to directly access the remote storage device through the access password;

[0018] Among them, during the process of the application in the first container accessing the remote storage device, the remote storage device is in a locked state to prevent other access ends from accessing the remote storage device.

[0019] Optionally, obtaining the target metadata pre-stored on the physical machine includes:

[0020] Create a virtual machine in a runtime manner, and use the application proxy of the container to obtain the target metadata stored on the physical machine based on the created virtual machine;

[0021] Mounting the remote storage device to the virtual machine corresponding to the first container according to the target metadata includes:

[0022] Use the application proxy to mount the remote storage device to the virtual machine according to the target metadata.

[0023] Optionally, the target metadata pre-stored on the physical machine is the encrypted result data obtained by encrypting the target metadata with a predetermined public key;

[0024] Obtaining the target metadata of the physical machine pre-stored in the electronic device includes:

[0025] Obtaining a private key that matches the public key;

[0026] Obtaining the encrypted result data from the physical machine and decrypting the encrypted result data with the private key to obtain the target metadata.

[0027] Optionally, the method further includes:

[0028] Obtaining a shutdown request for shutting down the first container, shutting down the first container, and releasing the mount of the remote storage device indicated by the target metadata;

[0029] Or, obtaining a destruction request for destroying the first container, destroying the first container, releasing the mount of the remote storage device indicated by the target metadata, and sending the destruction request to the remote storage server so that the remote storage server releases the storage space of the remote storage device according to the destruction request.

[0030] Optionally, the method further includes:

[0031] Obtaining a start request for starting a second container; the second container is a container for running on the physical machine, and the security of the second container is lower than the security of the first container;

[0032] Obtaining the target metadata pre-stored in the physical machine;

[0033] Mounting the remote storage device to be accessed to the physical machine according to the target metadata to obtain the mount information of the remote storage device on the physical machine;

[0034] Starting the second container so that the application in the second container accesses the remote storage device.

[0035] Optionally, the first container or the second container integrates a first protocol stack and a second protocol stack for accessing the remote storage device;

[0036] The first container or the second container accesses the remote storage device through any one of the first protocol stack and the second protocol stack.

[0037] An electronic device includes:

[0038] A memory for storing at least one set of instruction sets;

[0039] A processor for calling and executing the instruction set in the memory, and implementing the access control method as described in any one of the above through executing the instruction set.

[0040] As can be seen from the above solutions, for the access control method and the electronic device disclosed in this application, the target metadata of the remote storage device to be accessed by the first container running in the virtual machine is stored in advance in the physical machine of the electronic device. On this basis, in response to a startup request indicating to start the first container, the target metadata stored in advance in the physical machine of the electronic device is obtained, and according to the obtained target metadata, the remote storage device to be accessed by the first container is mounted to the virtual machine corresponding to the first container, so that the virtual machine corresponding to the first container obtains the mounting information of the remote storage device. Thus, the application in the first container running in the virtual machine can directly access the remote storage device in a direct pass-through manner based on the mounting information of the remote storage device in the virtual machine, avoiding cross-physical machine access. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0042] Figure 1 is a schematic flowchart of an access control method provided by the present application;

[0043] Figure 2 is a schematic diagram of an access mechanism for remote storage access based on a container provided by the present application;

[0044] Figure 3 is another schematic flowchart of an access control method provided by the present application;

[0045] Figure 4 is yet another schematic flowchart of an access control method provided by the present application;

[0046] Figure 5 is a flowchart of remote storage access control in an application example provided by the present application;

[0047] Figure 6 is a block diagram of the composition of an electronic device provided by the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0048] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts belong to the scope of protection of the present application.

[0049] Embodiments of the present application disclose an access control method and an electronic device, which are used to solve at least the technical problems existing in the existing access mode for accessing a remote storage device based on a secure container. This access control method can be used for devices in many general or specific computing device environments or configurations, such as: personal computers, server computers, handheld devices or portable devices, tablet devices, multi-processor devices, and so on.

[0050] Specifically, the access control method of the embodiments of the present application can be applied to container management tools on any of the above types of devices, such as Kubernetes.

[0051] The processing process of the access control method disclosed in the embodiments of the present application is as Figure 1 shown, and at least includes:

[0052] Step 101, obtain a startup request for starting a first container on the electronic device.

[0053] Among them, the first container is a container running on a virtual machine and has an independent kernel.

[0054] Specifically, the first container can be a secure container with an independent kernel, using a virtual kernel (virtual guest kernel) as the container kernel.

[0055] When the user of the electronic device has a need to start the first container to access a remote storage device through an application in the first container, in one embodiment, the corresponding operation can be performed on the container management tool installed and running on the electronic device to trigger a startup request for the first container.

[0056] Exemplarily, the user can trigger a startup request for the secure container, that is, the first container, by operating the secure container startup control in Kubernetes installed and running on the physical machine of the electronic device, and the electronic device (such as the container management tool Kubernetes on the electronic device) correspondingly obtains a startup request for starting the first container.

[0057] In another embodiment, the container management tool can also be run as a service on a server side such as the cloud, and a lightweight front-end client that matches the container management tool on the server side is provided on the physical machine of the electronic device. When the user of the electronic device needs to start the first container, the start request for the first container is triggered by operating the first container start control on the client of the electronic device. In response to this request, the client synchronizes the service data of the container management tool from the server side such as the cloud to the local device physical machine, and based on the synchronized service data, the start of the first container is realized by executing the subsequent steps 102-104.

[0058] Step 102: Obtain the target metadata pre-stored in the physical machine of the electronic device, where the target metadata is the metadata of the remote storage device to be accessed by the first container.

[0059] In the embodiment of the present application, the target metadata of the remote storage device to be accessed by the first container is pre-stored in the physical machine of the electronic device. The target metadata stored on the physical machine of the electronic device at least includes the device identifier and device address of the remote storage device to be accessed by the first container.

[0060] Optionally, in other embodiments, in addition to including the device identifier and device address of the remote storage device to be accessed by the first container, the target metadata may further include the access password required to access the remote storage device.

[0061] Among them, the process of pre-storing the target metadata in the physical machine of the electronic device can be realized as:

[0062] 11) Create a storage volume claim on the physical machine of the electronic device, and the storage volume claim includes the applied storage capacity.

[0063] Specifically, the existing protocol specifications of container management tools such as kubernetes limit that in the remote storage access scenario, the remote storage device needs to be mounted on the physical machine through PV and PVC semantics. This specification correspondingly restricts that the remote storage device needs to go through two layers of device driver control and a simulation layer to realize the mapping to the secure container virtual kernel, resulting in the application in the secure container needing to access the remote storage device across the physical machine.

[0064] In contrast, embodiments of the present application change the processing mode of existing protocol specifications of container management tools such as Kubernetes by providing a customized container storage interface (CSI). Based on this customized container storage interface, for the remote storage access scenario based on the first container (secure container), when the remote storage service pre-creates the remote storage device to be accessed by the first container, the present application obtains the metadata of the remote access device and saves it to the physical machine of the electronic device. That is, the present application does not mount the remote storage device to the physical machine of the electronic device, but only stores the metadata of the remote storage device on the physical machine, so as to avoid the first container / secure container running on the virtual machine from accessing the remote storage device by means of interaction with the physical machine (i.e., cross-physical machine). At the same time, it also supports that during the existence of the remote storage device on the remote storage service, when it is necessary to start the first container / secure container to access the remote storage device, the remote storage device can be mounted to the virtual machine corresponding to the first container in real time and conveniently based on the metadata of the remote storage device stored on the physical machine of the electronic device, so that the application in the first container can access the remote storage device in a direct pass-through manner.

[0065] Optionally, the customized container storage interface is implemented in the form of a plugin and is pre-integrated into the container management tool, such as Kubernetes.

[0066] In the process of storing the target metadata on the physical machine of the electronic device, first, a customized storage volume claim (customized pvc) is created through the customized container storage interface. Optionally, this embodiment follows the existing PV and PVC semantic framework specifications of Kubernetes and carries the created storage volume claim in the form of a local file. That is, the storage volume claim is a claim in the form of a local file.

[0067] 12) The physical machine of the electronic device transmits the claim information of the storage volume claim to the remote storage service through the remote storage interface, so that the remote storage service creates a matching remote storage device according to the received claim information and generates corresponding metadata for the created remote storage device.

[0068] After that, the physical machine of the electronic device calls the remote storage interface plugin to transmit the claim information of the storage volume claim to the remote storage service.

[0069] The remote storage service receives and responds to the storage volume claim of the electronic device, creates a storage volume with the storage capacity applied for in the claim as the remote storage device to be accessed by the electronic device, and at the same time, generates corresponding metadata such as device identification, device address, and access password for the created remote storage device and feeds it back to the electronic device.

[0070] The remote storage server can be a cloud or non-cloud distributed server that can be used to provide remote storage services, etc.

[0071] Preferably, the embodiment of the present application extends the container lifecycle management protocol algorithm. The container management tool implements a first protocol client and a second protocol client for supporting remote storage access, so that the first container and the second container involved later simultaneously support two protocol stacks of the first protocol and the second protocol, and have compatibility and performance advantages. However, it is easy to understand that in practical applications, it is not limited to this, and it is also possible to choose to support only any one of the two protocol stacks of the first protocol and the second protocol in the container management tool.

[0072] Correspondingly, the first container or the second container can access the remote storage device through any one of the first protocol stack and the second protocol stack.

[0073] Optionally, the first protocol is the iscsi (internet small computer system interface) protocol, and the second protocol is the nvme (non-volatile memory host controller interface specification) over fabrics protocol. Thus, the first container and the second container simultaneously support two protocol stacks of iscsi and nvme-of.

[0074] In response to the storage volume declaration initiated by the electronic device, the remote storage server can create an iscsi volume or an nvme volume as the remote storage device of the electronic device, and generate corresponding metadata information such as an iscsi iqn (iscsi qualified name), an nvme nqn (nvme qualified name), an access password, and a remote storage IP (Internet Protocol Address) for the created remote storage device. Among them, the remote storage IP of the remote storage device can be the IP of the physical device where the remote storage device is located, such as a cloud server.

[0075] 13) Obtain the above metadata fed back by the remote storage server, and store the metadata as the target metadata of the remote storage device to be accessed by the first container in the physical machine of the electronic device.

[0076] The physical machine of the electronic device receives the metadata (target metadata) of the remote storage device fed back by a remote storage server such as the cloud through a container storage interface plug-in, and writes it into the declaration file of the created storage volume claim, that is, the PVC file. That is to say, for the remote storage device created for the remote storage server, different from the prior art of mounting the remote storage device to the physical machine of the electronic device, the embodiment of the present application only stores the metadata of the remote storage device in the physical machine of the electronic device.

[0077] Further, optionally, the target metadata pre-stored in the physical machine of the electronic device is the encrypted result data obtained by encrypting the target metadata with a predetermined public key. That is, when storing the target metadata in the physical machine of the electronic device, the encrypted target metadata is specifically written into the pvc file locally defined on the physical machine of the electronic device.

[0078] On the basis of pre-storing the target metadata of the remote storage device to be accessed by the first container in the physical machine of the electronic device, when the electronic device obtains a start request indicating to start the first container, in response to this request, the target metadata pre-stored in the physical machine of the electronic device is obtained through step 102.

[0079] In one embodiment, in response to a start request indicating to start the first container, a virtual machine can be created by a container management tool such as kubernetes in a runtime manner, and the target metadata stored in the physical machine can be obtained by using the application agent of the container based on the created virtual machine. Specifically, the path of the PVC file in the physical machine can be configured for the application agent, and the agent obtains the target metadata according to the configured path information. The container runtime refers to a program that can create and run containers based on the images obtained online.

[0080] Among them, for the embodiment of writing encrypted target metadata into the PVC file, specifically, the application agent can obtain the private key matching the public key used during encryption, such as passing the private key through the pre-start hook of the container to implement the acquisition of the required private key by the agent. Then, the encrypted target metadata obtained from the PVC file of the physical machine is decrypted with the private key to obtain the decrypted available target metadata.

[0081] Step 103: Mount the above remote storage device to the virtual machine corresponding to the first container according to the target metadata, so as to obtain the mounting information of the above remote storage device in the virtual machine corresponding to the first container; the mounting information in the virtual machine can be used to enable the application in the first container to access the above remote storage device in a direct pass-through manner in the virtual machine.

[0082] After obtaining the target metadata of the remote storage device to be accessed by the first container, further mount the remote storage device indicated by the remote storage server at the remote storage service side to the virtual machine corresponding to the first container, that is, the virtual machine created by the container management tool in the above-mentioned runtime manner.

[0083] After the mounting is completed, the mounting information of the remote storage device to be accessed by the first container is obtained in the virtual machine corresponding to the first container. The mounting information specifically includes the storage directory of the remote storage device, which essentially maps the disk storage structure when the remote storage device provides storage services to the virtual machine corresponding to the first container in the electronic device, so as to provide the electronic device user with the remote access function to the remote storage device based on this disk storage structure.

[0084] Step 104: Start the first container so that the application in the first container can access the remote storage device.

[0085] After mounting the remote storage device to the virtual machine corresponding to the first container, further start the first container. After the startup is completed, the first container runs on the virtual machine of the electronic device.

[0086] In this application, instead of mounting the remote storage device to the physical machine of the electronic device, only the metadata of the remote storage device is stored on the physical machine, which effectively avoids the first container / secure container running on the virtual machine from accessing the remote storage device by means of interaction with the physical machine (i.e., across the physical machine). At the same time, it also supports that during the existence of the remote storage device at the remote storage service side, when it is necessary to start the first container / secure container to access the remote storage device, the remote storage device can be mounted to the virtual machine corresponding to the first container in real time and conveniently based on the metadata of the remote storage device stored on the physical machine of the electronic device, so that the application in the first container can access the remote storage device through the direct pass-through method. During the process of the first container running on the virtual machine of the electronic device, since the remote storage device is also mounted to this virtual machine, it supports the application in the first container to access the remote storage device through the direct pass-through method based on the mounting information (storage directory) of the remote storage device in the virtual machine, realizing the transparent access of the application in the first container to the remote storage device, that is, during the process of the application in the first container accessing the remote storage device, bypassing the physical machine of the electronic device is achieved. Referring to Figure 2 the entire access process can bypass the use of the physical machine.

[0087] Optionally, the application in the first container accesses the remote storage device in a direct pass-through manner through the access password in the target metadata. Specifically, during the life cycle of the first container, the target metadata retrieved by the agent from the physical machine of the electronic device is stored in the virtual machine corresponding to the first container, such as in the virtual machine memory. That is, during the life cycle of the first container, both the target metadata and the mounting information of the remote storage device are in the virtual machine. Correspondingly, the process of the application in the first container accessing the remote storage device through the access password in the target metadata does not need to interact with the physical machine, and can achieve a pass-through access to the remote storage device.

[0088] The application in the first container can be, but is not limited to, an HTTP (Hyper Text Transfer Protocol) service proxy, an in-memory database service, and so on.

[0089] Further, optionally, refer to Figure 2 , during the process of the application in the first container accessing the remote storage device, the remote storage device is in a locked state. For example, the remote storage server locks the remote storage device based on the access event of the application in the first container to the remote storage device using a mutex lock to make it in a locked state, etc., to achieve mutually exclusive single access and exclusive access of the application in the first container to the remote storage device, and to prevent other access ends from accessing the remote storage device during the access process.

[0090] From the above solution, it can be seen that the method of this embodiment pre-stores the target metadata of the remote storage device to be accessed by the first container running on the virtual machine in the physical machine of the electronic device. On this basis, in response to a startup request indicating to start the first container, the pre-stored target metadata in the physical machine of the electronic device is retrieved, and according to the retrieved target metadata, the remote storage device to be accessed by the first container is mounted to the virtual machine corresponding to the first container, so that the mounting information of the remote storage device is obtained in the virtual machine corresponding to the first container. Thereby, the application in the first container running on the virtual machine can directly access the remote storage device in a direct pass-through manner based on the mounting information of the remote storage device in the virtual machine, avoiding cross-physical machine access, reducing the intervention of the physical machine kernel layer, effectively improving the access efficiency of the application in the first container to the remote storage device, and reducing the performance loss caused by cross-physical machine access in the existing access mode, and improving the IO performance of the first container.

[0091] In addition, by providing mutually exclusive single access and key capabilities for the first container on the remote storage server in this embodiment, it is possible to further prevent multi-point mounting of the remote storage device on the server side, and solve the security problem of data leakage caused by multi-point mounting.

[0092] In one embodiment, refer to Figure 3The flowchart of the provided access control method. After step 104 of the access control method of this application, any one of the following processes may also be included:

[0093] Step 1051: Obtain a close request for closing the first container, close the first container, and release the mount of the remote storage device indicated by the target metadata.

[0094] Step 1052: Obtain a destruction request for destroying the first container, destroy the first container, release the mount of the remote storage device indicated by the target metadata, and send the destruction request to the remote storage server so that the remote storage server releases the storage space of the remote storage device according to the destruction request.

[0095] After completing the access to the remote storage device based on the first container, the user can close or destroy the first container according to needs. Specifically, according to actual needs, by performing corresponding operations, such as operating the security container close control or destruction control on the container management tool kubernetes, etc., a close request or destruction request for the first container can be triggered.

[0096] The container management tool executes the response processing matching the requested type.

[0097] Among them, in response to the close request for the first container, a close process for the first container is executed. The executed close process includes closing the first container on the electronic device and releasing the mount of the remote storage device indicated by the target metadata by the virtual machine. In this processing type, the remote storage device corresponding to the first container on the remote storage server still remains. Subsequently, access to the remote storage device can be realized by restarting the first container on the electronic device as needed.

[0098] In response to the destruction request for the first container, a destruction process for the first container is correspondingly executed. The executed destruction process includes destroying the first container on the electronic device and releasing the mount of the remote storage device indicated by the target metadata by the virtual machine. In addition, the destruction request is sent to the remote storage server. The destruction request includes the device identifier of the remote storage device (such as, iscsi iqn or nvme nqn), the device address, and the remote storage server releases the storage space of the remote storage device according to the destruction request.

[0099] In practical applications, when executing the close process or destruction process for the first container, the post-stop of the container can be used to obtain the target metadata decrypted when mounting the remote storage device, release the mount of the remote storage device based on the target metadata, and before closing / destroying the first container and releasing the mount, first close the access of the first container to the remote storage device.

[0100] This embodiment further provides a function for managing the shutdown and destruction of the container life cycle. After the user finishes accessing the remote storage device based on the first container, the user can trigger the shutdown or destruction process of the first container according to needs to shut down or destroy the first container.

[0101] In one embodiment, referring to Figure 4 the provided flowchart of the access control method, the access control method of this application may further include the following processes:

[0102] Step 401, obtain a startup request for starting the second container.

[0103] The second container is a container for running on a physical machine, and its security is lower than that of the first container. The second container may specifically be an ordinary container without an independent kernel, and when the second container runs, it shares the host kernel of the electronic device.

[0104] For the remote storage device, the user can choose to access the remote storage device based on the first container (secure container) or the second container (ordinary container) according to needs.

[0105] When the user of the electronic device has a need to start the second container for accessing the remote storage device based on the second container, in one implementation, the user can trigger the startup request for the second container by performing corresponding operations on the container management tool installed in the electronic device, such as operating the ordinary container startup control in kubernetes installed and running on the physical machine of the electronic device.

[0106] In another implementation, the container management tool can also be run as a service on a server such as the cloud, and a lightweight front-end client matching the container management tool of the server is provided on the physical machine of the electronic device. When the user of the electronic device needs to start the second container, the user triggers the startup request for the second container by operating the second container startup control on the electronic device client. In response to this request, the client synchronizes the service data of the container management tool from the server to the local device physical machine, and based on the synchronized service data, starts the second container by performing subsequent steps 402-404.

[0107] Step 402, obtain the target metadata pre-stored in the physical machine of the electronic device.

[0108] Similar to the implementation process of starting the first container, in response to the startup request for the second container, specifically, the application agent of the container can obtain the target metadata stored in the PVC file in the physical machine according to the configured path of the PVC file in the physical machine.

[0109] For the implementation of writing encrypted target metadata to a PVC file, the application agent can first obtain the private key that matches the public key used during encryption based on the pre-start hook of the container. Then, use the private key to decrypt the encrypted target metadata obtained from the PVC file of the physical machine to obtain the decrypted available target metadata.

[0110] Step 403: Mount the remote storage device to be accessed to the physical machine of the electronic device according to the target metadata, so as to obtain the mount information of the remote storage device on the physical machine.

[0111] Different from the startup of the first container, for the startup of the second container, after obtaining the target metadata of the remote storage device to be accessed by the second container, mount the target metadata to the remote storage device indicated by the remote storage server to the physical machine of the electronic device.

[0112] After the mounting is completed, the mount information of the remote storage device to be accessed by the second container, that is, the storage directory of the remote storage device, is obtained on the physical machine of the electronic device accordingly.

[0113] Step 404: Start the second container so that the application in the second container can access the remote storage device.

[0114] On the basis of mounting the remote storage device to the physical machine of the electronic device, further start the second container on the physical machine of the electronic device, that is, start a normal container. After the startup is completed, the second container runs on the physical machine of the electronic device accordingly, supporting the application in the second container to access the remote storage device in a direct access mode through the mount information of the remote storage device on the physical machine.

[0115] Optionally, the application in the second container accesses the remote storage device in a direct access mode through the access password in the target metadata.

[0116] In addition, optionally, during the process of the application in the second container accessing the remote storage device, the remote storage device is in a locked state. For example, the remote storage server locks the remote storage device using a mutex based on the access event of the application in the second container to the remote storage device, etc., to achieve exclusive single access and exclusive access of the application in the second container to the remote storage device, so as to prevent other access ends from accessing the remote storage device during the access process.

[0117] This embodiment further provides an access method for directly accessing a remote storage device on a physical machine based on a second container, providing users with more options for realizing remote storage access; in addition, by providing exclusive single access and key capabilities for the second container on the remote storage server in this embodiment, it can further prevent multi-point mounting of the remote storage device on the server, and solve the security problem of data leakage caused by multi-point mounting.

[0118] The following provides an application example of the access control method of the present application.

[0119] This example follows the pv and pvc semantic framework specifications of the existing container management tool kubernetes, carries the metadata of the remote storage device in the form of a file to support providing a temporary pv to the container based on the metadata, and this example extends the container lifecycle management protocol algorithm, implements the iscsi protocol client and nvme over fabrics protocol client of the container in the container management tool kubernetes, supports following the container lifecycle through the metadata in the pvc to manage the remote storage device based on the iscsi protocol client or nvme over fabrics protocol client, and realizes the access control of the remote storage device by the virtual machine secure container or the physical machine ordinary container. In addition, this example also provides exclusive single access and key capabilities on the remote storage server to prevent multiple mounts of the remote storage device and solve the security problem of data leakage caused by multiple mounts.

[0120] See Figure 5 , the access control process for the remote storage device in this example includes:

[0121] 21) Create a customized PVC through a customized csi plugin, and obtain and store the target metadata:

[0122] 21.1: Create a PVC carried in the form of a local file;

[0123] 21.2: Call the remote storage api to create an iscsi volume or an nvme volume when creating the PVC;

[0124] Specifically, call the remote storage api to transfer the PVC to the remote storage server, and the remote storage server creates an iscsi volume or an nvme volume of the applied storage capacity based on the PVC as the remote storage device to be accessed by the container application.

[0125] 21.3: After the remote storage server creates an iscsi volume or an nvme volume, obtain the corresponding iscsi iqn / nvme nqn, access password, and remote storage IP information;

[0126] 21.4: Encrypt the iscsi iqn / nvme nqn, access password, and remote storage IP information using a predetermined public key, and write them into the pvc file on the local physical machine of the electronic device after encryption to realize the storage of the target metadata on the local physical machine of the electronic device.

[0127] 22) Container lifecycle management:

[0128] 22.1: Before starting a secure container or a normal container, use the pre-start of the container to transfer the private key, decrypt based on the private key to obtain the metadata information in the pvc file - iscsi iqn / nvme nqn, access password, and remote storage IP information, and mount the remote storage device into the secure container kernel (virtual machine kernel) or mount it into the normal container physical machine kernel based on the decrypted metadata information;

[0129] 22.2: After the access ends, close or destroy the secure container or the normal container based on requirements. Before closing or destroying the secure container or the normal container, use the post-stop of the container to close the access to the remote storage by obtaining the iqn / nqn mapped in the guest kernel by the pvc and the remote storage IP information. At the same time, for the destruction process, the remote storage server also releases the storage space of the remote storage device.

[0130] The embodiments of the present application also disclose an electronic device, which may specifically be, but is not limited to, devices under numerous general or specific computing device environments or configurations, such as: personal computers, server computers, portable devices, tablet devices, multi-processor devices, and so on.

[0131] The composition structure of the electronic device is as Figure 6 shown, including:

[0132] A memory 10, used to store computer instruction sets;

[0133] The computer instruction sets in the memory 10 can be implemented in the form of computer programs.

[0134] A processor 20, used to implement the access control method disclosed in the above method embodiments by executing the computer instruction sets.

[0135] The processor 20 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, etc.

[0136] In addition, the electronic device may further include components such as a communication interface and a communication bus. The memory, the processor, and the communication interface complete communication with each other through the communication bus.

[0137] The communication interface is used for communication between the electronic device and other devices. The communication bus can be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0138] In summary, compared with the traditional technology, the access control method and the electronic device provided by the embodiments of the present application at least have the following technical advantages:

[0139] 31) Each guest kernel driver of the secure container directly accesses the remote storage device independently, reducing the intervention of the physical machine kernel layer of the electronic device and improving the IO performance of the secure container;

[0140] 32) On the premise of enhanced access control based on key capabilities and without the intervention of the physical machine kernel layer, the secure container reduces the risk of data leakage to the remote storage device and improves security;

[0141] 33) When a common container mounts a remote storage device, it also needs to perform decryption processing on the metadata in the pvc file to achieve mounting, realizing security control when accessing the remote storage based on the common container, and improving the security of remote storage access based on the common container to a certain extent;

[0142] 34) The secure container and the common container both support two protocol stacks, iscsi and nvme-of, and have compatibility and performance advantages;

[0143] 35) It is compatible with the existing kubernetes pv and pvc storage access models, and the implementation complexity and difficulty are low.

[0144] It should be noted that the various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0145] For the convenience of description, when describing the above system, device or equipment, various modules or units are described separately according to functions. Of course, when implementing the present application, the functions of each unit can be realized in the same or multiple software and / or hardware.

[0146] From the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present application, in essence, or the part that makes a contribution to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of the present application.

[0147] Finally, it should also be noted that in this text, relational terms such as first, second, third, and fourth are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including a..." does not exclude the existence of additional identical elements in the process, method, article or device including the said element.

[0148] The above are only the preferred embodiments of the present application. It should be pointed out that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. An access control method applied to a container management tool, comprising: Obtaining a startup request for starting a first container on an electronic device; The first container is a container running on a virtual machine; Obtaining target metadata pre-stored on a physical machine of the electronic device, where the target metadata is metadata of a remote storage device to be accessed by the first container, and the target metadata is generated by a remote storage server obtaining device metadata and saving it to the physical machine of the electronic device when pre-creating the remote storage device to be accessed by the first container; According to the target metadata, mounting the remote storage device to the virtual machine corresponding to the first container to obtain mount information of the remote storage device in the virtual machine; The mount information in the virtual machine can be used to enable an application in the first container to access the remote storage device in a direct pass-through manner in the virtual machine; Starting the first container so that the application in the first container accesses the remote storage device.

2. The method according to claim 1, wherein The process of pre-storing the target metadata on the physical machine of the electronic device includes: Creating a storage volume claim on the physical machine, where the storage volume claim includes the applied storage capacity; Transmitting the claim information of the storage volume claim to the remote storage server through a remote storage interface on the physical machine, so that the remote storage server creates a matching remote storage device according to the received claim information and generates corresponding metadata for the created remote storage device; Obtaining the metadata fed back by the remote storage server and storing the metadata as the target metadata on the physical machine.

3. The method according to claim 2, where the storage volume claim is a claim in the form of a local file; the target metadata includes the device identifier, device address, and access password of the remote storage device; and the target metadata is stored in the claim file of the storage volume claim on the physical machine; Among them, Pre-creating a storage volume claim on the physical machine of the electronic device through a container storage interface plugin integrated into the container management tool, and storing the target metadata in the claim file of the storage volume claim.

4. The method according to claim 3, where the application in the first container accesses the remote storage device in a direct pass-through manner, including: The application in the first container uses the mount information to access the remote storage device in a direct pass-through manner through the access password; Wherein, during the process of the application in the first container accessing the remote storage device, the remote storage device is in a locked state to prevent other access ends from accessing the remote storage device.

5. The method according to claim 1, where the obtaining of the target metadata pre-stored on the physical machine includes: Creating a virtual machine in a runtime manner, and obtaining the target metadata stored on the physical machine by using an application proxy of the container based on the created virtual machine; The mounting of the remote storage device to the virtual machine corresponding to the first container according to the target metadata includes: Using the application proxy to mount the remote storage device to the virtual machine according to the target metadata.

6. The method according to claim 1, wherein, The target metadata pre-stored in the physical machine is the encrypted result data obtained by encrypting the target metadata using a predetermined public key; The obtaining of the target metadata pre-stored in the physical machine of the electronic device includes: Obtaining a private key that matches the public key; Obtaining the encrypted result data from the physical machine and decrypting the encrypted result data using the private key to obtain the target metadata.

7. The method according to claim 1, further comprising: Obtaining a shutdown request for shutting down the first container, and shutting down the first container and releasing the mount of the remote storage device indicated by the target metadata; Or, obtaining a destruction request for destroying the first container, destroying the first container and releasing the mount of the remote storage device indicated by the target metadata, and sending the destruction request to a remote storage server so that the remote storage server releases the storage space of the remote storage device according to the destruction request.

8. The method according to claim 1, further comprising: Obtaining a start request for starting a second container; the second container is a container for running on a physical machine, and the security of the second container is lower than the security of the first container; Obtaining the target metadata pre-stored in the physical machine; Mounting the remote storage device to be accessed to the physical machine according to the target metadata so as to obtain mount information of the remote storage device on the physical machine; Starting the second container so that an application in the second container accesses the remote storage device.

9. The method according to claim 8, wherein a first protocol stack and a second protocol stack for accessing the remote storage device are integrated in the first container or the second container; The first container or the second container accesses the remote storage device through any one of the first protocol stack and the second protocol stack.

10. An electronic device, comprising: A memory for storing at least one set of instruction sets; A processor for calling and executing the instruction sets in the memory and implementing the access control method according to any one of claims 1-9 by executing the instruction sets.

Images