Container operation environment credible control method and device, equipment and medium

Abstract

The invention relates to a trusted control method and device for a container operation environment, equipment and a medium, and belongs to the technical field of computer security. A lightweight virtual machine is created on a host, a virtual trusted platform module is integrated in the lightweight virtual machine, a trusted startup process is executed in a startup process, and a trusted measurement result is calculated; submitting a trusted measurement result to a remote attestation server so as to verify the trusted state of the lightweight virtual machine; after the verification is passed, receiving an authorization response issued by the remote certification server; requesting to download the target encryption container mirror image from the container mirror image warehouse by using the download token, and downloading the target encryption container mirror image after the verification is passed; and decrypting the target encryption container mirror image by using the decryption key, and loading the decrypted target encryption container mirror image to the container operation environment to start the corresponding target container. A trusted closed loop is formed, and it is ensured that the container operation environment has safety and credibility in the initialization stage.

Description

Technical Field

[0001] The present application belongs to the field of computer security technology, and specifically relates to a trusted control method, apparatus, device, and medium for a container operating environment. Background Art

[0002] Container technology is a virtualization technology that packages applications and their dependencies into a standardized unit called a container. The primary advantage of container technology is that it provides a consistent operating environment, allowing applications to run regardless of the environment. With the development of cloud computing and container technology, containers have become a key form of modern application deployment due to their lightweight, fast deployment, and elastic scalability.

[0003] However, since containers usually run on a shared host kernel, their security isolation capabilities are weaker than those of virtual machines. Especially during the container initialization phase, before permission isolation and resource control are completed, they can easily become an entry point for attackers to invade.

[0004] Therefore, how to ensure the security and reliability of the container operating environment during the initialization phase has become an important issue in ensuring the security of cloud-native platforms. Summary of the Invention

[0005] In view of the above analysis, embodiments of the present invention aim to provide a trusted control method, apparatus, device, and medium for a container operating environment to ensure that the container operating environment is secure and trustworthy during the initialization phase.

[0006] In a first aspect of the present application, a trusted control method for a container runtime environment is provided. A lightweight virtual machine is created on a host, and a virtual trusted platform module is integrated into the lightweight virtual machine. The method includes: During the startup of the lightweight virtual machine, a trusted startup process is executed and a trusted measurement result is calculated; The lightweight virtual machine submits the trust measurement result to the remote attestation server, so that the remote attestation server verifies the trust status of the lightweight virtual machine based on the trust measurement result; and after the verification is successful, the lightweight virtual machine receives an authorization response from the remote attestation server, the authorization response including the image download token and the decryption key; The lightweight virtual machine uses the download token to request downloading of the target encrypted container image from the container image repository, and downloads the target encrypted container image after verification by the container image repository; The lightweight virtual machine uses the decryption key to decrypt the target encrypted container image, and loads it into the container runtime environment to start the corresponding target container.

[0007] Optionally, the remote attestation server verifies the trustworthy state of the lightweight virtual machine based on the trustworthy measurement result, including: After receiving the trust measurement result submitted by the lightweight virtual machine, the remote attestation server parses the EK public key of the virtual trusted platform module; Verify whether the corresponding EK certificate is issued by the host certificate on which the virtual trusted platform module is deployed; The trust status of the lightweight virtual machine is determined based on a preset authentication trust chain formed between the host certificate and the root certificate issuance service.

[0008] Optionally, the process of building the preset authentication trust chain includes: On the server with the physical trusted platform module deployed, generate a key pair for issuing certificates and deploy a root certificate issuance service as the trusted root of the cluster trust chain. Each host deployed with a virtual trusted platform module submits a certificate issuance request to the root certificate issuance service and obtains a host certificate issued by the root certificate issuance service as an intermediate node of the trust chain; The host generates an EK public key during the initialization of the virtual trusted platform module, and signs the EK public key using the private key corresponding to the host certificate to form an EK certificate for identity authentication, thereby building a three-layer trust chain structure.

[0009] Optionally, creating a lightweight virtual machine on the host includes: The host calls the virtual trusted platform module to generate a virtual trusted platform module instance, wherein the virtual trusted platform module instance includes an identity key pair with an EK public key; Signing the EK public key based on the host certificate of the host to form an EK certificate; Injecting the generated virtual trusted platform module instance and the EK certificate as parameters into the virtualization engine QEMU, so that the virtualization engine QEMU creates a sandbox lightweight virtual machine integrating the virtual trusted platform module based on the parameters and returns the corresponding virtual machine identifier; The virtual machine identifier is associated and bound with the corresponding container identifier and stored in the data storage area for subsequent container operation status management.

