A mirror management method and apparatus

Abstract

Embodiments of the present application provide a mirror image management method and device, the method comprising: receiving information of a signer and information of a target mirror image sent by a first terminal device; the signer being an object designated to sign the target mirror image; obtaining a signature file based on the information of the signer and the information of the target mirror image; if a first digest of the target mirror image returned by a container platform matches a second digest obtained based on the signature file, instructing the container platform to allow the target mirror image to be used to start a container. Embodiments of the present application propose to realize fine-grained and easy-to-use mirror image control functions through signature technology, and guarantee mirror image content security and container platform security in the whole life cycle of a container mirror image.

Description

Technical Field

[0001] This application relates to the fields of cloud computing and information security technology, and in particular to an image management method and apparatus. Background Technology

[0002] Container technology is a process-level virtualization technology at the operating system level. It achieves transparent and independent resource usage between processes by partitioning, isolating, and controlling resources such as CPU, memory, and file systems. Using container technology in a production environment requires the cooperation of both the container platform and the container image.

[0003] A container platform is a system that runs containers. It typically includes one or more of the following: servers, cloud platforms, container engines, container orchestration tools, etc., and can realize functions such as container deployment, operation, maintenance, and management.

[0004] Images are the foundation of containers; container engines can use images to start containers. An image is a file system package consisting of a packaged file system and metadata describing the image. It contains all the elements an application needs, including the system, environment, configuration, and the application code itself. In other words, the security of the image content directly affects the security of container operation, and consequently, the security of the underlying computing, storage, and network infrastructure of the container.

[0005] Therefore, how to ensure the integrity and security of the image is a hot topic of research for those skilled in the art. Summary of the Invention

[0006] This application discloses an image management method and apparatus that can control the security and integrity of images, ensure the security of image content and container platform, and improve user experience.

[0007] The first aspect of this application discloses a mirror management method, including:

[0008] Receive information about the signer and the target image sent by the first terminal device; the signer is the object designated to sign the target image;

[0009] The signature file is obtained based on the signer's information and the target image's information;

[0010] If the first digest of the target image returned by the container platform matches the second digest obtained based on the signature file, the container platform is instructed to allow the container to be started using the target image.

[0011] In the above embodiments, the signer's information and the target image's information are obtained through the first terminal device, and the signature file of the target image is obtained based on the signer's information and the target image's information. Since there is a mapping relationship between the target image's digest and its content, if the target image's content is tampered with, the target image's digest will also change accordingly. Therefore, when the container platform uses the target image to start a container, if the first digest of the target image matches the second digest of the target image when the signature file is generated, it indicates that the target image's content has not been tampered with. Thus, the container platform can be instructed to allow the use of the target image to start the container, thereby enabling control over the security and integrity of the target image, ensuring the security of the target image's content and the container platform.

[0012] In addition, signers only need to sign the image through the first terminal device, without having to generate key pairs, save keys, generate signature files, etc. on the local terminal. This improves the security of the image, reduces the operational complexity for signers, and enhances the user experience.

[0013] The above method embodiments can be executed before image development, during image push, and during image usage. Therefore, the above method embodiments can achieve tracking of the entire lifecycle of the image and can be coupled with the image building pipeline, adapting to current cloud-native development technologies.

[0014] In one possible implementation of the first aspect, before receiving the signer information and the target image information sent by the first terminal device, the method further includes:

[0015] The system receives indication information of the target image and description information of the signer from the second terminal device. Further, the description information of the signer is used to indicate the signer who signed the target image.

[0016] As can be seen, the second terminal device can indicate which signers are required to sign the target image. In one possible design, the administrator inputs the image control policy through the second terminal device. This control policy includes the aforementioned target image indication information and the signer description information. This control policy is used to control the target image. It can be seen that the administrator only needs to input the control policy to control the image, improving the user experience. Especially when there are multiple images to manage (e.g., the management of developed images by an enterprise or organization), it can decouple the image development team, image management team, and image signers, improving the user experience.

[0017] In yet another possible implementation of the first aspect, the indication information of the target image includes the identity of the target image and / or the identification information of the container cluster used to run the target image.

[0018] As can be seen, through the embodiments of this application, not only can the control function of a single image be realized, but also the control of multiple images that need to run in a container cluster can be realized, thereby realizing image control functions of various granularities and meeting the user's control needs for a single image, multiple images, and images that need to run in a container cluster.

[0019] In another possible implementation of the first aspect, the signer's information includes the signer's identity information, and the method further includes:

[0020] The identity of the at least one signer is confirmed to be verified based on the identity information.

[0021] The above explains that the identity of the signer can be authenticated during the image management process. This can prevent untrusted signers from signing the files and improve the security of the image.

[0022] In another possible implementation of the first aspect, determining that the identity information of the at least one signer has been authenticated based on the identity information includes:

[0023] Receive the authentication information of the signer sent by the second terminal device;

[0024] Based on the signer's authentication information and identity information, it is determined that the signer's identity verification is successful.

[0025] The above provides a method for authenticating the identity of a signer. (An administrator or automated management program, etc.) can set the signer's authentication information through a second terminal device. When the first terminal device uploads the signer's identity information, it can compare the identity information with the authentication information. If the comparison is consistent, it means that the signer's identity is trustworthy.

[0026] In another possible implementation of the first aspect, information transmission between the second terminal device, the first terminal device, and the container platform is supported via an application programming interface (API).

[0027] The above describes the communication method, which connects to the second terminal device, the first terminal device, and the container platform through an API interface. These devices can perform functions such as image management, image signing, and image startup control simply by calling relevant functions through the API interface, thus reducing the difficulty of operation for users.

[0028] In another possible implementation of the first aspect, after receiving the description information of at least one signer sent by the second terminal device, the method further includes:

[0029] Generate a key pair corresponding to the signer, the key pair including a public key and a private key.

[0030] The above describes how key pairs can be generated during image management, and these key pairs can be used in signing, authentication, and boot control processes. Furthermore, these key pairs can be stored in the image management device, eliminating the need for users to store public and private keys locally, thus preventing key leaks.

[0031] In another possible implementation of the first aspect, the information of the target image includes the hash value of the target image; the information of the signer corresponds to the private key of the signer; obtaining the signature file based on the information of the signer and the information of the target image includes:

[0032] The signature file is generated using the signer's private key and the hash value of the target image.

[0033] The above describes how to generate a signature file. The image information includes the image's hash value. A signature file can be generated using the signer's private key and the image's hash value. Because there is a mapping relationship between the image's content and its hash value, if the image content is tampered with, the image's digest will also change accordingly. Therefore, the image's hash value can be used to identify whether the image's content has been tampered with.

[0034] In yet another possible implementation of the first aspect, the method further includes:

[0035] The system receives a request message from a container platform, the request information being used to request the launch of the container on the container platform using the target image. Further, the request message includes the first digest.

[0036] Specifically, the container platform can include the target image's indication information in the request message and invoke the image's startup control via API. In this way, when the container platform starts a container, providing the target image's summary information allows it to determine the image's safety based on the feedback indication information. This eliminates the need to adjust the container platform's image inspection functionality and enables rapid compatibility with container platforms from multiple service providers.

[0037] In yet another possible implementation of the first aspect, the method further includes:

[0038] Based on the signer's authentication information, the signer's authentication information is added to the signer database.

[0039] In another possible implementation of the first aspect, the signer includes a first signer and a second signer; the first terminal device includes a first sub-device and a second sub-device, wherein the first sub-device is a device used by the first signer; and the second sub-device is a device used by the second signer.

[0040] Through the embodiments in this application, multiple signers can upload information for signing through one or more devices respectively, thereby obtaining signature files and realizing a multi-signature mechanism.

[0041] Secondly, embodiments of this application provide a mirror management device, including:

[0042] The receiving unit is used to receive information about the signer and the target image sent by the first terminal device; the signer is the object designated to sign the target image.

[0043] The processing unit is configured to obtain a signature file based on the information of the signer and the information of the target image;

[0044] The processing unit is configured to instruct the container platform to allow the launch of a container using the target image if the first digest of the target image returned by the container platform matches the second digest obtained based on the signature file.

[0045] In one possible implementation of the second aspect, the receiving unit is further configured to:

[0046] The system receives indication information of the target image and description information of the signer sent by the second terminal device, wherein the description information of the signer is used to indicate the signer who signs the target image.

[0047] In another possible implementation of the second aspect, the indication information of the target image includes the identity of the target image and / or the identification information of the container cluster used to run the target image.

[0048] In another possible implementation of the second aspect, the signer's information includes the signer's identity information; the processing unit is further configured to:

[0049] The identity of the at least one signer is confirmed to be verified based on the identity information.

[0050] In another possible implementation of the second aspect, the receiving unit is further configured to receive the authentication information of the signer sent by the second terminal device;

[0051] The processing unit is further configured to determine that the signer's identity verification is successful based on the signer's authentication information and identity information.

[0052] In another possible implementation of the second aspect, the device supports information transmission with the second terminal device, the first terminal device, and the container platform via an application programming interface (API).

[0053] In another possible implementation of the second aspect, the processing unit is further configured to generate a key pair corresponding to the signer, the key pair including a public key and a private key.

[0054] In another possible implementation of the second aspect, the information of the target image includes the hash value of the target image; the information of the signer corresponds to the private key of the signer; the processing unit is specifically used to generate the signature file using the private key of the signer and the hash value of the target image.

[0055] In another possible implementation of the second aspect, the receiving unit is further configured to receive a request message sent by the container platform, the request message being used to request the use of the target image to start a container on the container platform. Further, the request message includes the first digest.

