Method and system for realizing micro-isolation of container based on trusted state
By using an incremental trusted proof mechanism based on trusted state, containers periodically submit incremental proofs and generate time-sensitive credentials, which solves the problems of security isolation and low verification efficiency between containers, and achieves efficient and secure container micro-segmentation and event traceability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-25
- Publication Date
- 2026-03-27
AI Technical Summary
In existing technologies, the security isolation capabilities between containers are weak, and the verification efficiency of remote trusted proofs is low, which affects the system's operating efficiency.
Through an incremental trusted proof mechanism based on trusted state, containers periodically submit incremental trusted proofs, use TPM for digital signatures and behavior recording, generate time-sensitive credentials, and transmit and verify them between containers to ensure security and efficiency.
It achieves efficient and secure micro-isolation between containers, generates structured security event logs, facilitates subsequent traceability, and improves verification efficiency and security.
Smart Images
Figure CN121742974A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer security technology and relates to a method and system for implementing container micro-segmentation, particularly a method and system for implementing container micro-segmentation based on trusted state. Background Technology
[0002] Container technology is a virtualization technology that packages applications and their dependencies into a standardized unit called a container. The main advantage of container technology is its ability to provide a consistent runtime environment, allowing applications to run in different environments without needing to consider environmental differences. With the development of cloud computing and container technology, containers have become an important form of modern application deployment due to their advantages such as lightweight design, rapid deployment, and elastic scaling.
[0003] However, because containers typically run on a shared host kernel, their security isolation capabilities are weaker than those of virtual machines. If containers are not isolated based on trusted state, serious security vulnerabilities will arise. Therefore, how to achieve micro-isolation between containers based on trusted state is crucial.
[0004] Meanwhile, existing trusted proof methods based on remote trusted proofs have a significant drawback: efficiency. Because each complete remote trusted proof requires verifying every single entry in the container's non-volatile memory, the sheer number of entries in the non-volatile memory during long system runs can severely impact verification efficiency.
[0005] Therefore, how to achieve micro-isolation between containers while ensuring safety and efficiency is an important issue that urgently needs to be addressed. Summary of the Invention
[0006] To overcome the shortcomings of existing technologies, this invention proposes a method and system for achieving container micro-isolation based on trusted states, which can achieve micro-isolation between containers based on trusted states with high security and high verification efficiency.
[0007] To achieve the above objectives, the present invention provides the following technical solution: A method for implementing container micro-segmentation based on trusted state, characterized by the following steps: S1: The first container periodically submits incremental trusted proofs to the trusted verification module; S2: The trusted verification module performs trusted verification based on the incremental trusted proof, and after the verification is successful, generates a time-limited credential and returns the time-limited credential to the first container; S3: When the first container sends a request to the second container, the request payload data sent contains the latest time-sensitive credential; S4: The second container verifies the validity of the latest time-limited credential. If valid, it accepts the request payload data and hands it over to the business processing module for processing. If the request payload data has expired or is invalid, it discards the request payload data.
[0008] Preferably, the incremental trusted proof in step S1 includes the file path of the updated file and its corresponding changed hash value, and the newly added configuration item or runtime environment parameter and its corresponding newly added hash value.
[0009] Preferably, in step S1, before submitting the incremental trusted proof to the trusted verification module, the Agent of the first container uses the TPM private key in the first container to digitally sign the incremental trusted proof and the submission timestamp, and records the submission event and operation status in the storage area protected by the TPM in the first container, with each new record containing the hash value of the previous record.
[0010] Preferably, the trusted verification module in step S2 performs trusted verification based on the incremental trusted proof in the following way: the trusted verification module compares the changed hash value corresponding to each updated file and the new hash value corresponding to the new configuration item or runtime environment parameter in the incremental trusted proof with the trusted baseline value. Only when all changed hash values and new hash values pass the verification is the first container determined to be trusted. If some hash values fail the verification, exception handling is triggered.
[0011] Preferably, in step S4, the second container verifying the validity of the latest time-sensitive credential specifically includes: Signature verification: Verifies whether the signature of the latest valid credential was issued by the trusted verification module; Expiration time verification: Check whether the latest time-limited voucher is still within its validity period; Permission verification: Determine whether the access permissions declared in the latest time-limited credential comply with the security policy of the second container; Container ID verification: Confirm whether the container ID bound to the latest time-limited credential matches the first container.
[0012] Preferably, in step S3, before sending a request to the second container, the first container also puts the identity information of the first container into the time-limited credential, and in step S4, when the second container verifies the validity of the latest time-limited credential, it simultaneously checks whether the identity information of the first container that is currently sending the request is consistent with the identity information of the container recorded in the latest time-limited credential.
[0013] Preferably, it further includes: S5: The second container generates a structured security event log, which includes: the ID of the first container, the hash digest of the latest time-sensitive credential, the verification result, the request time, and the request load data.
[0014] Furthermore, the present invention also provides a system for realizing container micro-isolation based on trusted states, characterized in that it includes: An incremental trusted proof submission module is used to enable the first container to periodically submit incremental trusted proofs to the trusted verification module. The trusted verification and credential return module is used to enable the trusted verification module to perform trusted verification based on the incremental trusted proof, generate a time-limited credential after the verification is passed, and return the time-limited credential to the first container. A request payload data sending module is configured to cause the first container to send a request to the second container, and the sent request payload data contains the latest time-sensitive credentials. The credential verification module is used to enable the second container to verify the validity of the latest time-limited credential. If valid, it accepts the request payload data and hands it over to the business processing module for processing. If the request payload data has expired or is invalid, it discards the request payload data.
[0015] Furthermore, the present invention also provides a device for realizing container micro-isolation based on trusted state, characterized in that it includes: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the container micro-segmentation method based on trusted state as described above. Finally, the present invention also provides a computer-readable storage medium having a computer program stored thereon, characterized in that, when the program is executed by a processor, it implements the steps of the method for implementing container micro-isolation based on trusted state as described above.
[0016] Compared with existing technologies, the method and system for achieving container micro-isolation based on trusted states proposed in this invention have the following significant advantages: 1. This invention achieves micro-isolation between containers based on trusted state through remote trusted proof, thus ensuring security.
[0017] 2. This invention performs trusted verification based on incremental trusted proof, which is highly efficient and resource-saving.
[0018] 3. This invention can generate structured security event logs, which facilitates subsequent security tracing. Attached Figure Description
[0019] Figure 1 This is a flowchart of the method for achieving container micro-isolation based on trusted state according to the present invention.
[0020] Figure 2 This is a schematic diagram of the system for realizing container micro-isolation based on trusted state according to the present invention.
[0021] Figure 3 This is a structural block diagram of the device for realizing container micro-isolation based on trusted state according to the present invention. Detailed Implementation
[0022] Before detailing any embodiment of the invention, it should be understood that the invention, in its application, is not limited to the details of the construction and arrangement of the components set forth in the following description or illustrated in the following figures. The invention can have other embodiments and can be practiced or carried out in various ways. Furthermore, it should be understood that the wording and terminology used herein are for descriptive purposes and should not be considered limiting. The use of “comprising” or “having” and variations thereof in this invention is intended to cover the items set forth below and their equivalents, as well as any additional items. Unless otherwise specified or limited, the terms “installation,” “connection,” “support,” and “linkage,” and variations thereof are used broadly and cover both direct and indirect installation, connection, support, and linking. Moreover, “connection” and “linkage” are not limited to physical or mechanical connections or links. Furthermore, firstly, in the disclosure of this invention, the terms "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the above terms should not be construed as limiting this invention. Secondly, the term "a" should be understood as "at least one" or "one or more," that is, in one embodiment, the number of an element can be one, while in another embodiment, the number of the element can be multiple. The term "a" should not be construed as a limitation on the quantity.
[0023] Figure 1 A flowchart of the method for achieving container micro-segmentation based on trusted states according to the present invention is shown. Figure 1 As shown, the method for achieving container micro-segmentation based on trusted state according to the present invention includes the following steps: S1: Incremental Trusted Proof Submission: The first container periodically submits incremental trusted proofs to the trusted verification module.
[0024] In this invention, the Agent of the first container submits incremental trusted proofs to the trusted verification module at fixed time intervals (scheduled tasks). Specifically, the time interval can be configured according to security needs (e.g., every minute, every five minutes, etc.) to balance security and system overhead.
[0025] The system consists of a register called PCR (Platform Configuration Register) and an ML file on the hard drive, responsible for storing critical files, configuration items, or runtime environment parameters and their corresponding hash values. Specifically, the ML file stores information such as the file order during system loading, and the PCR stores the latest digest of the files, i.e., the hash value. The TPM is an encryption chip primarily used to protect the stored hash values. In this invention, the Agent of the first container only extracts the file path of the updated file and its corresponding hash value, as well as the newly added configuration items or runtime environment parameters and their corresponding hash values each time. That is, the Agent of the first container extracts the content stored in the ML file and the content stored in the PCT, and uses them to form an incremental trusted proof.
[0026] 1. File update scenarios.
[0027] For example, the configuration file ` / etc / app / config.yaml` in the first container is modified by the administrator to adjust the application's access parameters. This configuration file is now updated, and its hash value changes from `abc123...` to `def456...`, which is different from the previous measurement result. Therefore, the agent in the first container will submit the configuration file path and the new hash value "def456..." as an incremental trusted proof.
[0028] 2. Situations where the operating environment changes.
[0029] For example, if the first container starts a new background service process or loads a new dependency module, such as modifying a new background process worker.py, the runtime environment parameters will change. The Agent will submit the newly added process identifier, the new runtime environment parameters, and their corresponding hash values as an incremental trusted commit.
[0030] In this invention, the Agent of the first container can send incremental trusted proofs to the Trusted Authentication Module (Attestation Service) via a TLS connection.
[0031] Furthermore, in this invention, the timed submission of the incremental trusted proof itself becomes part of verifying the trusted state of the first container. That is, if the first container fails to submit the incremental trusted proof on a timed basis, it indicates that the first container is in an untrusted state.
[0032] Furthermore, in this invention, the behavior of the Agent of the first container can be signed or recorded within the trusted verification module or the first container to prevent tampering.
[0033] Specifically, to prevent the Agent's behavior from being tampered with, signatures or records can be made in the following ways: 1. Signature: The Agent digitally signs each generated incremental proof of feasibility and submission timestamp using the TPM private key within the first container. Since the private key is only available within the TPM, no external entity can forge the signature. Upon receiving the data, the trusted verification module can verify the signature using the corresponding public key, thus confirming that the data source is indeed the trusted Agent and that the content has not been modified.
[0034] 2. Behavior Recording: The Agent's periodic commit events and operation status can be recorded in a storage area protected by TPM within the first container, for example, by writing to non-volatile storage or generating a hash chain. Each new record can include the hash value of the previous record as a chain dependency, so that any attempt to tamper with an earlier record will break the subsequent chain and be detected by the trusted verification module.
[0035] Through the signature and behavior recording mechanism, it can be guaranteed that: (1) the source is trustworthy - the incremental trust proof is indeed generated by the designated Agent; (2) the content is complete - any tampering or replay behavior will be detected; (3) the behavior is auditable - each timed submission behavior can be tracked, providing a basis for the continuous verification of the trusted container.
[0036] Therefore, in this invention, the trusted verification is performed based on incremental trusted proof, which results in high verification efficiency and high security.
[0037] S2: Trusted Verification and Credential Return - The trusted verification module performs trusted verification based on the incremental trusted proof. After successful verification, it generates a time-limited credential and returns the time-limited credential to the first container.
[0038] In this invention, after receiving the incremental trusted proof submitted by the Agent of the first container, the trusted verification module compares the hash values (hash matching). Specifically, it compares the changed hash value corresponding to each updated file and the new hash value corresponding to the newly added configuration item or runtime environment parameter in the incremental trusted proof with the trusted baseline value. Only when all changed hash values and new hash values pass the verification is the first container determined to be trusted. If some hash value verification fails, an exception handling is triggered (rejecting credential issuance or logging a security event).
[0039] In this invention, the time-limited credential, i.e., the Token, is a digital credential containing the following fields: Signature algorithm: ensures the token is immutable (e.g., RSA, ECDSA); Credential type: Identifies the purpose (e.g., access credential, communication credential); Issuer: Identifier of the trusted verification module; User ID / Container ID: Identifies the container to which the token belongs; Issue date and expiration date: These indicate the validity period; Signature: Signed by the issuer using a private key to ensure integrity; The time-sensitive credential can adopt a standard binary structure to balance security and transmission efficiency.
[0040] After receiving the time-limited credential, the first container stores the time-limited credential token in the PCR (Platform Configuration Register) binding storage of the first container's TPM. The time-limited credential token can be bound to the current trusted state of the first container (i.e., it is only valid in the current trusted state) to prevent the token from being stolen and reused in an untrusted state. Furthermore, when the token is about to expire or the container state is updated, a new token can be automatically requested for reissue. This refresh mechanism can be triggered by the Agent to ensure that the token always corresponds to the latest trusted state of the container. If the container is determined to be untrusted, the token is immediately revoked and cleared from the TPM storage. Thus, token lifecycle management forms a closed loop, ensuring the continuity of trusted communication and access control.
[0041] S3: Sending Requested Load Data: When the first container sends requested load data to the second container, the requested load data contains the latest time-sensitive credential.
[0042] In this invention, when the first container sends request payload data to the second container, the latest time-validated credential token of the first container is appended to the request payload data. The token can be transmitted between the first and second containers via an HTTP header. By ensuring that the outgoing request payload data carries the latest time-validated credential token, it can be ensured that the second container can verify the trusted status of the first container.
[0043] Furthermore, in this invention, communication between the first container and the second container establishes an encrypted channel via TLS. The latest, time-sensitive credential token is transmitted only within the secure channel to prevent man-in-the-middle and replay attacks, and data is encrypted during transmission to prevent token leakage.
[0044] Furthermore, in this invention, when the validity period of the latest time-limited credential token of the first container expires, the second container and the first container disconnect, and when the first container receives another latest time-limited credential returned by the trusted verification module, the first container can reconnect with the second container.
[0045] S4: Credential Verification - The second container verifies the validity of the latest valid credential. If valid, it accepts the request payload data and hands it over to the business processing module for processing. If the request payload data has expired or is invalid, it discards the request payload data.
[0046] In this invention, after receiving the request payload data, the proxy of the second container extracts the latest time-sensitive credential token from the HTTP header. After extraction, the verification process is completed entirely within the local TPM environment of the second container, avoiding reliance on external services and improving real-time performance and security.
[0047] The proxy in the second container verifies the latest, time-sensitive token content to ensure the token data is secure and valid. The verification logic follows a multi-dimensional strategy to ensure the authenticity and timeliness of the token: 1. Signature Verification: Verify whether the signature of the latest valid credential token was issued by the trusted verification module; 2. TTL (Time To Live) Verification: Check whether the latest time-limited credential is still valid; 3. Permission verification: Determine whether the access permissions declared in the latest time-limited credential token comply with the security policy of the second container; 4. Container ID Verification: Confirm whether the container ID bound to the time-limited credential token matches the request source container (i.e., the first container).
[0048] If any verification item fails, the request is immediately rejected. That is, if the latest time-limited credential token is invalid, the signature does not match, it expires, the permissions are insufficient, or the identity does not match, the Proxy of the second container immediately discards the request data and does not enter the business processing layer.
[0049] Furthermore, in this invention, the first container and the second container exchange information based on the TLS protocol during the connection. The first container submits three pieces of information during this exchange: the time-limited credential token itself, the first container's identity information, and the valid information to be passed to the second container. To prevent the latest time-limited credential token from being stolen and misused, when issuing the latest time-limited credential token, the first container can also include some of its own identity information (such as TPM information) in the latest time-limited credential token. When verifying the latest time-limited credential token, the second container simultaneously checks whether the identity information of the currently requesting first container matches the identity information recorded in the latest time-limited credential token.
[0050] S5: Structured Security Event Log Generation - The second container generates a structured security event log, which includes: the ID of the first container, the hash digest of the latest time-sensitive credential, the verification result, the request time, and the request load data.
[0051] In this invention, the verification results (success or failure) of all requests sent by the first container generate a structured security event log for subsequent security tracing. The structured security event log includes: the request source container ID (i.e., the ID of the first container); the latest hash digest of the time-sensitive credential token; the verification result (pass / fail / exception type); the timestamp (i.e., the request time); and the request context (i.e., the request payload data).
[0052] S6: Structured Security Event Log Reporting - The second container reports the structured security event log to the central audit system through a secure channel to facilitate anomaly tracing, trend analysis, threat attribution, and post-event verification.
[0053] In this invention, the structured security event logs can be reported to the central audit center via a secure channel, thereby supporting: anomaly tracing; trend analysis; threat attribution; and post-event verification. Simultaneously, the log system of the second container can be linked with the trusted verification module to achieve event-based trust decay or dynamic policy adjustment.
[0054] Figure 2 A schematic diagram of the container micro-isolation system based on trusted states according to the present invention is shown. Figure 2 As shown, the system for container micro-isolation based on trusted states according to the present invention is characterized by comprising: 1. Incremental Trusted Proof Submission Module.
[0055] The incremental trusted proof submission module is used to enable the first container to periodically submit incremental trusted proofs to the trusted verification module.
[0056] 2. Trusted verification and credential return module.
[0057] The trusted verification and credential return module is used to enable the trusted verification module to perform trusted verification based on the incremental trusted proof, and after the verification is passed, generate a time-limited credential and return the time-limited credential to the first container.
[0058] 3. Request the load data sending module.
[0059] The request load data sending module is used to enable the first container to send request load data to the second container, the request load data containing the latest time-sensitive credentials.
[0060] 4. Credential Verification Module.
[0061] The credential verification module is used to enable the second container to verify the validity of the latest time-sensitive credential. If it is valid, the module accepts the request payload data and hands it over to the business processing module for processing. If the request payload data has expired or is invalid, the module discards it.
[0062] Preferably, the system for achieving container micro-isolation based on trusted states according to the present invention further includes: 5. Structured security event log generation module.
[0063] The structured security event log generation module is used to enable the second container to generate structured security event logs. The structured event security logs include: the ID of the first container, the hash digest of the latest time-sensitive credential, the verification result, the request time, and the request load data.
[0064] In this invention, the verification results (success or failure) of all requests sent by the first container generate a structured security event log for subsequent security tracing. The structured security event log includes: the request source container ID (i.e., the ID of the first container); the latest hash digest of the time-sensitive credential token; the verification result (pass / fail / exception type); the timestamp (i.e., the request time); and the request context (i.e., the request payload data).
[0065] 6. Structured security event log reporting module.
[0066] The structured security event log reporting module enables the second container to report the structured security event log to the central audit system through a secure channel, so as to facilitate anomaly tracing, trend analysis, threat attribution, and post-event verification.
[0067] In this invention, the structured security event logs can be reported to the central audit center via a secure channel, thereby supporting: anomaly tracing; trend analysis; threat attribution; and post-event verification. Simultaneously, the log system of the second container can be linked with the trusted verification module to achieve event-based trust decay or dynamic policy adjustment.
[0068] Furthermore, this invention also provides a device for achieving container micro-isolation based on trusted states. For example... Figure 3 As shown, the device for implementing container micro-segmentation based on trusted state according to the present invention includes: a memory 11 for storing one or more programs; one or more processors 12; when the one or more programs are executed by the one or more processors 12, the one or more processors 12 implement the method for implementing container micro-segmentation based on trusted state according to the present invention. Finally, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method for implementing container micro-segmentation based on trusted state in the present invention.
[0069] The computer-readable storage medium includes both permanent and non-permanent, removable and non-removable media, and information storage can be achieved by any method or technology. 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device. As defined in this invention, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0070] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art 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.
[0071] The steps of the methods or algorithms described in conjunction with the embodiments disclosed in this invention can be implemented in hardware, software modules executed by a processor, or a combination of both. The software modules can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art.
[0072] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit the scope of protection of the present invention. Those skilled in the art can modify or make equivalent substitutions to the technical solutions of the present invention based on the concept of the present invention, without departing from the essence and scope of the technical solutions of the present invention.
Claims
1. A method for implementing container micro-isolation based on trusted state, comprising: The method comprises the following steps: S1: the first container periodically submits an incremental trusted proof to a trusted verification module; S2: the trusted verification module performs trusted verification based on the incremental trusted proof, and generates a time-limited credential and returns the time-limited credential to the first container after verification is passed; S3: when the first container sends a request to the second container, the request load data sent contains the latest time-limited credential; S4: the second container verifies the validity of the latest time-limited credential, if valid, accepts the request load data and hands over the request load data to a business processing module for processing, if expired or invalid, discards the request load data.
2. The method for implementing container micro-isolation based on trusted state according to claim 1, wherein, The incremental trusted proof in step S1 comprises the file path of the updated file and the corresponding changed hash value and the newly added configuration item or running environment parameter and the corresponding newly added hash value.
3. The method for implementing container micro-isolation based on trusted state according to claim 2, characterized in that, Before submitting the incremental trusted proof to the trusted verification module, the Agent of the first container uses the TPM private key in the first container to digitally sign the incremental trusted proof and the submission timestamp, and records the submission event and the operation state in the storage area protected by the TPM in the first container, and each new record contains the hash value of the previous record.
4. The method for implementing container micro-isolation based on trusted state according to claim 3, characterized in that, The trusted verification module performs trusted verification based on the incremental trusted proof in step S2, specifically: the trusted verification module compares the changed hash value corresponding to each updated file and the newly added hash value corresponding to the newly added configuration item or running environment parameter in the incremental trusted proof with the trusted baseline value, only when all the changed hash values and the newly added hash values pass the verification, the first container is determined to be trusted, if part of the hash values fail the verification, an abnormal processing is triggered.
5. The method for implementing container micro-isolation based on trusted state according to claim 4, wherein, In step S4, the second container verifies the validity of the latest time-limited credential, specifically including: signature verification: verifying whether the signature of the latest time-limited credential is issued by the trusted verification module; expiration time verification: checking whether the latest time-limited credential is within the valid period; permission verification: judging whether the access permission declared in the latest time-limited credential matches the security policy of the second container; container ID verification: confirming whether the container ID bound to the latest time-limited credential matches the first container.
6. The method for implementing container micro-isolation based on trusted state according to claim 5, wherein, In step S3, before sending a request to the second container, the first container also puts the identity information of the first container into the time-limited credential, and in step S4, when the second container verifies the validity of the latest time-limited credential, it also checks whether the identity information of the first container currently sending the request is consistent with the identity information of the container recorded in the latest time-limited credential.
7. The method of implementing container micro -segregation based on trusted state according to any one of claims 1-6, wherein, Further comprising: S5: the second container generates a structured security event log, which comprises the ID of the first container, the hash digest in the latest time-limited credential, the verification result, the request time and the request load data.
8. A system for implementing container micro-isolation based on trusted state, comprising: Comprising: an incremental attestation submission module configured to cause the first container to periodically submit an incremental attestation to a trusted verification module; a trusted verification and credential return module configured to cause the trusted verification module to perform a trusted verification based on the incremental attestation, generate a time-limited credential upon a successful verification, and return the time-limited credential to the first container; a request load data sending module configured to cause the first container to send a request to a second container, and the sent request load data includes the latest time-limited credential; a credential verification module configured to cause the second container to verify the validity of the latest time-limited credential, if valid, accept the request load data and hand over the request load data to a business processing module for processing, if expired or invalid, discard the request load data.
9. An apparatus for implementing container micro-isolation based on trusted state, comprising: comprising: one or more processors; memory for storing one or more programs; when the one or more programs are executed by the one or more processors, cause the one or more processors to implement the method for implementing container micro-segmentation based on a trusted state as claimed in any one of claims 1-7.
10. A computer-readable storage medium having stored thereon a computer program, characterized in that, the program, when executed by the processor, implements the steps of the method for implementing container micro-segmentation based on a trusted state as claimed in any one of claims 1-7.