[0010] Optionally, the process of generating the target encrypted container image includes: The image encryption module sends the image identifier and encryption algorithm information to the key management service to request image encryption processing; The key management service applies for an image upload token from the container image repository according to the image identifier and generates a corresponding encryption key; The key management service returns the image upload token and the encryption key to the image encryption module; The image encryption module encrypts the container image using the encryption key, and uploads the encrypted container image to the container image repository using the image upload token.

[0011] Optionally, executing a trusted boot process during the startup of the lightweight virtual machine and calculating a trusted measurement result includes: Based on the virtual trusted platform module, a layer-by-layer hash measurement is performed on the file set in the file system to calculate the corresponding hash value; Expanding the hash values ​​into hash extension results in sequence, and storing the results in a platform configuration register of a virtual trusted platform module; The measurement agent module in the lightweight virtual machine is called to access the platform configuration register, and to extract and generate a trusted measurement result for use in remote attestation.

[0012] Optionally, after loading into the container runtime environment and starting the target container, the method further includes: Activate the built-in continuous measurement task module in the lightweight virtual machine, perform continuous measurement on the file collection based on the integrity measurement architecture subsystem, and generate a file integrity measurement log; Periodically sending the file integrity measurement log to a remote attestation server so that the remote attestation server can compare the hash value of each file therein with a reference hash value generated when building the container image to determine the runtime integrity status; When an abnormal change in a file is detected, the remote attestation server reports the abnormal event to the policy management server so that the policy management server can determine the risk level according to the preset security policy and send a control instruction to the container orchestration system to trigger the corresponding container destruction or restart operation when the risk level meets the preset condition.

[0013] In a second aspect of the present application, a trusted control device for a container runtime environment is provided, which is deployed on a host and includes: A lightweight virtual machine creation module, configured to create a lightweight virtual machine on the host and integrate a virtual trusted platform module into the lightweight virtual machine; A trusted boot module, configured to execute a trusted boot process during the startup of the lightweight virtual machine and calculate a trusted measurement result; A remote attestation interaction module is configured to submit a trust measurement result to a remote attestation server so that the remote attestation server verifies the trust status of the lightweight virtual machine based on the trust measurement result; and after the verification is successful, the lightweight virtual machine receives an authorization response from the remote attestation server, the authorization response including an image download token and a decryption key; An image download module, configured to use the download token to request download of a target encrypted container image from a container image repository, and download the target encrypted container image after verification by the container image repository; The image decryption and startup module is used to decrypt the target encrypted container image using the decryption key, and load it into the container runtime environment to start the corresponding target container.

[0014] In a third aspect of the present application, a trusted control device for a container operating environment is provided, comprising a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the trusted control method for the container operating environment according to any one of the above-described methods is implemented.

[0015] In a fourth aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the trusted control method of the container operating environment according to any of the above-mentioned methods is implemented.

[0016] The trusted control method, device, equipment and medium of the container operating environment provided in this application execute the trusted startup process during the startup of the lightweight virtual machine and calculate the trusted measurement results to ensure that the container operating environment has not been tampered with, fundamentally improve the credibility of the initialization stage, and effectively prevent malicious tampering and other attacks. Through the mechanism of submitting trusted measurement results to the remote certification server, a centralized and verifiable certification of the security status of each container instance is achieved. In addition, the image download token and decryption key are issued only after the remote certification server has passed the verification, ensuring that access to sensitive resources is allowed only in a trusted environment, avoiding image leakage or use by unauthorized devices. From the trusted startup of the virtual machine to the security measurement, and further authorization verification, and then the image encryption download, and finally decryption startup, a trusted closed loop is formed to ensure that the container operating environment is secure and trustworthy during the initialization stage. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this specification. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0018] Figure 1 A flow chart of the method for constructing a three-tier authentication trust chain provided in this embodiment; Figure 2 Schematic diagram of the process of establishing a trusted trust chain; Figure 3A flowchart of a trusted control method for a container operating environment provided in this embodiment; Figure 4 Flowchart of the process for generating a target encrypted container image; Figure 5 Schematic diagram of the process of generating a container image for target encryption; Figure 6 This is a diagram of the image decryption process; Figure 7 This is a diagram of the container startup process; Figure 8 A schematic diagram of the process of executing the trusted boot process and calculating the trust measurement results during the startup of a lightweight virtual machine; Figure 9 A flowchart of another method for trusting a container runtime environment provided by this embodiment; Figure 10 Diagram of the message chain used to handle security exceptions during continuous measurement; Figure 11 This is a structural block diagram of the trusted control device for the container operating environment provided by this application; Figure 12 This is a structural block diagram of the trusted control device for the container runtime environment provided by this application. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all of the embodiments. It should be noted that, in the absence of conflict, the embodiments in this disclosure and the features in the embodiments can be combined, separated, interchanged and / or rearranged with each other. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0020] The terms used herein are for the purpose of describing specific embodiments and are not intended to be restrictive. As used herein, unless the context clearly indicates otherwise, the singular forms "one (kind, person)" and "said (the)" are also intended to include plural forms. In addition, when the terms "comprise" and / or "include" and their variations are used in this specification, the features, integral bodies, steps, operations, parts, assemblies and / or their groups stated are explained, but the presence or addition of one or more other features, integral bodies, steps, operations, parts, assemblies and / or their groups is not excluded. It should also be noted that, as used herein, the terms "substantially", "approximately" and other similar terms are used as approximate terms and not as degree terms, so that they are used to explain the inherent deviations of the measured values, calculated values ​​and / or the values ​​provided that will be recognized by those of ordinary skill in the art.