[0056] In another possible implementation of the second aspect, the processing unit is further configured to add the signer's authentication information to the signer database based on the signer's authentication information.

[0057] In another possible implementation of the second aspect, the signer includes a first signer and a second signer; the first terminal device includes a first sub-device and a second sub-device, wherein the first sub-device is a device used by the first signer; and the second sub-device is a device used by the second signer.

[0058] Thirdly, embodiments of this application provide a mirror management device, including a processor and a memory; the processor is used to execute computer instructions stored in the memory, causing the mirror management device to implement the method described in the first aspect or any possible implementation of the first aspect.

[0059] In one possible implementation of the third aspect, the image management device further includes a communication interface, the processor specifically used for:

[0060] The system receives information about the signer and the target image from the first terminal device via a communication interface; the signer is the object designated to sign the target image.

[0061] A signature file is obtained based on the signer's information and the target image's information;

[0062] If the first digest of the target image returned by the container platform matches the second digest obtained based on the signature file, the container platform is instructed to allow the container to be started using the target image.

[0063] In yet another possible implementation of the third aspect, the processor is further configured to:

[0064] The system receives the indication information of the target image and the description information of the signer sent by the second terminal device through the communication interface, wherein the description information of the signer is used to indicate the signer who signed the target image.

[0065] In another possible implementation of the third aspect, the indication information of the target image includes the identity of the target image and / or the identification information of the container cluster used to run the target image.

[0066] In yet another possible implementation of the third aspect, the signer's information includes the signer's identity information; the processor is further configured to:

[0067] The identity of the at least one signer is confirmed to be verified based on the identity information.

[0068] In yet another possible implementation of the third aspect, the processor is further configured to:

[0069] The authentication information of the signer sent by the second terminal device is received through the communication interface;

[0070] Based on the signer's authentication information and identity information, it is determined that the signer's identity verification is successful.

[0071] In another possible implementation of the third aspect, the device supports information transmission with the second terminal device, the first terminal device, and the container platform via an application programming interface (API).

[0072] In another possible implementation of the third aspect, the processor is further configured to generate a key pair corresponding to the signer, the key pair including a public key and a private key.

[0073] In another possible implementation of the third aspect, the information of the target image includes the hash value of the target image; the information of the signer corresponds to the private key of the signer; the processor is specifically used to generate the signature file using the private key of the signer and the hash value of the target image.

[0074] In another possible implementation of the third aspect, the processor is further configured to receive a request message sent by the container platform via the communication interface 1204, the request message being used to request the launch of a container on the container platform using the target image. Further, the request message includes the first digest.

[0075] In another possible implementation of the third aspect, the processor is further configured to add the signer's authentication information to the signer database based on the signer's authentication information.

[0076] In another possible implementation of the third aspect, the signer includes a first signer and a second signer; the first terminal device includes a first sub-device and a second sub-device, wherein the first sub-device is a device used by the first signer; and the second sub-device is a device used by the second signer.

[0077] Fourthly, embodiments of this application disclose a server, the server including a processor and a memory; the processor is configured to execute computer instructions stored in the memory, causing the server to implement the method described in the first aspect or any possible implementation of the first aspect.

[0078] Fifthly, embodiments of this application disclose a mirror management system, including a mirror management device, a first terminal device, and a second terminal device. The mirror management device includes the apparatus described in any possible implementation of the second or third aspect; or it includes the apparatus described in the third aspect or any possible implementation of the third aspect.

[0079] Sixthly, embodiments of this application disclose an image management system, including an image management device, a first terminal device, a second terminal device, and a container platform. The image management device includes the apparatus described in any possible implementation of the second or third aspect; or it includes the apparatus described in the third aspect or any possible implementation of the third aspect.

[0080] In a seventh aspect, embodiments of this application disclose a computer-readable storage medium storing computer instructions for implementing the method described in the first aspect or any possible implementation thereof.

[0081] Eighthly, embodiments of this application disclose a computer program product for implementing the method described in the first aspect or any possible implementation of the first aspect.

[0082] It is understood that the beneficial effects of the technical solutions provided in the second and third aspects of this application can be referred to the beneficial effects of the first aspect, and therefore will not be repeated here. Attached Figure Description

[0083] The accompanying drawings used in the embodiments of this application are described below.

[0084] Figure 1 This is a schematic diagram of the architecture of a mirror management system provided in an embodiment of this application;

[0085] Figure 2 This is a schematic diagram illustrating a use case of a mirror management system provided in an embodiment of this application;

[0086] Figure 3 This is a schematic diagram illustrating a possible mirror control strategy and a description of the signer provided in an embodiment of this application;

[0087] Figure 4 This is a flowchart illustrating an image management method provided in an embodiment of this application;

[0088] Figure 5 This is a schematic diagram illustrating a scenario where a second terminal device communicates with a mirror management device, as provided in an embodiment of this application.

[0089] Figure 6 This is a schematic diagram illustrating a scenario where a first terminal device communicates with a mirror management device, as provided in an embodiment of this application.

[0090] Figure 7 This is a schematic diagram illustrating a scenario where a container platform communicates with an image management device, as provided in an embodiment of this application.

[0091] Figure 8 This is a flowchart illustrating another image management method provided in an embodiment of this application;

[0092] Figure 9 This is a flowchart illustrating another mirror signature method provided in an embodiment of this application;

[0093] Figure 10 This is a flowchart illustrating another mirror signature method provided in an embodiment of this application;

[0094] Figure 11 This is a schematic diagram of the structure of a mirror management device provided in an embodiment of this application;

[0095] Figure 12 This is a schematic diagram of another image management device provided in the embodiments of this application. Detailed Implementation

[0096] The embodiments of this application are described below with reference to the accompanying drawings. It should be noted that in this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. The use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0097] The technical terms used in this application will be explained below.

[0098] I. Container

[0099] A container is a series of processes isolated from the rest of the system. Container technology is a virtualization technology in computer operating systems that allows processes to run in relatively independent and isolated environments (including independent file systems, namespaces, resource views, etc.), thereby simplifying software deployment processes, enhancing software portability and security, and improving system resource utilization. Container technology is widely used in service-oriented scenarios in the cloud computing field. Using container technology requires the cooperation of objects and components such as container images, container engines, and orchestration platforms.

[0100] II. Mirror

[0101] An image is a file system package consisting of a pre-packaged file system and metadata describing the image. It contains one or more of the elements required by an application, including the system, environment, configuration, and the application code itself. For example, packaging a test version of an operating system creates a test system image, and packaging a game program creates a game image, and so on.

[0102] Images are the foundation of containers, and container engines can use images to start containers. Because images contain all the elements needed for an application, the security of the image content directly affects the security of container operation, and consequently, the security of the underlying computing, storage, and network infrastructure of the container.

[0103] III. Kubernetes

[0104] Kubernetes (also known as K8s) is an open-source container orchestration tool and a de facto standard for container orchestration. It is used to manage the orchestration, deployment, and management of containers across multiple hosts in a cloud platform. It can be adapted to various container engines and provides convenient, efficient, and elastically scalable application container management.

[0105] Kubernetes not only provides powerful container orchestration capabilities, but also offers users control points before the container engine starts containers from images, through rules / restrictions on the startup of containers corresponding to images. This mechanism is called Kubernetes Admission Control (also known as permission control or access control). Admission Control contains a rule chain consisting of system defaults and user-defined rules; only images that meet the requirements of all rules in the rule chain are allowed to be started by the container engine.

[0106] IV. Container Platform

[0107] A container platform is a system for running containers, which includes servers, cloud platforms, container engines, container orchestration tools, etc., and can realize functions such as container deployment, operation, maintenance, and management.

[0108] V. Mirror Repository

[0109] A container image repository is a centralized repository for storing container images. It can be divided into public and private image repositories. Public image repositories can be accessed directly via the internet, while private image repositories can only be accessed through the local network where they are located.

[0110] VI. Hash value

[0111] A hash value is the output value obtained by hashing a piece of data (such as a string, number, file, etc.). A mirror hash value is a fixed-length hash value obtained by hashing the content of a mirror image; it can also be called a mirror digital digest and can be used for signature calculations. Typically, when a mirror file is packaged according to a standard format, its hash value can be obtained as one of the attributes of the mirror file.

[0112] VII. Signature Mechanism

[0113] A signature mechanism is used to protect the integrity and authenticity of data. Generally, this mechanism is based on a public-private key pair. Specifically, an asymmetric key algorithm and a private key are used to calculate a digital digest of the protected data to generate a digital signature. The digital signature can be used to obtain a digital digest by reversing the operation between the public key and the asymmetric key algorithm. By comparing the digital digest obtained through the reverse operation with the digital digest calculated from the protected data, it can be determined whether the protected data has been tampered with.

[0114] Please see Figure 1 and Figure 2 , Figure 1 This is a schematic diagram of the structure of a possible mirror management system 10 provided in an embodiment of this application. Figure 2 This is a schematic diagram illustrating a usage scenario for system 10. System 10 includes an image management device 101 and a first terminal device 102. Optionally, it may also include a container platform 103. Further optionally, it may also include a second terminal device 104.

[0115] in:

[0116] The first terminal device 102 is a device or cluster of devices with data processing and data storage capabilities, used by the signer of the image to submit information for generating the signature file. This includes, for example, the target image's attribute information (such as identifier, number, hash value, etc.) and the signer's identity information (such as account, name, identity identifier, etc.). The first terminal device can be a single device or a cluster of multiple devices. See, for example... Figure 2The first terminal devices 102a, 102b, and 102c form a cluster of first terminal devices. First terminal device 102a is the device used by signer A and can submit signer A's identity information; first terminal device 102b is the device used by signer B and can submit signer B's identity information, and so on for the other devices.

