A webhook-based cloud-native trust measurement method, system and storage medium
By dynamically deploying a trusted metrics admission controller in Kubernetes and using webhooks and trusted baseline services to verify images, the problem of insufficient image trust in Kubernetes is solved, and secure and trusted metrics of images and security assurance of container content are achieved.
Patent Information
- Application Number
- CN202310058311.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-01-17
- Publication Date
- 2025-12-05
- Estimated Expiration
- 2043-01-17
AI Technical Summary
Kubernetes lacks a reliable trust measurement mechanism, which cannot effectively ensure the trustworthiness and integrity of container images, resulting in insufficient security.
Dynamically deploy a Trusted Metrics Admission Controller in a Kubernetes cluster. Use a webhook mechanism to hook image deployment requests and obtain the latest Trusted Metrics baseline value through the Trusted Baseline Value Security Release and Verification Service to verify the trustworthiness of the image and allow or deny the image deployment request.
It implements a trust metric that is highly versatile, compatible, and flexible in Kubernetes, ensuring the security and trustworthiness of images, guaranteeing the security of container content in cloud computing application scenarios, and supporting fine-grained control and image integrity verification.
Smart Images

Figure CN116208383B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application belongs to the technical field of cloud security, and particularly relates to a cloud native trust measurement method and system based on webhook and a storage medium. BACKGROUND
[0002] The trust measurement technology is one of important means for solving the problems of untrusted computing environment and lack of deep security protection of network security, and can provide the system with safe immunity ability by performing security protection while performing operation.
[0003] When a pod is started by Kubernetes, the pod can pull a container image from various different container image repositories. Since the containers can access some host resources in the process of sharing the host kernel, it is crucial for security to ensure that the trusted container image is run in the system. In order to confirm whether the container image is trusted and whether the container image is complete, it is necessary to perform a forced image security policy to perform trust measurement on the image pulled by the pod. However, there is no reliable trust measurement mechanism in Kubernetes. SUMMARY
[0004] In order to solve the problems in the prior art, the application provides a cloud native trust measurement method and system based on webhook and a storage medium, which first adds a trust measurement mechanism in Kubernetes, has the characteristics of strong universality, good compatibility, high flexibility, etc., and can realize the trust measurement of cloud native on the basis of small modification, ensure that the image deployed by the deployment personnel is safe and trusted, and realize the security and trust of the container content in the cloud computing application scenario.
[0005] To achieve the above purpose, the technical scheme adopted by the application is as follows:
[0006] In a first aspect, a cloud native trust measurement method based on webhook is provided, and a trust measurement admission controller is dynamically deployed in a Kubernetes cluster, the method is executed by the trust measurement admission controller dynamically deployed in the Kubernetes cluster, and includes the following steps: obtaining all image deployment requests from a Kube interface service; obtaining the latest trust measurement benchmark value matched with the image deployment request from a trusted benchmark value security publishing and verification service; verifying whether the image to be deployed in the image deployment request is trusted by using the trust measurement benchmark value, and if the image is trusted, allowing the image deployment request.
[0007] Further, the trusted measurement benchmark value is obtained through the trusted benchmark value security publishing and verification service matched with the image deployment request, specifically: when the image deployment request contains a pod and the operation type is creation or modification, for each image in the pod, a matching security policy is obtained; if no matching security policy is obtained, the current image deployment request is released and the trusted measurement is ended; if a matching security policy is obtained, a new HTTP request is initiated to the trusted benchmark value security publishing and verification service for each image GUN to request the latest trusted measurement benchmark value of the image.
[0008] Further, the image deployment request is verified through the trusted measurement benchmark value to determine whether the image requested to be deployed is trusted, specifically: after obtaining the trusted measurement benchmark value matched with the image deployment request and successfully verifying the signature, the format of the GUN in the image deployment request is modified, and the modified image deployment request is sent to the Kube interface service, so that the Kube interface service completes the creation or modification process according to the modified image deployment request.
[0009] Further, the image deployment request includes a trusted measurement object; wherein the trusted measurement object is identified by a globally unique name GUN, and the structure of the GUN identifier is “[source repository of the image] / [image name]:[image version]”.
[0010] Further, the image deployment request includes a target namespace of the trusted measurement; the scope of the trusted measurement is the specified namespace or the entire cluster; when the target namespace is configured with a trusted measurement policy, the configured trusted measurement policy is used as the reference; when the target namespace is not configured with a trusted measurement policy, the trusted measurement policy of the cluster is used as the reference.
[0011] In a second aspect, a method for publishing an image trusted benchmark value is provided, which is executed by a trusted benchmark value security publishing and verification server, and includes: obtaining new metadata uploaded by a user, the new metadata being data signed by an image maker locally for an image; verifying the new metadata by using metadata of the corresponding image stored in a server database; generating a timestamp and a snapshot of the new metadata after the verification is passed; signing the generated timestamp and snapshot by using a private key stored in a signature service database; and storing the new metadata and the signed timestamp and snapshot in the server database as the latest trusted measurement benchmark value, which is used for calling by an image user to verify whether the signature of a to-be-deployed image is correct.
[0012] In a third aspect, a webhook-based cloud-native trust measurement system is provided, comprising: a Kubernetes cluster, in which a trust measurement admission controller is dynamically deployed, the trust measurement admission controller being configured to obtain all image deployment requests from a Kube interface service, obtain the latest trust measurement benchmark value matching the image deployment request from a trust benchmark secure release and verification service, verify whether the image to be deployed in the image deployment request is trustworthy by using the trust measurement benchmark value, and if so, allow the image deployment request.
[0013] Further, the trust measurement admission controller comprises: an image deployment request obtaining module configured to obtain all image deployment requests from the Kube interface service; a trust measurement benchmark value module configured to obtain the latest trust measurement benchmark value matching the image deployment request from the trust benchmark secure release and verification service; and an image deployment request verification module configured to verify whether the image to be deployed in the image deployment request is trustworthy by using the trust measurement benchmark value, and if so, allow the image deployment request.
[0014] Further, the webhook-based cloud-native trust measurement system further comprises a trust benchmark secure release and verification service; and the trust measurement admission controller dynamically deployed in the Kubernetes cluster is a custom webhook admission controller based on a MutatingAdmissionWebhook admission controller and a ValidatingAdmissionWebhook admission controller in a Kubernetes API server.
[0015] The MutatingAdmissionWebhook admission controller is configured to send an admission request to the trust benchmark secure release and verification service, obtain the latest trust measurement benchmark value matching the image deployment request, and modify the object by creating a patch before returning an admission response; and the ValidatingAdmissionWebhook admission controller is configured to reject the image deployment request if the image to be deployed in the image deployment request is determined to be untrustworthy by the trust measurement benchmark value.
[0016] In a fourth aspect, a computer-readable storage medium is provided, comprising a stored computer program, wherein when the computer program is run by a processor, the computer program controls a device in which the storage medium is located to perform the method of the first aspect.
[0017] Compared with the prior art, the present application has the following beneficial effects:
[0018] (1) This invention is based on a trusted measurement admission controller dynamically deployed in a Kubernetes cluster. It hooks all image deployment requests through a webhook mechanism, obtains the latest trusted measurement benchmark value through a trusted benchmark value security release and verification service, and verifies whether the image requested for deployment in the image deployment request is trustworthy through the trusted measurement benchmark value. This invention adds a trusted measurement mechanism to Kubernetes for the first time. It has the characteristics of strong universality, good compatibility and high flexibility. It can realize cloud-native trusted measurement with minimal modifications, ensure that the images deployed by the deployment personnel are safe and trustworthy, and realize the safe and trustworthy container content in cloud computing application scenarios.
[0019] (2) Based on webhook technology, this invention can realize dynamic deployment and strategy configuration, and can perform fine-grained control over container images;
[0020] (3) The trusted measurement technology used in this invention can restrict only authorized images signed by a specific publisher to be deployed, verify the integrity of the images in use, and effectively ensure the security of the cluster. Attached Figure Description
[0021] Figure 1 This is a schematic diagram of the structure of a cloud-native trust measurement method based on webhook provided in an embodiment of the present invention;
[0022] Figure 2 This is an explanatory diagram of a webhook in an embodiment of the present invention;
[0023] Figure 3 This is a flowchart of the trusted benchmark value secure release and verification service in an embodiment of the present invention. Detailed Implementation
[0024] The present invention will be further described below with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of the present invention.
[0025] Example 1:
[0026] like Figure 1 As shown, a cloud-native trusted measurement method based on webhooks is described. A trusted measurement admission controller is dynamically deployed in the Kubernetes cluster. The method is executed by the trusted measurement admission controller dynamically deployed in the Kubernetes cluster, including: obtaining all image deployment requests from the Kube interface service; obtaining the latest trusted measurement benchmark value matching the image deployment request from the trusted benchmark value security release and verification service; and verifying whether the image requested for deployment in the image deployment request is trusted using the trusted measurement benchmark value. If it is trusted, the image deployment request is allowed.
[0027] Step 1: Based on the Trusted Metrics Admission Controller dynamically deployed in the Kubernetes cluster, hook all image deployment requests through a webhook mechanism.
[0028] Kubernetes admission controllers are code segments used to intercept requests to Kubernetes API services before object persistence, allowing requests to pass through after authentication and authorization. Mutating controllers can modify the resource objects they process, while validating controllers cannot. If any controller in any stage rejects a request, the entire request is immediately rejected, and an error is returned to the end user. While these traditional controllers are powerful, they need to be compiled into kube-apiserver and can only be started when the API server starts. In this embodiment, the webhook-based admission controller can be dynamically deployed and used. The Kubernetes API server includes two special admission controllers: MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These two webhook controllers send admission requests to an external HTTP callback service and receive an admission response. Figure 2 As shown, this illustrates the lifecycle of the Kubernetes API server and the scope of the webhook-based Trust Metrics Admission Controller within its lifecycle.
[0029] The Trusted Measurement Admission Controller consists of the two webhook-based admission controllers mentioned above. Before deploying the Trusted Measurement Admission Controller, you first need to enable the MutatingAdmissionWebhook and ValidatingAdmissionWebhook webhook admission controllers in kube-apiserver.
[0030] The MutatingAdmissionWebhook admission controller can modify the object by creating a patch before returning an admission response, while the ValidatingAdmissionWebhook admission controller can reject the request, but they cannot modify the object obtained in the admission request.
[0031] Step 2: Obtain the latest trusted benchmark values through the Trusted Benchmark Value Security Release and Verification Service.
[0032] The server side of the image trusted baseline secure publishing and verification service is responsible for storing and updating metadata signed by the image publisher. This metadata is stored in the server relational database (Server DB).
[0033] The Signer of the Mirror Trusted Benchmark Secure Publishing and Verification Service is responsible for storing the private keys used to sign server-side metadata. These private keys are stored in the Signer Relational Database (Signer DB).
[0034] like Figure 3 As shown, this illustrates the process of a mirror publisher uploading signed metadata and the process of a client requesting the latest metadata.
[0035] Trusted benchmark values are stored by an independent trusted benchmark secure publishing and verification service. After signing the image locally, the image creator uploads the metadata to the server to sign the timestamp / snapshot and save it. Image users obtain the latest metadata from the server and verify whether the signature of the specified image is correct.
[0036] It should be noted that this service is implemented and used according to the TUF framework, a general design methodology for secure software distribution and updates. By using the TUF framework, this service can achieve a high level of security.
[0037] Step 3: Verify the trustworthiness of the image requested in the image deployment request using a trustworthiness metric benchmark. If the image is trustworthy, allow the image deployment request; otherwise, reject the image deployment request.
[0038] After deploying the Trusted Metrics Admission Controller, every request sent by the Kubernetes API server goes through the Trusted Metrics Admission Controller. The Trusted Metrics process is as follows:
[0039] (1) When a request contains a pod and the operation type is create or modify, a check is triggered. For each image in the pod, the Trusted Measurement Admission Controller attempts to find a matching security policy. If a security policy is matched, proceed to the next step. If no security policy is matched, end the current Trusted Measurement and allow the current request.
[0040] (2) After a security policy is matched, the Trusted Metrics Admission Controller initiates a new HTTP request to the Trusted Benchmark Value Security Release and Verification Service for each image’s GUN, requesting to obtain the latest metadata of the image.
[0041] (3) If the latest metadata is obtained and the signature is successfully verified, the digest corresponding to the GUN in the request is passed to the next step of processing; otherwise, the request is stopped and an error is reported.
[0042] (4) The Trusted Measurement Admission Controller modifies the image's GUN to a fixed format: registry / project@sha256: digest based on the received digest, and sends the modified request to the Kubernetes API server.
[0043] The Kubernetes API server continues the creation or modification process, pulls images from the container image repository, and completes the deployment.
[0044] In this embodiment, the scope of trusted measurement is a specified namespace or the entire cluster; when a trusted measurement policy is configured for a certain namespace, the configured trusted measurement policy shall prevail; when a trusted measurement policy is not configured for a certain namespace, the trusted measurement policy of the cluster shall prevail.
[0045] In this embodiment, the object of the trust measurement is identified by a globally unique name, denoted as the GUN identifier. The structure of the GUN identifier is "[source repository of the image] / [image name]:[image version]".
[0046] This embodiment, based on webhook technology, enables dynamic deployment and policy configuration, allowing for fine-grained control over container images. The trusted measurement technology used in this embodiment restricts deployment to only authorized images signed by specific publishers, verifying the integrity of images in use and effectively ensuring cluster security. This embodiment is the first to add a trusted measurement mechanism to Kubernetes, offering strong versatility, good compatibility, and high flexibility. It allows for cloud-native trusted measurement with minimal modifications, ensuring the security and trustworthiness of images deployed by personnel and achieving secure and trustworthy container content in cloud computing application scenarios.
[0047] Example 2:
[0048] Based on the webhook-based cloud-native trusted measurement method described in Embodiment 1, this embodiment provides a webhook-based cloud-native trusted measurement system, including: a Kubernetes cluster, in which a trusted measurement admission controller is dynamically deployed. The trusted measurement admission controller is used to obtain all image deployment requests from the Kubernetes interface service; obtain the latest trusted measurement benchmark value matching the image deployment request from the trusted benchmark value security release and verification service; and verify whether the image requested for deployment in the image deployment request is trusted using the trusted measurement benchmark value. If it is trusted, the image deployment request is allowed.
[0049] Furthermore, the Trusted Measurement Admission Controller includes an image deployment request acquisition module, used to acquire all image deployment requests from the Kube interface service; a Trusted Measurement Benchmark module, used to acquire the latest Trusted Measurement Benchmark value matching the image deployment request from the Trusted Benchmark Value Security Release and Verification Service; and an Image Deployment Request Verification module, used to verify whether the image requested for deployment in the image deployment request is trustworthy using the Trusted Measurement Benchmark value, and if trustworthy, to allow the image deployment request.
[0050] Furthermore, the cloud-native trusted measurement system based on webhook also includes a trusted baseline value secure release and verification service; the trusted measurement admission controller dynamically deployed in the Kubernetes cluster is a custom webhook admission controller implemented based on the MutatingAdmissionWebhook admission controller and the ValidatingAdmissionWebhook admission controller in the Kubernetes API server.
[0051] The MutatingAdmissionWebhook admission controller is used to send an admission request to the Trusted Benchmark Value Security Release and Verification Service, obtain the latest Trusted Benchmark Value that matches the image deployment request, and modify the object by creating a patch before returning the admission response; the ValidatingAdmissionWebhook admission controller is used to reject the image deployment request after verifying that the image requested for deployment in the Trusted Benchmark Value image deployment request is untrusted.
[0052] Example 3:
[0053] Based on the webhook-based cloud-native trusted measurement method described in Embodiment 1, this embodiment provides a method for publishing a trusted benchmark value for an image. This method is executed by a trusted benchmark value secure publishing and verification server, and includes: acquiring new metadata uploaded by a user, wherein the new metadata is data signed by the image creator locally; verifying the new metadata using the corresponding image's metadata stored in the server-side database; generating a timestamp and snapshot of the new metadata after successful verification; signing the generated timestamp and snapshot using a private key stored in the signature service database; and then storing the new metadata and the signed timestamp and snapshot in the server-side database as the latest trusted measurement benchmark value, which can be called by image users to verify whether the signature of the image to be deployed is correct.
[0054] Example 4:
[0055] Based on the cloud-native trust measurement method based on webhook described in Embodiment 1, this embodiment provides a computer-readable storage medium, which includes a stored computer program, wherein the computer program, when run by a processor, controls the device where the storage medium is located to execute the method described in Embodiment 1.
[0056] Embodiments of this application may be provided as methods, systems, or computer program products. Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in the embodiments of this application may be implemented in various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.
[0057] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0058] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0059] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0060] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.
[0061] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. A cloud-native trust measurement method based on webhooks, characterized in that, A trusted metric admission controller is dynamically deployed in a Kubernetes cluster. The method is executed by the dynamically deployed trusted metric admission controller in the Kubernetes cluster, including: Retrieve all image deployment requests from the Kube API service; Obtain the latest trusted benchmark values that match the image deployment request from the Trusted Benchmark Security Release and Verification Service; Verify the trustworthiness of the image requested in the image deployment request using a trustworthiness benchmark value. If the image is trustworthy, allow the image deployment request. Specifically, the trustworthiness of the image requested for deployment in the image deployment request is verified using a trustworthiness metric benchmark value. After obtaining a trusted metric benchmark value that matches the image deployment request and successfully verifying the signature, the format of GUN in the image deployment request is modified, and the modified image deployment request is sent to the Kube interface service so that the Kube interface service can complete the creation or modification of the process based on the modified image deployment request.
2. The cloud-native trust measurement method based on webhook according to claim 1, characterized in that, The trusted benchmark value is obtained through the trusted benchmark value security release and verification service to match the image deployment request, specifically: When an image deployment request contains a pod, and the operation type of the pod is creation or modification, then for each image in the pod, obtain the matching security policy. If no matching security policy is found, the current trust measurement will end and the current image deployment request will be allowed. If a matching security policy is obtained, a new HTTP request is initiated to the Trusted Benchmark Value Security Release and Verification Service for each image's GNU system to request the latest trusted benchmark value for that image.
3. The cloud-native trust measurement method based on webhook according to claim 1, characterized in that, The image deployment request includes a trusted measurement object; the trusted measurement object is identified by a globally unique name GUN identifier, the structure of which is "[source repository of the image] / [image name]:[image version]".
4. The cloud-native trust measurement method based on webhook according to claim 1, characterized in that, The image deployment request includes the target namespace of the trusted metric; the scope of the trusted metric can be the specified namespace or the entire cluster. When a trusted measurement policy is configured for the target namespace, the configured trusted measurement policy shall prevail. When the target namespace does not have a trusted measurement policy configured, the trusted measurement policy of the cluster shall prevail.
5. The cloud-native trust measurement method based on webhook according to claim 1, characterized in that, The publication of trusted benchmark values is performed by the trusted benchmark value security publication and verification server, including: The system retrieves new metadata uploaded by the user. This new metadata is the data signed by the image creator locally. The system then verifies the new metadata using the metadata of the corresponding image stored in the server-side database. After successful verification, a new timestamp and snapshot of metadata are generated. The generated timestamp and snapshot are then signed using the private key stored in the signature service database. The new metadata, along with the signed timestamp and snapshot, are then stored in the server-side database as the latest trusted benchmark value, which can be called by image users to verify whether the signature of the image to be deployed is correct.
6. A cloud-native trust measurement system based on webhooks, characterized in that, include: The Kubernetes cluster dynamically deploys a Trusted Metrics Admission Controller, which is used to obtain all image deployment requests from the Kube interface service. Obtain the latest trusted benchmark values that match the image deployment request from the Trusted Benchmark Security Release and Verification Service; Verify the trustworthiness of the image requested in the image deployment request using a trustworthiness benchmark value. If the image is trustworthy, allow the image deployment request. Specifically, the trustworthiness of the image requested for deployment in the image deployment request is verified using a trustworthiness metric benchmark value. After obtaining a trusted metric benchmark value that matches the image deployment request and successfully verifying the signature, the format of GUN in the image deployment request is modified, and the modified image deployment request is sent to the Kube interface service so that the Kube interface service can complete the creation or modification of the process based on the modified image deployment request.
7. The cloud-native trust measurement system based on webhook according to claim 6, characterized in that, Trusted metric admission controller, including: The image deployment request acquisition module is used to obtain all image deployment requests from the Kube interface service; The Trusted Metrics Benchmark module is used to obtain the latest Trusted Metrics Benchmark that matches the image deployment request from the Trusted Benchmarks Security Release and Verification Service; The image deployment request verification module is used to verify whether the image requested for deployment in the image deployment request is trustworthy using a trust metric benchmark value. If it is trustworthy, the image deployment request is allowed.
8. The cloud-native trust measurement system based on webhook according to claim 6, characterized in that, The cloud-native trusted measurement system based on webhook also includes a trusted benchmark value secure publishing and verification service; The Trusted Metrics Admission Controller, dynamically deployed in the Kubernetes cluster, is a custom webhook admission controller implemented based on the MutatingAdmissionWebhook and ValidatingAdmissionWebhook admission controllers in the Kubernetes API server. The MutatingAdmissionWebhook admission controller is used to send an admission request to the Trusted Benchmark Value Security Release and Verification Service, obtain the latest trusted benchmark value that matches the image deployment request, and modify the object by creating a patch before returning the admission response; The ValidatingAdmissionWebhook admission controller is used to reject an image deployment request if the requested image is found to be untrusted in the image deployment request using a trust metric benchmark.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein when the computer program is executed by a processor, it controls the device in which the storage medium is located to perform the method according to any one of claims 1 to 5.
Citation Information
Patent Citations
Container mirror image compliance inspection method and system for container cloud platform
CN115495196A
Preventing unauthorized package deployment in clusters
US20210397712A1