[0021] In order to achieve trusted control of the container operating environment, it is necessary to build a complete trust chain structure from the physical host to the virtual trusted platform module (vTPM). To this end, this embodiment provides a three-layer authentication trust chain construction method, the flow chart of which is as follows: Figure 1 As shown, the specific steps include: S101: On a server where a physical trusted platform module is deployed, a key pair for issuing a certificate is generated, and a root certificate issuance service is deployed as a trusted root of the cluster trust chain.

[0022] First, a key pair (public key and private key) for certificate issuance is generated on a physical server with a physical Trusted Platform Module (TPM) deployed. Based on this key pair, a root certificate authority (Root CA) is deployed as the root node of the entire trust chain.

[0023] The Root CA is used to issue trusted certificates for each host in the cluster, establish the starting point of the trusted chain, and ensure the security and tamper-proof capabilities of the CA private key through its own TPM.

[0024] S102: Each host deployed with a virtual trusted platform module submits a certificate issuance request to the root certificate issuance service, and obtains a host certificate issued by the root certificate issuance service as an intermediate node of the trust chain.

[0025] Then, a virtual trusted platform module (such as swTPM or ibmTPM) is deployed on each host in the cluster used to host the container runtime environment.

[0026] Each host communicates with the Root CA and submits a certificate signing request (CSR) containing the host identity information and public key. After the Root CA reviews the request, it issues a host certificate (HostCertificate) based on its own CA private key to identify the host's trusted identity, thus forming an intermediate node in the trust chain.

[0027] It is understandable that the host certificate issuance process follows the standard X.509 PKI protocol to ensure that the identity of each host can be verified and the source of the certificate is trustworthy.

[0028] S103: The host generates an EK public key during the initialization of the virtual trusted platform module, and signs the EK public key using the private key corresponding to the host certificate to form an EK certificate for identity authentication, thereby building a three-layer trust chain structure.

[0029] Subsequently, when the host initializes the virtual trusted platform module, the module generates its own Endorsement Key (EK) public key.

[0030] The host uses its own certificate issuance private key (the private key corresponding to the Host Certificate) to sign the EK public key, generating an EK Certificate with the host's signature. This certificate binds the virtual trusted module and the host's identity information and is used as an identity identifier in the virtual trusted module.

[0031] Figure 2 The figure shows a schematic diagram of the trusted chain establishment process. A root certificate issuance service (Root CA) is deployed on a server equipped with a TPM chip to establish the trusted root of the trusted chain. A host certificate is requested from the Root CA on each host equipped with a virtual trusted platform module, forming a secondary diffusion of the trusted chain. The swTPM software is deployed on the host that has requested the host certificate and uses the newly requested host certificate to issue an EK certificate, replacing the EK certificate of the vTPM created by the swTPM on the host. When the Kata runtime uses QEMU to create a virtual machine, the vTPM is passed as a parameter to QEMU, making it the built-in TPM chip of the virtual machine created by QEMU. The vTPM's built-in EK certificate is then utilized, forming a tertiary diffusion of the trusted chain.

[0032] This trust chain can be fully verified in scenarios such as remote attestation and container image distribution control, ensuring that each layer from physical hardware to container runtime has a verifiable trust foundation, thereby effectively preventing containers from running in untrusted environments.

[0033] In order to better understand the trusted control method of the container operating environment provided by this application, Figure 3 , the specific implementation of this method is described in detail. Figure 3 As shown, this embodiment provides a trusted control method for a container operating environment, the method comprising the following steps: S301: Create a lightweight virtual machine on a host, and integrate a virtual trusted platform module into the lightweight virtual machine.

[0034] The process may specifically include: the host calling the virtual trusted platform module to generate a virtual trusted platform module instance, wherein the virtual trusted platform module instance includes an identity key pair with an EK public key; signing the EK public key based on the host certificate of the host to form an EK certificate for subsequent trusted identity authentication.

[0035] Afterwards, the generated virtual trusted platform module instance and the EK certificate are injected into the virtualization engine QEMU as parameters, so that the virtualization engine QEMU creates a sandbox lightweight virtual machine integrating the virtual trusted platform module based on the parameters and returns the corresponding virtual machine identifier.