[0117] Container platform 103 is a platform for running containers, and can start containers based on a target image. In this application, container platform 103 can send information about the target image to be run to image management device 101, receive the security verification result from image management device 101, and determine whether to start the container based on the target image in response to the verification result. Generally, Kubernetes can be deployed in the container platform, and Kubernetes can manage multiple containers in the container platform. Of course, in some possible scenarios, other applications can also be deployed to manage the containers.

[0118] The second terminal device 104 is a device or cluster of devices with data processing and data storage capabilities, used to submit instruction information for the target image and specify the signer of the target image.

[0119] The image management device 101 is a device or cluster of devices with data processing and data storage capabilities. It can interact with the first terminal device 102, the container platform 103, and the second terminal device 104 to achieve secure management of images.

[0120] In one possible design, the image management device 101 may specifically include a management module 1011, a signature module 1012, and a control module 1013. Further, it may include one or more of an authentication module 1014, a key module 1015, and a storage module 1016. Optionally, any one of the management module 1011, signature module 1012, control module 1013, authentication module 1014, and key module 1015 may be an electronic device with data processing capabilities or a component (e.g., a chip or integrated circuit) within an electronic device with data processing capabilities. The aforementioned electronic device may be a physical device, such as one or more host machines, rack servers, or blade servers; or it may be a virtual device, such as one or more virtual machines or containers.

[0121] Storage module 1016 is a device with data storage capabilities. It can be a physical storage device, such as memory (including random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), etc.), or a disk (including compact disc random access memory (CD-RAM), hard disk, etc.). It can also be other electronic devices with data storage capabilities, such as network attached storage (NAS) servers, or virtual storage devices, such as virtual machines, containers, etc.

[0122] It should be noted that the multiple modules in the image management device 101 can be deployed on different devices, on the same device, or in the same server cluster. For example, the distributed server can be a server cluster composed of multiple servers, which may include cloud computing servers, content delivery network (CDN) servers, network time protocol (NTP) servers, domain name system (DNS) servers, storage servers, etc. The cluster may also include NAS for data storage. The various devices of the distributed server can coordinate with each other to jointly complete functions such as computing, data storage, and communication. In one possible design, the management module 1011, signature module 1012, and control module 1013 can be deployed on the CDN server in the distributed server, the authentication module 1014 and key module 1015 can be deployed on the cloud computing server in the distributed server, and the storage module 1016 can be deployed on the storage server in the distributed server.

[0123] Specifically, the management module 1011 can be used to determine one or more of the following: the control strategy of the image, the description information of the signer, and the authentication information of the signer. Optionally, the management module in this embodiment can also be called an interaction module.

[0124] The control policy for the image can include one or more of the following: indication information of the controlled object (e.g., the target image), control requirements, etc. Optionally, the indication information of the controlled object can be the image's identifier (e.g., the image's name, number, ID, etc., one or more) and / or the identifier of the cluster using the image. That is, the indication information of the controlled object can include either the image's identifier or the cluster's identifier, and it is also supported to include both the image's identifier and the cluster's identifier simultaneously.

[0125] Understandably, if the control object's instruction information includes an image identifier, then the control policy applies to the image corresponding to that identifier. If the control object's instruction information includes a cluster identifier, then the control policy applies to images running within the cluster indicated by that identifier. If the control object's instruction information includes both an image identifier and a cluster identifier, then the control policy applies to the specified image running within the cluster indicated by that identifier. See also Figure 3 , Figure 3 This is a schematic diagram illustrating a possible mirror control strategy and the signer's description information, as exemplified in this application. See [link to relevant documentation]. Figure 3 In part (a) of the diagram, the control strategy shown in region 201 includes the control objects: the indication information of the image (i.e., image1) and the indication information of the cluster. Figure 3 The control policy shown is an indication of an empty cluster (in the specific implementation, it can be the cluster name, number, etc.), indicating that the control is applied to the image named image1.

[0126] Optionally, an image identifier can correspond to one or more images. Further optionally, the control object's indication information may also include an image tag. If the control object's indication information includes both an image identifier and an image tag, then the control policy applies to images possessing that tag.

[0127] Optionally, the control policy and signer description information of the image can be pre-configured, or they can be obtained by the management module based on information sent by the second terminal device. For example, see Figure 2 The administrator can input control policies through the second terminal device 104, which can then send the control policies to the mirror management device 101. The control policies may include indication information for the controlled objects (see...). Figure 2 In the example, the instruction information is image1. Understandably, the R&D team obtained two images (labeled tag1 and tag2), both of which are identified as image. Since the control policy does not include the image's label, the control policy applies to the two images identified as image1.