[0036] The virtual machine identifier is associated and bound with the corresponding container identifier and stored in the data storage area for subsequent container operation status management. In this embodiment, the Kata runtime binds the virtual machine identifier to the container Pod identifier it receives and stores the binding relationship in the local key-value database.

[0037] S302: Execute a trusted boot process during the startup of the lightweight virtual machine and calculate a trusted measurement result.

[0038] Specifically, during the execution of the bootloader, the lightweight virtual machine performs layer-by-layer hash measurement operations on the operating system kernel and key system configuration files, and sequentially expands the obtained hash values ​​into the platform configuration registers (PCRs) in the virtual TPM module to form a trusted measurement result.

[0039] S303: The lightweight virtual machine submits the trust measurement result to the remote attestation server, so that the remote attestation server verifies the trust status of the lightweight virtual machine based on the trust measurement result; and after the verification is successful, the lightweight virtual machine receives an authorization response issued by the remote attestation server.

[0040] The remote attestation server parses the EK public key of the virtual TPM module and verifies whether its EK certificate is issued by the host certificate; then, based on the authentication trust chain built by the preset root certificate issuance service, it completes the cascade verification of the host identity.

[0041] If the verification is successful, the remote attestation server sends an authorization response to the lightweight virtual machine, where the response includes an image download token and a decryption key.

[0042] Specifically, the remote attestation server verifies the trust status of the lightweight virtual machine based on the trust measurement result, including: after receiving the trust measurement result submitted by the lightweight virtual machine, the remote attestation server parses the EK public key of the virtual trusted platform module; verifies whether the corresponding EK certificate is issued by the host certificate on which the virtual trusted platform module is deployed; and judges the trust status of the lightweight virtual machine based on the preset authentication trust chain formed between the host certificate and the root certificate issuance service.

[0043] S304: The lightweight virtual machine uses the download token to request downloading of the target encrypted container image from the container image repository, and downloads the target encrypted container image after verification by the container image repository.

[0044] The lightweight virtual machine initiates a request with a token to the container image repository, and the container image repository verifies the token. After the verification is passed, the target encrypted container image is allowed to be downloaded.

[0045] S305: The lightweight virtual machine uses the decryption key to decrypt the target encrypted container image, loads it into the container runtime environment, and starts the corresponding target container.

[0046] In this step, the lightweight virtual machine uses the decryption key contained in the aforementioned authorization response to perform a decryption operation on the downloaded encrypted container image, and then loads the decrypted image into the container runtime environment to complete the secure startup of the corresponding target container.

[0047] Through the above steps, this embodiment implements trusted control and link closure in the entire process of container creation, authentication, downloading, and operation, ensuring the integrity and security of the operating environment.

[0048] To further improve the security of the image delivery process in the container runtime environment, this embodiment provides a target encrypted container image generation and decryption mechanism. Figure 4 A flowchart showing the process of generating a target encrypted container image is shown. Figure 5 A schematic diagram showing the generation process of the target encrypted container image is shown. Figure 4 as well as Figure 5 , the generation process of the target encrypted container image includes: S401: The image encryption module sends an image identifier and encryption algorithm information to the key management service to request image encryption processing.

[0049] Specifically, after completing image construction, the image encryption module (for example, running on a DevOps management platform or a build node in an image building pipeline) sends the image's unique identifier (image ID) and the preset encryption algorithm type (such as AES-256) to the Key Management Service (KMS) to request image encryption processing.

[0050] S402: The key management service applies for an image upload token from the container image repository according to the image identifier, and generates a corresponding encryption key.

[0051] After receiving the encryption request, the key management service first requests an upload token from the container image repository based on the image identifier. This token is then used for subsequent image upload operations. Simultaneously, the key management service generates a corresponding symmetric encryption key and stores it, along with the image information and encryption algorithm, in a system-provided secure data storage area.

[0052] S403: The key management service returns the image upload token and the encryption key to the image encryption module.

[0053] The key management service returns the generated encryption key and image upload token to the image encryption module of the requester for encryption and upload operations.

[0054] S404: The image encryption module encrypts the container image using the encryption key, and uploads the encrypted container image to the container image repository using the image upload token.

[0055] The image encryption module uses the returned symmetric encryption key to encrypt the container image to obtain the encrypted target container image. Subsequently, the encrypted image is uploaded to the specified location in the container image repository using the upload token and marked as an encrypted image.

[0056] This process ensures the confidentiality and tamper-resistance of the image during storage and transmission, providing data protection for subsequent trusted deployment.

[0057] Corresponding to the encryption process, Figure 6 Figure 2 shows a schematic diagram of the image decryption process. Figure 6 As shown, the decryption process of the target encrypted container image includes the following steps: Image pull request: The Kata agent in the lightweight virtual machine initiates a decryption authorization request to the KMS, along with the image identifier and its own trusted proof information.