[0128] The control requirements in the image's control policy include the signer's descriptive information (e.g., one or more of the signer's name, number, ID, etc.), which describes the object signing the target image. Specifically, the signer's descriptive information can be a list of signer accounts, for example, see [link to relevant documentation]. Figure 3 Taking the image1 file, which requires signatures from signers A, B, and C, as an example, the list of signer accounts includes the accounts of signers A, B, and C. It should be noted that the inclusion of signers A, B, and C here is for ease of description; in actual implementation, any number of signers can be included, and the descriptive information can be the signer's number, identifier (ID), etc.

[0129] The signer's authentication information includes one or more of the signer's account, name, password, etc. Optionally, the administrator can input the signer's authentication information through a second terminal device 104, which can then send the signer's authentication information to the management module 1011 (e.g., when the administrator adds a new signer or edits a signer's information). For example, taking the image1 file requiring signatures from signers A, B, and C as an example, see [link to example]. Figure 3 In section (b), the signature authentication information in area 302 includes the account (i.e., signer1, for example only) and password (i.e., password1, for example only) of signer A, the account and password of signer B, and the account and password of signer C.

[0130] Optionally, the management module may provide an application programming interface (API) to the outside world, through which the management module can receive control policies and / or authentication information sent by the first terminal device 102.

[0131] The signature module 1012 is used to sign the target image. For example, see... Figure 2 The signer, A, can send the hash value of the target image through the first terminal device 102a. Correspondingly, the signing module receives the hash value of the target image sent by the first terminal device 102a. The signing module can generate a signature file for the target image based on the private key corresponding to signer A and the hash value of the target image. The signing process for other signers can be deduced similarly, and will not be elaborated here.

[0132] Furthermore, the signature module 1012 can also verify the authenticity of the signature file. For example, if the signature file F1 is generated based on the private key corresponding to signer A and the hash value of the target image, then when verifying the signature file, the first signature module 1012 can verify the security and integrity of the signature file F1 through the signer's public key and the hash value of the target image.

[0133] The control module 1013 is used to receive requests to verify the security of the target image, and to provide verification results to the container platform. For example, see... Figure 2 The container platform 103 can pull the target image from the image repository 201 and request the image management device 101 to use the target image to start a container. Optionally, the operator can instruct the container platform 103 to pull the image and start the container via the console. The container platform 103 can send the target image information to the control module 1013, so that the control module 1013 can verify the target image's signature file, etc. For example, the control module checks whether the target image's signature file contains signature files from all specified signers and whether the signature files are correct. If the control module 1013 verifies the signature file successfully, it can send a verification success indication to the container platform 103, thereby enabling the container platform 103 to start the container. Understandably, if the verification fails, the control module 1013 can also send a verification failure indication to the container platform 103, and the container platform can refuse to start the target container based on this verification failure indication.

[0134] The authentication module 1014 is used to provide identity authentication functions, provide feedback on identity authentication results, and manage related authentication information.

[0135] The key module 1015 is used to provide key management functions, generate key pairs based on signer information and manage them effectively, and provide keys to other modules when needed.

[0136] Storage module 1016 is used to provide storage functions, such as saving signer information, signer key pairs, mirrored signing files, and mirrored control policies, and to feed back relevant information to each module when requested.

[0137] Furthermore, it should be noted that the signer mentioned in the embodiments of this application can be a user or an object such as a computer program that can operate on or call the input module in the computer. For example, the signer can be an artificial intelligence (AI) program that checks the code.

[0138] Please see Figure 4 , Figure 4 This is a flowchart illustrating an image management method provided in an embodiment of this application. Furthermore, this method can be based on... Figure 1The framework shown is used to implement this method, which includes at least the following steps:

[0139] Optional, Figure 4 The image management method shown includes step S401, which is detailed below:

[0140] Step S401: The image management device receives the target image indication information and the signer description information sent by the second terminal device. The signer is the object designated to sign the target image. This optionality means that, in actual implementation scenarios, the target image indication information and the signer description information may be sent by the second terminal device to the image management device, or they may not be sent by the second terminal device to the image management device (e.g., predefined or pre-configured by the image management device, or obtained by the image management device from network-side devices). The specific details depend on the implementation of the image management device and pre-defined agreements.

[0141] Specifically, a target image is a file system package developed by the R&D team. Typically, the R&D team develops business software, then packages this software according to image packaging standards to obtain the target image. After image development, the target image can be pushed to an image repository for storage.

[0142] To distinguish different images, image indication information can be used to designate a specific image. The target image indication information includes the image's identifier (e.g., one or more of the image's name, number, ID, etc.) and may also include the identifier of the cluster used to run the target image. Optionally, if the target image indication information includes the image's identifier, the image management device manages the image corresponding to that identifier (i.e., the target image). If the target image indication information includes a cluster identifier, the image management device manages images running within the cluster indicated by that identifier. If the target image indication information includes both the image's identifier and the cluster identifier, the image management device manages the specified image running within the cluster indicated by the identifier.

[0143] For example, taking the target image as image1, the indication information of the target image can be the name of the target image (i.e., image1), or it can be the ID of image1 (for example, if the ID of image1 is 0010, then the second terminal device can carry "0010" in the message to indicate the target image), to indicate that the managed object is image1.

[0144] For example, a container platform may include one or more container clusters (e.g., container cluster 1, container cluster 2, and container cluster 3). The target image's identifier can be the identifier of container cluster 1, indicating that the managed object is an image running in container cluster 1. Of course, this is just an example using cluster 1; in a real implementation, it could be one or more container clusters.

[0145] Further, optionally, the target image's indication information may include an image tag to specify an image with a particular tag. Generally speaking, since the same business software can have multiple different versions, attaching a tag to the image makes it easy to distinguish between different versions (e.g., development version, internal testing version, production version, etc.).

[0146] The signer's description information indicates the signer who signed the target image, and may include one or more of the signer's name, number, ID, etc. Specifically, the signer's description information may be a list of signer accounts. For example, see... Figure 3 Taking the image1 file, which requires signatures from signers A, B, and C, as an example, the list of signer accounts includes the accounts corresponding to signers A, B, and C. It should be noted that the inclusion of signers A, B, and C here is for ease of description; in actual implementation, any number of signers can be included.

[0147] It should be noted that the target image indication information and the signer description information mentioned above can be sent in the same message or in different messages. This description is for ease of understanding and is not intended to limit the invention. In some specific implementation scenarios, the target image indication information and the signer description information can be encapsulated together as a control policy. The second terminal device sends this control policy to the image management device in the first message. The image management device parses the first message to obtain the target image indication information and the signer description information.

[0148] Optionally, the second terminal device sends the target image instruction information and the signer's description information to the image management device, and correspondingly, the image management device receives the target image instruction information and the signer's description information from the second terminal device. For example, an administrator uses the second terminal device to input the target image instruction information and the signer's description information, and the second terminal device sends the target image instruction information and the signer's description information to the image management device. Further optionally, the second terminal device can send information to the image management device after receiving confirmation from the administrator.

[0149] In one possible design, the image management device can provide an API (referred to as the first API for convenience), through which the second terminal device can send indication information of the target image and description information of the signer to the image management device. For example, see... Figure 5 , Figure 5 This is a schematic diagram illustrating a possible scenario where a second terminal device communicates with a mirror management device, as provided in an embodiment of this application. Figure 5 Part (a) is a schematic diagram of the possible attributes of API 501. API 501 attributes include API address, request method, request parameters, and return parameters. The API address can be represented as a Uniform Resource Locator (URL). The request method can include at least the following four methods: GET, PUT, POST, and DELETE. Request parameters are the parameters passed when requesting the interface, and return parameters are the parameters returned after the interface processing. Typically, request and return parameters can include fields (also called parameter names, such as imageName), descriptions (used to describe the field), type (the type of the parameter, which can be integer, boolean, character, floating-point, array, etc.), remarks, and whether they are required. It can be seen that API 501 defines the interface used by the second terminal to send information to the image management device. See also... Figure 5 In part (b) of the design, in one possible configuration, the second terminal device 104 can display a front-end page as shown in areas 502 and 503. An administrator (who can be a person or a computer program) inputs information (e.g., the name of the image, signer information, etc.). The second terminal device generates message 504 and sends it to the image management device. Message 504 includes indication information of the target image and description information of the signer. Correspondingly, the image management device can obtain the indication information of the target image and the description information of the signer. Furthermore, the image management device can also return relevant parameters to the second terminal device (e.g., see the return parameters shown in area 505) to indicate whether the reception was successful, etc.

[0150] Optionally, the image management device can pre-register multiple signers. Further, the image management device can provide multiple signers to the second terminal device, allowing the user of the second terminal device to specify one or more of these signers as the object to be signed on the target image. Optionally, the image management device can provide the function of registering new signers. For example, the image management device can receive description information of a new signer A sent by the second terminal device (or may also include authentication information, such as one or more of the signer's account, name, password, etc.), and register the signer (or specifically, add signer A to the database storing the signer's description information).

[0151] Optionally, the image management device can also periodically or non-periodically authenticate the administrator's identity. For example, before processing the instruction information for the target image sent by the administrator, the device receives the administrator's identity information sent by the second terminal device. After successfully authenticating the administrator's identity using the administrator's information, the device processes the instruction information for the target image sent by the administrator.

[0152] In another possible design, the image management system can be client / server (C / S) architecture software (i.e., client / server mode) or browser / server (B / S) architecture system. The image management device acts as the server, and the second terminal device can input information and send information to the image management device through client programs or browsers.

[0153] Step S402: The image management device receives the signer information and target image information sent by the first terminal device.

[0154] Specifically, the signer's information may include one or more of the following: the signer's identification (ID), number, name, account, password, the signer's authentication information, and session authentication information.

[0155] The information of the target image can be one or more of the following: hash value, digest information, identity information, etc. The hash value is the output value obtained by hashing a piece of data (such as a string, number, or file) using a hash algorithm. In one possible design, when packaging the image file according to a standard format, the hash value of the image can be obtained as one of the attributes of the image file. The digest information is a type of hash value, also known as a message digest or digital digest. It is typically generated by mapping the plaintext to be encrypted into a fixed-length ciphertext (the length can be 128 bits, 256 bits, or other predefined lengths) using an algorithm.

[0156] It should be noted that the algorithm for generating digest information is usually called a message digest algorithm, while the algorithm for generating hash values ​​is usually called a hash algorithm. The message digest algorithm is a type of hash algorithm, but the message digest algorithm has stricter conditions, such as not being able to perform inverse operations and having higher collision requirements.

[0157] Understandably, the first terminal device sends the signer's information and the target image's information to the image management device, and correspondingly, the image management device receives the signer's information and the target image's information from the first terminal device. For example, signer A uses the first terminal device, enters signer A's information and the target image's information into the first terminal device, and the first terminal device sends the signer's information and the target image's information to the image management device.

[0158] In one possible design, the image management device can provide an API (referred to as the second API for convenience), through which the first terminal device can send information about the target signer and the target image to the image management device. For example, see... Figure 6 , Figure 6 This is a schematic diagram illustrating a possible scenario in which a first terminal device communicates with a mirror management device, as provided in an embodiment of this application. Figure 6 Part (a) is a schematic diagram of the possible attributes of API 601. The attributes of API 601 include API address, request method, request parameters, and return parameters. For a detailed explanation, please refer to the aforementioned explanation of the attributes of API 501. It can be seen that API 601 defines the API used by the second terminal to send information to the image management device. The request parameters include image number (field is imageId), image hash value (field is imageHash), signer ID (field is signerId), and signer password (field is signerPassword). Of course, in the specific implementation, other request parameters may also be included, or some parameters shown in API 601 may not be included. For example, the message in the request parameters may not include the signer's password. In some scenarios, when signer A logs into the first device, the first terminal device stores signer A's authentication information (such as session authentication information cookie or authentication file). When the first terminal device sends information to the image management device, it carries this authentication information, so that the image management device can identify the identity of signer A.

[0159] See Figure 6In part (b) of the design, in one possible configuration, the first terminal device 103 can display a front-end page as shown in area 602. An administrator (who can be a person or a computer program) inputs information (e.g., the name of the image). The first terminal device receives confirmation of submission from signer A, thereby generating message 603, which is then sent to the image management device. Message 603 includes information about the target image and the signer. Correspondingly, the image management device can obtain the target image information and the signer information. Furthermore, the image management device can also return relevant parameters to the second terminal device (e.g., see the return parameters shown in area 604) to indicate whether reception was successful, etc.

[0160] In some possible designs, the signer's information includes the signer's identity information. The mirror management device can first verify the signer's identity based on this information. If verification is successful, it continues with subsequent steps; if verification fails, it can return a message indicating identity verification failure to the first terminal device, or it can disconnect the communication connection with the first terminal device. Below are four examples of how to verify the signer's identity based on their identity information:

[0161] Implementation Method 1: The mirror management device stores the signer's authentication information (e.g., the signer's account and password). The signer's identity information has the same parameters as the signature information (e.g., the signer's identity information is also the signer's account and password). In this case, the mirror management device can compare the signer's identity information with the signature information. If they match, the signer's authentication is successful; otherwise, the authentication fails. Optionally, the signer's authentication information can be sent to the mirror management device by a second terminal device. For example, an administrator can define the signer's authentication information when registering a signer.

[0162] Method 2: The mirror management device stores the signer's contact information, such as phone number and email address. The signer's identity can be authenticated via SMS verification, email verification, or other contact accounts using a dynamic password. Optionally, the signer's contact information can be provided by the administrator during registration, pre-configured in the mirror management device, or obtained from the network device.

[0163] Implementation Method 3: The mirror management device stores a first password agreed upon with the signer (this first password can also be understood as a shared key, seed password, etc.). The mirror management device can generate a random number and send it to the first terminal device. The first terminal device uses a certain one-way algorithm to calculate the signer's identity information by mixing the first password and the random number, and then sends it to the mirror management device. The mirror management device uses the same method to calculate verification information, and verifies the user's identity by comparing the verification information with the signer's identity information. Optionally, the first password can be the password set by the signer when logging into the mirror management system, or it can be the password set by the administrator for the signer.