[0058] Key authorization: KMS verifies the submitted trusted identity and returns the repository address, download token, and decryption key corresponding to the image after verification.

[0059] Image download and decryption: The Kata agent uses the download token to pull the encrypted container image from the image repository and decrypts the image data using the authorized decryption key.

[0060] Image loading: The decrypted container image is loaded into the container runtime environment and the container startup process is executed.

[0061] This embodiment implements a centralized management and authorization distribution mechanism for image encryption keys through a key management service, combined with a trusted boot mechanism for remote attestation. This implements end-to-end container image security control from encrypted upload to authorized decryption, ensuring the integrity and confidentiality of container content at all stages of construction, distribution, and deployment.

[0062] Figure 7 The diagram below shows a diagram of the container startup process. In this embodiment, the present application proposes a method for creating a trusted container sandbox and running a trusted container within the sandbox. This embodiment forms a complete trusted container creation and loading link based on a lightweight virtual machine, a virtual trusted platform module, and a remote attestation and key authorization mechanism. The specific steps are as follows: Step 1: Receive scheduling instructions and prepare to create a container sandbox The Kubernetes container orchestration system uses its scheduler to decide to allocate a container pod to a target host. The scheduling result is sent to the Kubelet component on the target host through the API server.

[0063] After receiving the request to run the container, Kubelet calls the container runtime interface (Containerd + Kataruntime) to start the process of creating a sandbox container environment.

[0064] Step 2: Generate vTPM and create a lightweight virtual machine Kata runtime first calls the swTPM module deployed on the local host to generate a virtual TPM instance (vTPM) with an Endorsement Key (EK) public key, and issues an EK certificate for its EK public key based on the host certificate to ensure the continuation of the trusted identity chain.

[0065] The Kata runtime then calls the virtualization engine QEMU to create a lightweight virtual machine (Light VM) and injects the vTPM instance and EK certificate into QEMU as startup parameters. This VM serves as a trusted container sandbox, with an independent execution environment and trusted computing capabilities.

[0066] After successful creation, Kata runtime receives the virtual machine identifier from QEMU, binds it to the Pod identifier issued by Kubernetes, and writes it to the secure data storage area provided by the system for subsequent lifecycle management and scheduling synchronization.

[0067] Step 3: Perform trusted boot and metrics reporting After the Light VM is successfully started, the pre-configured Kata agent inside it automatically runs and starts the measurement agent module (Attestation Agent).

[0068] The Attestation Agent generates a standard hash record based on the hash value of the virtual machine file system (including the operating system image, configuration files, etc.), accesses the platform configuration register (PCR) of the vTPM to obtain the startup measurement data, generates a quote message for remote attestation, and sends it to the Attestation Server deployed on the CA trusted attestation platform.

[0069] The Attestation Server verifies the identity chain of the EK certificate in the Quote and compares the boot file hash with the whitelist to determine the credibility of the current state of the Light VM.

[0070] Step 4: Apply for and pull the protected image When remote attestation passes, the Kata agent initiates an image access request to the Key Management Service (KMS), submitting information including the image identifier and requesting to download the token and decryption key.

[0071] Based on the image identifier, KMS first searches the internal key database for the corresponding encryption algorithm and key, and then applies for a temporary download token from the image repository.

[0072] Subsequently, KMS returns the image's encryption algorithm, decryption key, and download token to the Kata agent.

[0073] Step 5: Image decryption and container startup The Kata agent uses the above download token to securely pull the target encrypted container image from the image repository and decrypt it using the obtained decryption key and algorithm.

[0074] The decrypted image file is injected into the container runtime environment inside the Light VM to complete the container loading.

[0075] After the container is successfully started, Kata Runtime follows the CRI (Container Runtime Interface) standard and feeds the container startup status back to Containerd, which then reports the information to Kubelet.

[0076] Finally, Kubelet returns the notification of container startup completion to the Kubernetes control plane, completing the trusted scheduling and execution loop of the entire Pod.

[0077] Figure 8 The diagram shows the process of executing the trusted boot process and calculating the trusted measurement results during the startup of the lightweight virtual machine. Figure 8 , the process specifically includes: S801: Based on the virtual trusted platform module, perform layer-by-layer hash measurement on a file set in the file system to calculate a corresponding hash value.

[0078] After the lightweight VM boots up, it relies on its built-in virtual trusted platform module to perform layer-by-layer hash calculations on a set of key files in the file system. This set of files typically includes, but is not limited to, the boot loader (bootloader), kernel image (vmlinuz), initial root file system (initramfs), and system configuration files (such as key configuration files under / etc), ensuring that key system components have not been tampered with.

[0079] S802: Expand the hash values ​​into hash extension results in sequence, and store the results in the platform configuration register of the virtual trusted platform module.

[0080] The hash values ​​are input into the platform configuration registers of the virtual trusted platform module in a predefined order, and the final hash extension value is generated through the Hash Extend operation. This extension value is stored in the PCR as a summary of the system integrity state and used as a trust measurement evidence.

[0081] S803: Calling the measurement agent module in the lightweight virtual machine to access the platform configuration register, extracting and generating a trusted measurement result for use in remote attestation.

[0082] The Attestation Agent in the virtual machine calls the TPM interface to access the PCR registers to obtain the current hash expansion result. It then generates a Quote structure for remote attestation based on this hash expansion value and the TPM's internal identity key, forming a trusted measurement result that is submitted to the remote attestation server.

[0083] This process ensures that every key component of the virtual machine from boot to initialization is effectively measured, and the measurement results cannot be forged or forged, providing a secure premise for trusted loading of container images.

[0084] On the basis of any of the above embodiments, in order to further improve the security assurance capability during the operation of the container, the embodiment of the present application also provides a runtime integrity continuous monitoring and response mechanism, see Figure 9 The specific process is as follows: S901: Activate the built-in continuous measurement task module in the lightweight virtual machine, perform continuous measurement on the file set based on the integrity measurement architecture subsystem, and generate a file integrity measurement log.

[0085] Use the osbuilder tool provided by Kata Container to create a Linux image with the IMA subsystem activated. Use it as the OS image for the light VM created by QEMU.

[0086] After the light VM starts and successfully runs the container, the Kata agent component running in the light VM activates the Measure task. Whenever a file is read or written, the file hash is measured and written to the PCR register.

[0087] Figure 10 The following figure shows a message chain diagram for handling security exceptions during continuous measurement. Figure 10 When the target container successfully starts, the Kata agent component within the lightweight VM automatically activates the pre-configured continuous measurement task module (Measure Task). This module, based on the Linux Integrity Measurement Architecture (IMA) subsystem, continuously performs hash measurements on the key files that the container depends on at runtime (such as system configuration, runtime libraries, startup scripts, etc.), generating a file integrity measurement log.

[0088] The measurement process uses the same measurement algorithm (such as SHA-256) as that used at startup to ensure consistency and comparability of measurement results.

[0089] S902: The file integrity measurement log is periodically sent to a remote attestation server so that the remote attestation server compares the hash value of each file therein with a reference hash value generated when building the container image to determine the runtime integrity status.

[0090] The Measure Task transmits the real-time file integrity measurement logs to the remote attestation server in the Security Center platform. The attestation server compares each file hash value recorded in the log with the baseline hash value generated when building the container image.

[0091] By comparing, it is possible to accurately identify whether abnormal behaviors such as malicious file tampering, replacement, or injection have occurred during the operation of the container, thereby achieving continuous verification of the runtime integrity status.

[0092] S903: When an abnormal change in a file is detected, the remote attestation server reports the abnormal event to the policy management server so that the policy management server can determine the risk level according to the preset security policy, and send a control instruction to the container orchestration system when the risk level meets the preset condition to trigger the execution of the corresponding container destruction or restart operation.

[0093] Once a key file hash value is found to be inconsistent with the baseline value, the Attestation Server will immediately generate an abnormal event report and submit the report to the Strategy Server. The Strategy Server will conduct a risk assessment of the event based on the preset security policy and risk level judgment model.

[0094] When an event is identified as a serious risk or reaches the warning threshold, the policy management server will call the API interface provided by the container orchestration system (such as Kubernetes) and issue control instructions to trigger the destruction or restart of the corresponding container to achieve immediate risk isolation and repair response.

[0095] This implementation extends the traditional static trusted computing model to a full-cycle security assurance system for the container lifecycle by introducing a dynamic measurement mechanism during container operation. By continuously collecting, comparing, and triggering response actions, it significantly improves the container operating environment's defenses against unknown threats, tampering, and zero-day attacks, demonstrating promising industrial applicability and widespread adoption.

[0096] In another embodiment of the present application, a trusted control device for a container operating environment is provided. The device is deployed on a host and is used to implement trusted control of the container operating environment during startup and loading, thereby ensuring the integrity and confidentiality of the container execution environment. Figure 11As shown, the device may include the following modules or functional units: The lightweight virtual machine creation module 100 is used to create a lightweight virtual machine on the host and integrate a virtual trusted platform module into the lightweight virtual machine.

[0097] In specific implementations, the host invokes a virtual TPM management component (such as swTPM) to generate an identity key pair with an EK public key. The EK public key is then signed using the local host certificate to generate an EK certificate. The host then passes the generated virtual TPM instance and EK certificate as parameters to a virtualization engine (such as QEMU) to create a sandboxed virtual machine with a trusted module.