[0164] Implementation Method 4: The mirror management device sends session authentication information generated for the signer to the first terminal device. When the first terminal device sends a message to the mirror management device, it carries this session authentication information as the signer's identity information, enabling the mirror management device to identify the signer. For example, the mirror management device can generate a session authentication information cookie (sometimes also in plural form, cookies) for signer A and send it to the first terminal device. A cookie is data (usually encrypted) stored on the user's local device for identifying the user and tracking sessions; it is information temporarily or permanently stored by the device used by the user. Therefore, when the first terminal device sends a message to the mirror management device, it can carry the cookie as the signer's identity information. The mirror management device receives the cookie and can authenticate the signer's identity based on it.

[0165] Understandably, in practical implementation, only one authentication method can be used, or multiple authentication methods can be combined. Furthermore, optionally, the image management device can authenticate the signer's identity periodically or non-periodically, not necessarily before or after performing a specific action. For example, the image management device can authenticate the signer's identity when logging in, or it can authenticate the identity at regular intervals after logging into the system, or it can authenticate the identity when performing certain important operations.

[0166] Step S403: The image management device obtains the signature file based on the signer's information and the target image's information.

[0167] Specifically, the signature file is generated based on the digest of the target image. The image management device obtains the signature file based on the signer's information and the target image's information, and can use at least the following two methods:

[0168] Option 1: The signer's information corresponds to the signer's key, and the target image's information includes the target image's hash value or digest information. The image management device can generate a signature file based on the signer's key and the target image's hash value. Specifically, the signature method used to generate the signature file can be signature operations, such as modulo, XOR, logarithmic, and exponential operations, or it can use signature algorithms, such as RSA digital signatures, Data Signature Standard (DSS) digital signatures, ElGamal digital signatures, Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures, etc.

[0169] For example, the signer's key K1 can be determined based on the signer's ID. The target image information includes the target image's hash value (or it can be replaced with digest information). The image management device generates a signature file S1 using the DSS algorithm, based on the key K1 and the image's hash value, for example: S1 = DSS(K1, hash).

[0170] It should be noted that the signer's key in the embodiments of this application can be a public key, a private key, or a symmetric key. Generally speaking, in some scenarios, it can be a key pair, which includes a public key and a private key, such as when the signature algorithm used is an asymmetric algorithm; in other scenarios, it can be a single key, such as in peer-to-peer communication when the signature algorithm used is a symmetric algorithm.

[0171] Option 2: When the image management device detects (or listens to, receives) that an image has been packaged or pushed to an image repository, it calls a predefined interface or signature algorithm to sign the image's hash value using the key specified by the signer for that image, thus obtaining a signature file. This signature file can be stored in a file pool to be extracted. When the signer uploads their information and the target image's information through the first management device, the corresponding signature file can be extracted from the file pool using these information. This allows the signature file generation function to be deployed to a dedicated signature server, network-side equipment, or provided by a signature service provider, reducing the computational burden on the image management device. Furthermore, directly extracting the completed signature file during the signing process reduces the signer's waiting time and improves the user experience.

[0172] Step S404: If the first digest of the target image returned by the container platform matches the second digest obtained based on the signature file, the image management device instructs the container platform to allow the target container to be started using the target image.

[0173] Specifically, before the container platform starts the image, the image management device receives a summary of the image returned by the container platform. For ease of description, the summary of the target image returned by the container platform is referred to as the first summary.

[0174] A digest of the target image's signature can be obtained from the signature file; for convenience, this is referred to as the second digest. As can be understood, since the signature file is obtained by signing based on the signer's key and the target image's information, the second digest of the signature file can be obtained using the signer's public key and the signature file.

[0175] By comparing the first digest and the second digest, it can be determined whether the target image has been tampered with. Understandably, if the first digest matches the second digest, it indicates that the target image has not been tampered with, and the image management device instructs the container platform to allow the use of the target image to start the target container. Optionally, if the first digest does not match the second digest, it indicates that the content of the target image has been changed, and the image management device can instruct the container platform to refuse to use the target image to start the target container.

[0176] In one possible design, the image management appliance can provide an API (referred to as the third API for convenience), through which the container platform can return a first summary to the image management appliance. For example, see... Figure 7 , Figure 7 This is a schematic diagram illustrating a possible scenario of communication between a container platform and an image management device, as provided in an embodiment of this application. Figure 7 Part (a) is a schematic diagram of a possible API 701 attribute. API 701 attributes include API address, request method, request parameters, and return parameters. For a detailed explanation, please refer to [link to documentation / reference]. Figure 5 Explanation of API attributes. It can be seen that API 701 defines the API used by the container platform to send information to the image management device. Request parameters include the image name (field is imageName, or the image name can be replaced with one or more of the image number, image ID, image tag, etc.) and the first digest value (field is imageHash2). Of course, specific implementations may also include other request parameters, or some parameters not shown in API 701. For example, the request parameters may also include the container platform ID.

[0177] See Figure 7 In part (b), before launching the container based on the target image1, the container platform 103 returns a summary of the image1 to the image management device 101. Figure 7Taking the digest "931d9f58b642cd96f1fed1ecf6a0f8beda9d65bb" as an example (in specific implementations, it can be other digests), it is returned to the image management device 101 via message 702. Correspondingly, the image management device can obtain the first digest of the target image, match this digest with the digest obtained based on the signature file, and return message 703 to the container platform to indicate the matching result or to indicate whether it is allowed to start the container using the target image image1.

[0178] Understandably, if the signature file is obtained based on the hash value of the target image, then the information of the target image obtained after signature verification will be the hash value of the target image. However, for ease of description, this application refers to the information of the target image obtained after signature verification as the second digest, without intending to limit the second digest to a digital digest. Correspondingly, if the signature file is obtained based on the hash value of the target image, then the second digest of the target image returned by the container platform will also be the hash value of the target image, facilitating comparison.

[0179] exist Figure 4 In the described method, the image management device obtains the signer's information and the target image's information through a first terminal device. Based on these information, it can then obtain the target image's signature file. Since there is a mapping relationship between the target image's digest and its content, if the target image's content is tampered with, its digest will also change accordingly. Therefore, when a container platform uses the target image to start a container, if the first digest of the target image matches the second digest of the target image used to generate the signature file, it indicates that the target image's content has not been tampered with. This allows the container platform to be instructed to allow the use of the target image to start the container, thereby enabling control over the target image's security and integrity, ensuring the security of both the target image's content and the container platform.

[0180] In addition, signers only need to sign the image through the first terminal device, without having to generate key pairs, save keys, generate signature files, etc. on the local terminal. This improves the security of the image, reduces the operational complexity for signers, and enhances the user experience.

[0181] The above method embodiments can be executed before image development, during image push, and during image usage. Therefore, the above method embodiments can achieve tracking of the entire lifecycle of the image and can be coupled with the image building pipeline, adapting to current cloud-native development technologies.

[0182] Furthermore, it should be noted that the data link for sending and receiving information between the image management device and the first terminal device, the second terminal device, or the container platform can include various types of connection media, specifically wired links (such as fiber optic cables, twisted-pair cables, etc.), wireless links, or a combination of wired and wireless links. Examples include 802.11b / g, Bluetooth, Zigbee, Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), and Ultra Wideband (UWB) technologies. Of course, other technologies may also be used to support communication between the upgrade image management device and the first terminal device, the second terminal device, or the container platform.

[0183] above Figure 4 The method embodiments shown include many possible implementation schemes, which will be discussed in detail below. Figure 8 , Figure 9 and Figure 10 Some of the implementation schemes will be illustrated with examples. It should be noted that... Figure 8 , Figure 9 and Figure 10 For any unexplained related concepts, operations, or logical relationships, please refer to [link / reference]. Figure 4 The corresponding descriptions in the illustrated embodiments will not be repeated here.

[0184] See Figure 8 , Figure 8 This is a flowchart illustrating another image management method provided in this application embodiment. This method can be based on... Figure 1 The image management system shown is used to implement this, and the image management method includes at least the following steps:

[0185] Step S801: The management module of the mirror management device receives first information sent by the second terminal device through the first API. The first information includes the administrator's identity information and information setting application.

[0186] Specifically, an information setting request can include one or more of the following: control policies and signer authentication information. In practice, the information setting request can also be referred to as control information.

[0187] The control policy includes indication information for the target image and description information for the signer. The indication information for the target image and the description information for the signer can be found in the detailed description in step S401.

[0188] Specifically, the administrator's identity information may include one or more of the following: administrator ID, number, name, account, password, authentication information of the signer, and session authentication information.

[0189] Step S802: The authentication module in the mirror management device determines the administrator's identity based on the administrator's identity information and the administrator's authentication information.

[0190] Specifically, the management module can send the administrator's authentication information from the first message to the authentication module to authenticate the administrator's identity. The authentication module can then request the administrator's authentication information from the storage module based on the administrator's identity information. After receiving the administrator's authentication information returned by the storage module, the authentication module authenticates the administrator's identity based on the administrator's identity information and the authentication information.

[0191] In one design, the authentication module compares the administrator's identity information sent by the management module with the authentication information returned by the storage module. If they match, authentication is successful; otherwise, authentication fails. For example, if the administrator's identity information is "username: admin, password: adminpw", and the requested administrator's authentication information is also "username: admin, password: adminpw", then the administrator's authentication will succeed.

[0192] It should be noted that the description here is in plaintext for ease of understanding. In actual implementation, the authentication information returned by the storage module may be encrypted, or the information returned by the storage module may be a digest value of the authentication information. For example, the content returned by the storage module may be a digest of the authentication information. In this case, the authentication module generates a digest based on the administrator's identity information, and then compares the generated digest with the digest returned by the storage module to determine whether the identity authentication is successful.

[0193] Furthermore, the authentication module can return the authentication result to the management module. If authentication fails, the management module can return an authentication failure indication to the second terminal device (e.g., returning an operation failure message via API return value), allowing the second terminal device to resubmit for authentication. If authentication succeeds, the management module can process the information setting request submitted by the administrator.

[0194] Step S803: If the administrator's information setting application includes a control policy, the control module in the image management device sets the control policy for the target image.

[0195] Specifically, if the administrator's information configuration request includes a control policy, the control module can send the control policy to the control module. This control policy includes instructions for the target image and a description of the signer.

[0196] The control module designates the signer as the entity to sign the target image based on the target image's instruction information and the signer's description information. When a subsequent request is made to verify the target image, the module checks whether the target image contains the signer's signature file and whether the signature file is valid.

[0197] Furthermore, the control module can control the content of the control strategy in the storage module. The specific control operations can be adding, updating, or deleting control strategies.

[0198] Step S804: If the administrator's information setting application includes signer authentication information, the authentication module in the mirror management device stores the signer's authentication information.

[0199] Specifically, the management module sends the signer's authentication information to the authentication module. After receiving the signer's authentication information, the authentication module can store the signer's authentication information in the storage module.

[0200] In some implementation scenarios, the administrator's information setting application can also request the deletion of the signer's authentication information. In this case, the authentication module can request the storage module to delete the corresponding signer's authentication information.

[0201] Optional, Figure 8 The image management method shown may also include step S805, as follows:

[0202] Step S805: The key module in the mirror management device determines the signer's key.

[0203] Specifically, the authentication module will request the public and private key pair of the signer from the key module. The request may include the signer's authentication information (which may include all authentication information, such as account and password, or only some information, such as only account).

[0204] Furthermore, after receiving a request from the authentication module, the key module generates a public-private key pair based on the signer. After generating the key pair, the key module sends it to the storage module for safekeeping.

[0205] In some implementation scenarios, the administrator's information setting request can also request the deletion of the signer's corresponding key. In this case, the authentication module can request the key module to delete the signer's key. Then, the key module can delete the signer's corresponding key from the storage module.

[0206] See Figure 9 , Figure 9 This is a flowchart illustrating another mirror signature method provided in this application embodiment. This method can be based on... Figure 1 The image management system shown is used to implement this, and the image management method includes at least the following steps:

[0207] Step S901: The signature module of the image management device receives second information sent by the first terminal device through the second API. The second information includes the information of the signer and the information of the target image.

[0208] Specifically, the first terminal device requests a signature operation by calling the second API. The input parameters of this API can be included in the second information, specifically the information of the signer and the target image. The information of the signer and the target image can be found in the detailed description of step S402, and will not be repeated here.

[0209] In one possible implementation, the signer's information includes the signer's identity information, and the target image's information includes a summary of the target image. Optionally, the target image's information may also include one or more of the following: the target image's ID, name, etc.

[0210] Step S901: The authentication module of the mirror management device authenticates the signer's identity based on the signer's identity information and authentication information.

[0211] Specifically, after receiving the signer's authentication information, the signature module sends the signature authentication information to the authentication module, which then authenticates the signer's identity (for example, by verifying the authenticity of the signer's identity).

[0212] The authentication module can request the signer's authentication information from the storage module. Specifically, it can query the storage module for the signer's authentication information based on the signer's ID, account number, or other identifiers. The storage module returns the saved signature's authentication information to the authentication module. The authentication module then authenticates the signer's identity based on the signer's identity information and the signature information.

[0213] In one design, the authentication module compares the signer's identity information sent by the signing module with the signer's authentication information returned by the storage module. If they match, authentication is successful; otherwise, authentication fails. For example, if the signer's identity information is "username: signer1, password: passwprd1", and the requested administrator's authentication information is also "username: signer1, password: passwprd1", then the signer's authentication is successful.

[0214] It should be noted that the description here is in plaintext for ease of understanding. In actual implementation, the authentication information returned by the storage module may be encrypted, or the information returned by the storage module may be a digest value of the authentication information. For example, the content returned by the storage module may be an encrypted username and password. In this case, the authentication module requests the corresponding decryption key to decrypt the returned content, and then compares it with the identity information.

[0215] Furthermore, the authentication module can return the authentication result to the signature module. If authentication fails, the signature module can return an authentication failure indication to the first terminal device (e.g., returning a signature operation failure message via an API return value), which the first terminal device can then use to resubmit the authentication. If authentication is successful, subsequent signature operations can proceed.

[0216] Step S903: The signature module of the image management device generates a signature file based on the signer's key and the target image information.

[0217] Specifically, the signing module requests the signer's key from the key module, and the key module requests the stored signer's private key from the storage module. Correspondingly, the storage module returns the signer's private key to the key module, which then sends the private key to the signing module.

[0218] The signature module receives the signer's private key, uses the private key and the target image information to perform signature calculation, and obtains the image signature file.

[0219] Furthermore, the signing module sends the image signature file to the storage module for saving. Optionally, the signing module can return a successful signing indication message through the return value (or return parameter) of the second API.

[0220] See Figure 10 , Figure 10 This is a flowchart illustrating another mirror control method provided in this application embodiment. This method can be based on... Figure 1 The image management system shown is used to implement this, and the image management method includes at least the following steps:

[0221] Step S1001: The control module of the image management device receives third information sent by the container platform through a third API. This third information includes information about the target image and may further include a first digest. The target image information may include the target image's identifier, number, ID, etc.

[0222] Specifically, the container platform uses image signing control functionality by calling a third-party API. The input parameters for this API can be included in third-party information, which may include information about the target image that the container platform can launch (including one or more of the image name, tag, hash value, and cluster information for which the image needs to be launched). This third-party information can also be referred to as request information.

[0223] Understandably, if the first digest is not included in the third information, the container platform can send the first digest of the target image through other information.

[0224] Step S1002: The control module of the image management device determines the signature file of the target image according to the control strategy of the target image.

[0225] Specifically, after receiving the third-party information (or request information), the control module requests the control policy of the target image from the storage module. Correspondingly, the storage module returns the control policy of the target image to the control module. The control module then requests the signature file of the target image from the signing module.

[0226] Understandably, the control policy includes the signer's description information, so the signer's signature file is required when starting the image.

[0227] Step S1003: The signature module of the mirror management device obtains a second digest based on the signature file and the signer's key.

[0228] Specifically, the signing module requests the signature file of the target image from the storage module, and the storage module returns the signature file of the target image to the signing module. Understandably, when signature files from multiple signers exist, the storage module returns signature files corresponding to each signer.

[0229] Furthermore, the signing module requests the signer's public key from the key module, which in turn requests the signer's public key stored in the storage module. Correspondingly, the storage module returns the signer's public key to the key module, which then returns the signer's public key back to the signing module.

[0230] The signing module calculates a second digest of the target image based on the signing file and the signer's public key, and returns the second digest to the control module.

[0231] In one possible design, the signature file is generated based on the hash value of the target image and the signer's information (such as the signer's account, ID, etc., one or more of these). The signature module can design the signature file using the signer's public key to obtain a second digest of the target image and the signer's information. Furthermore, the signature module can compare the designed signer's information with the information of the specified signer for that image to determine whether the signature file has been tampered with.

[0232] Step S1004: The control module of the image management device compares the second digest with the container platform and returns the first digest.

[0233] Specifically, the control module calculates and compares the second digest and the first digest returned by the container platform to verify the integrity of the image content. If the results obtained from the calculation of the second digest and the first digest are consistent, it indicates that the target image has not been tampered with, and an indication message allowing the use of the target image to start the container is returned to the container platform. If they are inconsistent, it indicates that the target image has been tampered with, and a prompt message indicating that the image has been tampered with is sent to the container platform or an indication message refusing to use the target image to start the image is sent.

[0234] Furthermore, if the signature file returned by the signature module received by the control module is missing one or more signature files from the signer, it indicates that the signature of the target image is incomplete. In this case, the image management device can send a message to the container platform indicating that the signature file is incomplete or send a message indicating that the target image should not be used to start the image.

[0235] In some possible designs, the operation shown in step S1004 can also be performed by the signing module. Specifically, the signing module calculates and compares the first digest returned by the container platform, the signer's public key, and the image signing file to verify the integrity of the image content and obtain a verification result (indicating whether the verification passed or failed). The signing module then returns the signing file and the corresponding verification result to the control module. The control module checks whether it has the signing files of all signers and the verification results of the signer files. If the signing file is complete and the verification results of all signing files indicate that the verification passed, it instructs the container platform to allow the container to be started using the target image.

[0236] The methods of the embodiments of this application have been described in detail above, and the apparatus of the embodiments of this application is provided below.

[0237] Please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a mirror management device 110 provided in an embodiment of this application. The mirror management device 110 can be... Figure 4 The image management device in the illustrated embodiment can also be a module within an image management device, such as a chip or integrated circuit. This image management device 110 is used to implement the aforementioned image management method, such as... Figure 4 , Figure 8 , Figure 9 , Figure 10 The image management method described in any of the embodiments.

[0238] Furthermore, the mirror management device 110 may include a receiving unit 1101 and a processing unit 1102. Optionally, it may also include a sending unit 1103. The detailed descriptions of each unit are as follows:

[0239] The receiving unit 1101 is used to receive information about the signer and the target image sent by the first terminal device; the signer is the object designated to sign the target image;

[0240] Processing unit 1102 is used to obtain a signature file based on the information of the signer and the information of the target image;

[0241] The processing unit 1102 is configured to instruct the container platform to allow the launch of a container using the target image if the first digest of the target image returned by the container platform matches the second digest obtained based on the signature file.