[0098] The trusted startup module 200 is used to execute a trusted startup process during the startup of the lightweight virtual machine and calculate a trusted measurement result.

[0099] This module is used to perform the trusted boot process during virtual machine startup.

[0100] Specifically, the module cooperates with the IMA (Integrity Measurement Architecture) subsystem to perform layer-by-layer hash measurement on the boot loader, kernel, driver, and key system files, and writes the hash values ​​into the platform configuration registers (PCRs) of the virtual TPM in a preset order, ultimately forming a trusted measurement result (Quote), providing basic data for remote attestation.

[0101] The remote attestation interaction module 300 is used to submit the trust measurement result to the remote attestation server so that the remote attestation server verifies the trust status of the lightweight virtual machine based on the trust measurement result; and after the verification is passed, the lightweight virtual machine receives the authorization response issued by the remote attestation server, and the authorization response includes the image download token and decryption key.

[0102] This module is used to submit the trust measurement results generated by the virtual machine to the remote attestation server and receive the returned authorization response.

[0103] After receiving the measurement result, the remote attestation server parses the virtual TPM's EK public key and authenticates the virtual machine based on the authentication trust chain consisting of the host certificate and the root certificate. It also compares the measurement hash value to determine the credibility of the current virtual machine state.

[0104] When the verification is successful, the remote attestation server sends an authorization response, which contains the download token and decryption key for accessing the container image repository.

[0105] The image download module 400 is configured to use the download token to request downloading of a target encrypted container image from a container image repository, and download the target encrypted container image after verification by the container image repository.

[0106] This module uses a download token to initiate access requests to a container image repository. After verifying the token's validity, the container image repository allows the virtual machine to download the target encrypted container image. The download process is implemented based on the standard OCI image pull protocol, supporting the fragmented retrieval of multi-layer image structures.

[0107] The image decryption and startup module 500 is used to decrypt the target encrypted container image using the decryption key, and load it into the container runtime environment to start the corresponding target container.

[0108] This module is responsible for decrypting the encrypted image and completing the container startup process. Specifically, the module uses the previously obtained decryption key to decrypt the image, obtain usable image data, and load it into the container runtime environment (such as Kata Container) within the virtual machine. Once the container is started, it can be registered and scheduled through the Kubernetes container orchestration system.

[0109] This application executes a trusted startup process during the startup of a lightweight virtual machine and calculates the trusted measurement results to ensure that the container operating environment has not been tampered with, fundamentally improving the credibility of the initialization phase and effectively preventing malicious tampering and other attacks. Through the mechanism of submitting trusted measurement results to a remote attestation server, a centralized and verifiable proof of the security status of each container instance is achieved. In addition, the image download token and decryption key are only issued after the remote attestation server has passed the verification, ensuring that access to sensitive resources is allowed only in a trusted environment, avoiding image leakage or use by unauthorized devices. From the trusted startup of the virtual machine to the security measurement, and further authorization verification, followed by encrypted download of the image, and finally decryption startup, a trusted execution closed loop is formed to ensure that the container operating environment is secure and trustworthy during the initialization phase.

[0110] In addition, this application also provides a trusted control device for the container operating environment, such as Figure 12 As shown, the device includes a memory 11 and a processor 12, wherein the memory 11 stores a computer program, and when the computer program is executed by the processor 12, the trusted control method of the container operating environment according to any one of the above-mentioned methods is implemented.

[0111] In addition, the present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the trusted control method of the container operating environment according to any of the above-mentioned methods is implemented.

[0112] Computer-readable storage media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0113] Professionals should also be further aware that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0114] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0115] The specific implementation methods described above further illustrate the purpose, technical solutions and beneficial effects of this application. It should be understood that the above description is only the specific implementation methods of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this application should be included in the scope of protection of this application.

Claims

1. A trusted control method for a container operating environment, characterized in that: A lightweight virtual machine is created on a host, and a virtual trusted platform module is integrated into the lightweight virtual machine. The method includes: During the startup of the lightweight virtual machine, a trusted startup process is executed and a trusted measurement result is calculated; The lightweight virtual machine submits the trust measurement result to the remote attestation server, so that the remote attestation server verifies the trust status of the lightweight virtual machine based on the trust measurement result; and after the verification is successful, the lightweight virtual machine receives an authorization response from the remote attestation server, the authorization response including the image download token and the decryption key; The lightweight virtual machine uses the download token to request downloading of the target encrypted container image from the container image repository, and downloads the target encrypted container image after verification by the container image repository; The lightweight virtual machine uses the decryption key to decrypt the target encrypted container image, and loads it into the container runtime environment to start the corresponding target container.