[0242] In the above embodiments, the image management device 110 obtains the signer's information and the target image's information through the first terminal device, and can then obtain the target image's signature file based on the signer's information and the target image's information. Since there is a mapping relationship between the target image's digest and its content, if the target image's content is tampered with, the target image's digest will also change accordingly. Therefore, when the container platform uses the target image to start a container, if the first digest of the target image matches the second digest of the target image used to generate the signature file, it indicates that the target image's content has not been tampered with. Thus, the image management device 110 can instruct the container platform to allow the use of the target image to start the container, thereby enabling control over the security and integrity of the target image, ensuring the security of the target image's content and the container platform.

[0243] In addition, signers only need to sign the image through the first terminal device, without having to generate key pairs, save keys, generate signature files, etc. on the local terminal. This improves the security of the image, reduces the operational complexity for signers, and enhances the user experience.

[0244] The aforementioned image management device 110 can manage target images during image development, image push, and image usage. Therefore, the above method embodiment can track the entire lifecycle of an image and can be coupled with the image building pipeline, adapting to current cloud-native development technologies.

[0245] In one possible implementation, the receiving unit 1101 is further configured to:

[0246] The system receives indication information of the target image and description information of the signer sent by the second terminal device, wherein the description information of the signer is used to indicate the signer who signs the target image.

[0247] As can be seen, the second terminal device can indicate which signers are required to sign the target image. In one possible design, the administrator inputs the image control policy through the second terminal device. This control policy includes the aforementioned target image indication information and the signer description information. This control policy is used to control the target image. It can be seen that the administrator only needs to input the control policy to control the image, improving the user experience. Especially when there are multiple images to manage (e.g., the management of developed images by an enterprise or organization), it can decouple the image development team, image management team, and image signers, improving the user experience.

[0248] In another possible implementation, the indication information of the target image includes the identity of the target image and / or the identification information of the container cluster used to run the target image.

[0249] As can be seen, through the embodiments of this application, not only can the control function of a single image be realized, but also the control of multiple images that need to run in a container cluster can be realized, thereby realizing image control functions of various granularities and meeting the user's control needs for a single image, multiple images, and images that need to run in a container cluster.

[0250] In another possible implementation, the signer's information includes the signer's identity information; the processing unit 1102 is further configured to:

[0251] The identity of the at least one signer is confirmed to be verified based on the identity information.

[0252] The above describes how the image management device 110 can authenticate the identity of the signer, thus preventing untrusted signers from signing the file and improving the security of the image.

[0253] In another possible implementation, the receiving unit 1101 is further configured to receive the authentication information of the signer sent by the second terminal device;

[0254] The processing unit 1102 is further configured to determine that the signer's identity verification is successful based on the signer's authentication information and identity information.

[0255] The above provides a method for authenticating the identity of a signer. (An administrator or automated management program, etc.) can set the authentication information of the signer through a second terminal device. When the first terminal device uploads the identity information of the signer, the mirror management device 110 can compare the identity information with the authentication information. If the comparison is consistent, it means that the identity of the signer is trustworthy.

[0256] In another possible implementation, the device supports information transmission with the second terminal device, the first terminal device, and the container platform via an application programming interface (API).

[0257] The above describes the communication method. The image management device 110 can connect with the second terminal device, the first terminal device, and the container platform through the API interface. The above devices can realize image management, image signing, image startup control, and other functions simply by calling the relevant functions through the API interface, which reduces the difficulty of user operation.

[0258] In another possible implementation, the processing unit 1102 is further configured to generate a key pair corresponding to the signer, the key pair including a public key and a private key.

[0259] The above describes how the image management device 110 can generate key pairs during the image management process. These key pairs can be used in signing, authentication, and startup control. Furthermore, these key pairs can be stored in the image management device 110, eliminating the need for users to store public and private keys locally and preventing key leakage.

[0260] In another possible implementation, the information of the target image includes the hash value of the target image; the information of the signer corresponds to the private key of the signer; the processing unit 1102 is specifically used to generate the signature file using the private key of the signer and the hash value of the target image.

[0261] The above describes how the image management device 110 generates a signature file. The image information includes the image's hash value. A signature file can be generated using the signer's private key and the image's hash value. Because there is a mapping relationship between the image content and the image's hash value, if the image content is tampered with, the image digest will also change accordingly. Therefore, the image hash value can be used to identify whether the image content has been tampered with.

[0262] In another possible implementation, the receiving unit 1101 is further configured to receive a request message sent by the container platform, the request message being used to request the use of the target image to start a container on the container platform. Further, the request message includes the first digest.

[0263] Specifically, the container platform can include the target image's indication information in the request message and invoke the image's startup control via an API interface. In this way, when the container platform starts a container, it provides the image management device 110 with a summary of the target image. The device can then determine the image's safety based on the feedback indication information, eliminating the need to adjust the container platform's image inspection function and enabling rapid compatibility with container platforms from multiple service providers.

[0264] In another possible implementation, the processing unit 1102 is further configured to add the signer's authentication information to the signer database based on the signer's authentication information.

[0265] In another possible implementation, the signer includes a first signer and a second signer; the first terminal device includes a first sub-device and a second sub-device, wherein the first sub-device is the device used by the first signer; and the second sub-device is the device used by the second signer.

[0266] Through the embodiments in this application, multiple signers can upload information for signing through one or more devices respectively, thereby obtaining signature files and realizing a multi-signature mechanism.

[0267] In another possible implementation, the sending unit 1103 is used to send information to the first terminal device, the second terminal device, and the container platform. For example, the sending unit can send indication information to the container platform to indicate whether it is allowed to start the target container using the target image.

[0268] It is understood that in the various device embodiments of this application, the division of multiple units or modules is only a logical division based on function and is not intended to limit the specific structure of the device. In specific implementations, some functional modules may be subdivided into more smaller functional modules, and some functional modules may be combined into a single functional module. However, regardless of whether these functional modules are subdivided or combined, the general process executed during image management is the same. For example, the receiving unit 1101 and the transmitting unit 1103 in the aforementioned device 110 can also be collectively referred to as a communication unit. Typically, each unit corresponds to its own program code (or program instructions). When the program code corresponding to each unit runs on the processor, it causes the unit to be controlled by the processing unit to execute the corresponding process and thus achieve the corresponding function.

[0269] Please see Figure 12 , Figure 12The application embodiment provides a schematic diagram of the structure of a mirror management device 120. The mirror management device 120 may include at least one memory 1201, at least one processor 1202, and a communication interface 1204. Optionally, it may also include a bus 1203, wherein the memory 1201, processor 1202, and communication interface 1204 are connected via the bus 1203.

[0270] The memory 1201 provides storage space, which can store data such as the operating system and computer instructions. The memory 1201 can be one or a combination of several of the following: random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM).

[0271] Processor 1202 is a module that performs arithmetic and / or logical operations. Specifically, it can be one or a combination of processing modules such as central processing unit (CPU), graphics processing unit (GPU), microprocessor unit (MPU), application specific integrated circuit (ASIC), field programmable gate array (FPGA), and complex programmable logic device (CPLD).

[0272] The communication interface 1204 is used to receive and / or transmit data to external sources. It can be a wired link interface, such as an Ethernet cable, or a wireless link interface (Wi-Fi, Bluetooth, general wireless transmission, vehicle short-range communication technology, etc.). Optionally, the communication interface 1204 may also include a transmitter (such as a radio frequency transmitter, antenna, etc.) or a receiver coupled to the interface.

[0273] The processor 1202 in the image management device 120 is used to read computer instructions stored in the memory 1201 and to execute the aforementioned image management method, such as... Figure 4 , Figure 8 , Figure 9 , Figure 10 The image management method described in any of the embodiments.

[0274] For example, the mirror management device 120 can provide... Figure 4 , Figure 8 , Figure 9 , Figure 10 In any embodiment of the image management device, the processor 1202 in the image management device 120 is used to read computer instructions stored in the memory 1201 and to perform the following operations:

[0275] The signer's information and the target image information are sent through the terminal device via communication interface 1204; the signer is the object designated to sign the target image.

[0276] A signature file is obtained based on the signer's information and the target image's information;

[0277] If the first digest of the target image returned by the container platform matches the second digest obtained based on the signature file, the container platform is instructed to allow the container to be started using the target image.

[0278] In the above embodiments, the image management device 120 obtains the signer's information and the target image's information through the first terminal device, and can then obtain the target image's signature file based on the signer's information and the target image's information. Since there is a mapping relationship between the target image's digest and its content, if the target image's content is tampered with, the target image's digest will also change accordingly. Therefore, when the container platform uses the target image to start a container, if the first digest of the target image matches the second digest of the target image used to generate the signature file, it indicates that the target image's content has not been tampered with. Thus, the image management device 120 can instruct the container platform to allow the use of the target image to start the container, thereby enabling control over the security and integrity of the target image, ensuring the security of the target image's content and the container platform.

[0279] In addition, signers only need to sign the image through the first terminal device, without having to generate key pairs, save keys, generate signature files, etc. on the local terminal. This improves the security of the image, reduces the operational complexity for signers, and enhances the user experience.

[0280] The aforementioned image management device 120 can manage target images during image development, image push, and image usage. Therefore, the above method embodiment can track the entire lifecycle of an image and can be coupled with the image building pipeline, adapting to current cloud-native development technologies.

[0281] In yet another possible implementation, the processor 1202 is further configured to:

[0282] The system receives the indication information of the target image and the description information of the signer sent by the second terminal device through the communication interface 1204, wherein the description information of the signer is used to indicate the signer who signed the target image.