2. The trusted control method for a container operating environment according to claim 1, characterized in that: The remote attestation server verifies the trustworthy state of the lightweight virtual machine based on the trustworthy measurement result, including: After receiving the trust measurement result submitted by the lightweight virtual machine, the remote attestation server parses the EK public key of the virtual trusted platform module; Verify whether the corresponding EK certificate is issued by the host certificate on which the virtual trusted platform module is deployed; The trust status of the lightweight virtual machine is determined based on a preset authentication trust chain formed between the host certificate and the root certificate issuance service.

3. The trusted control method for the container operating environment according to claim 2, characterized in that: The process of building the preset authentication trust chain includes: On the server with the physical trusted platform module deployed, generate a key pair for issuing certificates and deploy a root certificate issuance service as the trusted root of the cluster trust chain. Each host deployed with a virtual trusted platform module submits a certificate issuance request to the root certificate issuance service and obtains a host certificate issued by the root certificate issuance service as an intermediate node of the trust chain; The host generates an EK public key during the initialization of the virtual trusted platform module, and signs the EK public key using the private key corresponding to the host certificate to form an EK certificate for identity authentication, thereby building a three-layer trust chain structure.

4. The trusted control method for the container operating environment according to claim 3, characterized in that: The step of creating a lightweight virtual machine on a host includes: The host calls the virtual trusted platform module to generate a virtual trusted platform module instance, wherein the virtual trusted platform module instance includes an identity key pair with an EK public key; Signing the EK public key based on the host certificate of the host to form an EK certificate; Injecting the generated virtual trusted platform module instance and the EK certificate as parameters into the virtualization engine QEMU, so that the virtualization engine QEMU creates a sandbox lightweight virtual machine integrating the virtual trusted platform module based on the parameters and returns the corresponding virtual machine identifier; The virtual machine identifier is associated and bound with the corresponding container identifier and stored in the data storage area for subsequent container operation status management.

5. The trusted control method for a container operating environment according to claim 1, characterized in that: The process of generating the target encrypted container image includes: The image encryption module sends the image identifier and encryption algorithm information to the key management service to request image encryption processing; The key management service applies for an image upload token from the container image repository according to the image identifier and generates a corresponding encryption key; The key management service returns the image upload token and the encryption key to the image encryption module; The image encryption module encrypts the container image using the encryption key, and uploads the encrypted container image to the container image repository using the image upload token.

6. The trusted control method for a container operating environment according to any one of claims 1 to 5, characterized in that: The trusted boot process is executed during the startup of the lightweight virtual machine, and the trusted measurement result is calculated, including: Based on the virtual trusted platform module, a layer-by-layer hash measurement is performed on the file set in the file system to calculate the corresponding hash value; Expanding the hash values ​​into hash extension results in sequence, and storing the results in a platform configuration register of a virtual trusted platform module; The measurement agent module in the lightweight virtual machine is called to access the platform configuration register, and to extract and generate a trusted measurement result for use in remote attestation.

7. The trusted control method for a container operating environment according to claim 6, characterized in that: After loading into the container runtime environment and starting the target container, the method further includes: Activate the built-in continuous measurement task module in the lightweight virtual machine, perform continuous measurement on the file collection based on the integrity measurement architecture subsystem, and generate a file integrity measurement log; Periodically sending the file integrity measurement log to a remote attestation server so that the remote attestation server can compare the hash value of each file therein with a reference hash value generated when building the container image to determine the runtime integrity status; When an abnormal change in a file is detected, the remote attestation server reports the abnormal event to the policy management server so that the policy management server can determine the risk level according to the preset security policy and send a control instruction to the container orchestration system to trigger the corresponding container destruction or restart operation when the risk level meets the preset condition.

8. A trusted control device for a container operating environment, characterized in that: Deployed on a host, the device includes: A lightweight virtual machine creation module, configured to create a lightweight virtual machine on the host and integrate a virtual trusted platform module into the lightweight virtual machine; A trusted boot module, configured to execute a trusted boot process during the startup of the lightweight virtual machine and calculate a trusted measurement result; A remote attestation interaction module is configured to submit a trust measurement result to a remote attestation server so that the remote attestation server verifies the trust status of the lightweight virtual machine based on the trust measurement result; and after the verification is successful, the lightweight virtual machine receives an authorization response from the remote attestation server, the authorization response including an image download token and a decryption key; An image download module, configured to use the download token to request download of a target encrypted container image from a container image repository, and download the target encrypted container image after verification by the container image repository; The image decryption and startup module is used to decrypt the target encrypted container image using the decryption key, and load it into the container runtime environment to start the corresponding target container.

9. A trusted control device for a container runtime environment, characterized in that: The system comprises a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the method for trusted control of a container operating environment according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor, the trusted control method for the container operating environment according to any one of claims 1 to 7 is implemented.

Images