[0283] As can be seen, the second terminal device can indicate which signers are required to sign the target image. In one possible design, the administrator inputs the image control policy through the second terminal device. This control policy includes the aforementioned target image indication information and the signer description information. This control policy is used to control the target image. It can be seen that the administrator only needs to input the control policy to control the image, improving the user experience. Especially when there are multiple images to manage (e.g., the management of developed images by an enterprise or organization), it can decouple the image development team, image management team, and image signers, improving the user experience.

[0284] In another possible implementation, the indication information of the target image includes the identity of the target image and / or the identification information of the container cluster used to run the target image.

[0285] The above describes how the image management device 120 can authenticate the identity of the signer, thus preventing untrusted signers from signing the file and improving the security of the image.

[0286] In yet another possible implementation, the signer's information includes the signer's identity information; the processor 1202 is further configured to:

[0287] The identity of the at least one signer is confirmed to be verified based on the identity information.

[0288] In yet another possible implementation, the processor 1202 is further configured to:

[0289] The authentication information of the signer sent by the second terminal device is received through the communication interface 1204;

[0290] Based on the signer's authentication information and identity information, it is determined that the signer's identity verification is successful.

[0291] The above provides a method for authenticating the identity of a signer. (An administrator or automated management program, etc.) can set the authentication information of the signer through a second terminal device. When the first terminal device uploads the identity information of the signer, the mirror management device 120 can compare the identity information with the authentication information. If the comparison is consistent, it means that the identity of the signer is trustworthy.

[0292] In another possible implementation, the device supports information transmission with the second terminal device, the first terminal device, and the container platform via an application programming interface (API).

[0293] The above describes the communication method. The image management device 120 can connect with the second terminal device, the first terminal device, and the container platform through the API interface. The above devices can realize image management, image signing, image startup control, and other functions simply by calling the relevant functions through the API interface, which reduces the difficulty of user operation.

[0294] In another possible implementation, the processor 1202 is also configured to generate a key pair corresponding to the signer, the key pair including a public key and a private key.

[0295] The above describes how the image management device 120 can generate key pairs during the image management process. These key pairs can be used in signing, authentication, and startup control. Furthermore, these key pairs can be stored in the image management device 110, eliminating the need for users to store public and private keys locally and preventing key leakage.

[0296] In another possible implementation, the information of the target image includes the hash value of the target image; the information of the signer corresponds to the private key of the signer; the processor 1202 is specifically used to generate the signature file using the private key of the signer and the hash value of the target image.

[0297] The above describes how the image management device 120 generates a signature file. The image information includes the image's hash value. A signature file can be generated using the signer's private key and the image's hash value. Because there is a mapping relationship between the image content and the image's hash value, if the image content is tampered with, the image digest will also change accordingly. Therefore, the image hash value can be used to identify whether the image content has been tampered with.

[0298] In another possible implementation, the processor 1202 is further configured to receive a request message sent by the container platform via the communication interface 1204, the request message being used to request the use of the target image to start a container on the container platform. Further, the request message includes the first digest.

[0299] Specifically, the container platform can include the target image's indication information in the request message and invoke the image's startup control via an API interface. In this way, when the container platform starts a container, it provides the image management device 120 with a summary of the target image. The device can then determine the image's safety based on the feedback indication information, eliminating the need to adjust the container platform's image inspection function and enabling rapid compatibility with container platforms from multiple service providers.

[0300] In another possible implementation, the processor 1202 is further configured to add the signer's authentication information to the signer database based on the signer's authentication information.

[0301] In another possible implementation, the signer includes a first signer and a second signer; the first terminal device includes a first sub-device and a second sub-device, wherein the first sub-device is the device used by the first signer; and the second sub-device is the device used by the second signer.

[0302] Through the embodiments in this application, multiple signers can upload information for signing through one or more devices respectively, thereby obtaining signature files and realizing a multi-signature mechanism.

[0303] This application also provides a server, which includes a processor and a memory; wherein the processor is used to execute computer instructions stored in the memory, causing the server to implement... Figure 4 , Figure 8 , Figure 9 or Figure 10 The image management method described in any of the embodiments shown.

[0304] This application also provides a computer-readable storage medium storing computer instructions that, when executed on one or more processors, implement... Figure 4 , Figure 8 , Figure 9 or Figure 10 The image management method described in any of the embodiments shown.

[0305] This application embodiment also provides a chip system including at least one processor, a memory, and an interface circuit. The interface circuit is used to provide information input / output to the at least one processor. The at least one memory stores computer instructions, which, when executed on one or more processors, implement... Figure 4 , Figure 8 , Figure 9 or Figure 10 The image management method described in any of the embodiments shown.

[0306] This application also provides a computer program product that, when run on one or more processors, implements... Figure 4 , Figure 8 , Figure 9 or Figure 10 The image management method described in any of the embodiments shown.

[0307] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented entirely or partially in the form of a computer instruction product. This computer instruction product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application can be implemented entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0308] The steps in the method embodiments of this application can be adjusted, combined, or deleted according to actual needs.

[0309] The modules in the device embodiments of this application can be merged, divided, and deleted according to actual needs.

Claims

1. A mirror management method, characterized in that, Applied to an image management device, the image management device supports information transmission with a second terminal device, at least one first terminal device, and a container platform via an application programming interface (API), the method includes: The system receives a control policy sent by a second terminal device via a first API. The control policy includes indication information of the target image and description information of the signer, wherein the signer is at least one object designated to sign the target image. The system receives the signer's information and the target image information sent by the at least one first terminal device via the second API. A signature file is obtained based on the signer's information and the target image's information, and stored in the storage module of the image management device; The system receives a request message from the container platform via a third API. The request message is used to request the use of the target image to start a container on the container platform. The request message includes a first digest of the target image. The signature file of the target image is determined according to the control strategy; A second digest is obtained based on the signature file of the target image and the key of the signer; If the first digest matches the second digest, the container platform is instructed to allow the container to be started using the target image.

2. The method according to claim 1, characterized in that, The indication information of the target image includes the identity of the target image and / or the identification information of the container cluster used to run the target image.

3. The method according to claim 1 or 2, characterized in that, The signer's information includes the signer's identity information; the method further includes: The identity of the at least one signer is confirmed to be verified based on the identity information.

4. The method according to claim 3, characterized in that, The step of determining that the identity information of the at least one signer has been authenticated based on the identity information includes: Receive the authentication information of the signer sent by the second terminal device; Based on the signer's authentication information and identity information, it is determined that the signer's identity verification is successful.

5. The method according to claim 4, characterized in that, After receiving the description information of at least one signer sent by the second terminal device, the method further includes: Generate a key pair corresponding to the signer, the key pair including a public key and a private key.

6. The method according to claim 5, characterized in that, The information of the target image includes the hash value of the target image; The signer's information corresponds to the signer's private key; The process of obtaining a signature file based on the signer's information and the target image's information includes: The signature file is generated using the signer's private key and the hash value of the target image.

7. The method according to claim 6, characterized in that, The method further includes: Based on the signer's authentication information, the signer's authentication information is added to the signer database.

8. A mirror management device, characterized in that, The image management device supports information transmission with a second terminal device, at least one first terminal device, and a container platform via an application programming interface (API), including: The receiving unit is used for: The system receives a control policy sent by a second terminal device via a first API. The control policy includes indication information of the target image and description information of the signer, wherein the signer is at least one object designated to sign the target image. The system receives the signer's information and the target image information sent by the at least one first terminal device via the second API. The processing unit is used to obtain a signature file based on the information of the signer and the information of the target image, and store it in the storage module of the image management device; The processing unit is configured to receive a request message sent by the container platform via a third API. The request message is used to request the use of the target image to start a container on the container platform. The request message includes a first digest of the target image. The processing unit is used to determine the signature file of the target image according to the control strategy; The processing unit is configured to obtain a second digest based on the signature file of the target image and the key of the signer; The processing unit is configured to instruct the container platform to allow the container to be started using the target image if the first digest matches the second digest.

9. The apparatus according to claim 8, characterized in that, The indication information of the target image includes the identity of the target image and / or the identification information of the container cluster used to run the target image.

10. The apparatus according to claim 8 or 9, characterized in that, The signer's information includes the signer's identity information; the processing unit is further configured to: The identity of the at least one signer is confirmed to be verified based on the identity information.

11. The apparatus according to claim 10, characterized in that, The receiving unit is further configured to receive the authentication information of the signer sent by the second terminal device; The processing unit is further configured to determine that the signer's identity verification is successful based on the signer's authentication information and identity information.

12. The apparatus according to claim 11, characterized in that, The processing unit is also configured to generate a key pair corresponding to the signer, the key pair including a public key and a private key.

13. The apparatus according to claim 12, characterized in that, The target image information includes the hash value of the target image; the signer information corresponds to the signer's private key; the processing unit is specifically used to generate the signature file using the signer's private key and the hash value of the target image.

14. The apparatus according to claim 13, characterized in that, The processing unit is further configured to add the signer's authentication information to the signer database based on the signer's authentication information.

15. A mirror management device, characterized in that, The image management device includes a processor and a memory; the processor is configured to execute computer instructions stored in the memory, causing the image management device to implement the method as described in any one of claims 1-7.

16. A mirror management system, characterized in that, The mirror management system includes a mirror management device, a first terminal device, and a second terminal device; wherein the mirror management device is the mirror management device according to any one of claims 8-14, or the mirror management device according to claim 15.

17. A mirror management system, characterized in that, The image management system includes an image management device, a first terminal device, a second terminal device, and a container platform; wherein the image management device is the image management device according to any one of claims 8-14, or the image management device according to claim 15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for implementing the method of any one of claims 1-7.

Images