Pre-generation security injection and verification method and system for cloud application template

Abstract

The invention provides a pre-generation security injection and verification method and system for a cloud application template. The method comprises the following steps: acquiring an original cloud application template; a security special configuration file is injected into the original cloud application template to generate an intermediate template containing the security special configuration file; based on real-time threat intelligence and an external compliance reference, dynamically reinforcing the intermediate template to generate a reinforced template; carrying out beforehand compliance verification on the reinforced template, and calling a strategy engine to carry out strategy rule verification in a simulation rendering stage; and according to a verification result, if the verification is passed, pushing the reinforced template to a safe warehouse. According to the method, security configuration and compliance check are preposed before template rendering, so that the problems of hysteresis, low efficiency, configuration drift and the like in a traditional security process are solved.

Description

Technical Field

[0001] This application relates to the field of cloud-native application technology, and in particular to a method and system for pre-generating security injection and verification of cloud application templates. Background Technology

[0002] With the rapid development of cloud computing technology, cloud-native applications, with their high elasticity, scalability, and ease of deployment, have become a core support for enterprise digital transformation and are widely used in various industries such as finance, manufacturing, and the internet. In the deployment process of cloud-native applications, template-based deployment tools such as Helm have become the mainstream choice in the industry because they can simplify the packaging, release, and management of applications in Kubernetes clusters. Cloud application templates (such as Helm Charts) serve as the core carrier for application deployment, and the security and compliance of their configuration directly determine the stability and risk controllability of application operation.

[0003] To ensure the security of cloud-native applications, existing technologies have developed a series of routine security practices. However, these practices have significant shortcomings in terms of protection timeliness, configuration consistency, delivery efficiency, and compliance adaptability, making it difficult to meet the security and efficiency requirements of large-scale, high-frequency deployment scenarios of cloud-native applications. Therefore, there is an urgent need for a technical solution that can address these issues at the source, enabling proactive security empowerment and efficient compliance verification of cloud application templates. This has become a pressing technical challenge in this field. Summary of the Invention

[0004] In view of this, this application proposes a pre-generation security injection and verification method, system, device, and storage medium for cloud application templates. By moving security configuration and compliance checks to before template rendering, it solves the problems of lag, low efficiency, and configuration drift in traditional security processes.

[0005] Firstly, this application provides a pre-generated security injection and verification method for cloud application templates, including: Obtain the original cloud application template; An intermediate template containing a security-specific configuration file is generated by injecting a security-specific configuration file into the original cloud application template. Based on real-time threat intelligence and external compliance benchmarks, the intermediate template is dynamically hardened to generate a hardened template. The reinforced template is subjected to pre-compliance verification, and the strategy engine is called to verify the strategy rules during the simulation rendering stage. If the verification results are successful, the reinforced template will be pushed to the security repository.

[0006] As described above, the cloud application template pre-generation security injection and verification method provided in this application fundamentally eliminates the risk of deploying applications containing known security vulnerabilities or non-compliant configurations to the runtime environment by placing security metadata injection, dynamic hardening, and pre-compliance verification before template rendering. Furthermore, it ensures the immutability of template metadata through digital signatures, achieves proactive defense capabilities through dynamic hardening combined with real-time threat intelligence, and significantly reduces the risk of human operation through pre-verification and automated push mechanisms. Ultimately, it constructs a template management system that is secure from the moment it is generated, realizing full lifecycle security protection for cloud application templates.

[0007] Optionally, generating the intermediate template containing the security-specific configuration file specifically includes: Parse the directory structure and file content of the original cloud application template; A security-specific configuration file is generated under the directory structure of the original cloud application template. This security-specific configuration file is used to define the default values ​​and policy switches for security attributes. The metadata of the original cloud application template is digitally signed.

[0008] As described above, by parsing the template and automatically generating an independent security-specific configuration file, security policies are decoupled from business configurations, facilitating independent management, version control, and auditing. Furthermore, by digitally signing the template metadata, the authenticity of the template's source and the integrity of its content can be verified at any subsequent stage, effectively defending against supply chain attacks and configuration tampering, and providing a trusted foundation for security processes.

[0009] Optionally, the security-specific configuration file includes at least one of the following configuration items: ISM schema version, security level preset reference, least privilege enable switch, read-only root file system enforce switch, list of allowed capabilities, list of required capabilities, cryptographic specification configuration, image repository whitelist, and image digest enforce use switch.

[0010] In summary, by defining configuration items covering key dimensions such as ISM version, security level, access control, image security, and password standards, a complete and programmable security baseline specification has been established for cloud application templates. Furthermore, it supports the rapid application of security policy packages of varying strengths to different application scenarios through methods such as pre-defined security level references, thereby improving the efficiency and consistency of policy management. Optionally, the dynamic reinforcement specifically includes: Access real-time threat intelligence and external compliance benchmark APIs; Based on the real-time threat intelligence feedback and external compliance benchmarks, the content of the intermediate template is analyzed, a security patch file is generated and applied in situ to the intermediate template to generate the hardened template.

[0011] As described above, by connecting to external threat intelligence and compliance benchmark APIs, the hardening strategy can respond instantly to new vulnerabilities, attack methods, or regulatory changes, ensuring that security measures are always up-to-date. Furthermore, based on external intelligence, the template content is analyzed and differentiated patches are generated, achieving precise hardening and improving the template's adaptability to dynamic threats.

[0012] Optionally, the security patch file includes at least one of the following configuration items: Force the container to run as a non-root user, enable the default Seccomp configuration file, disable privilege escalation for container processes, and remove all Linux capabilities.

[0013] In summary, by implementing progressively more detailed patch configurations, such as forcing non-root operation, disabling privilege escalation, removing all Linux capabilities, and enabling Seccomp, the attack surface is significantly compressed from multiple levels by strictly adhering to the principle of least privilege. Furthermore, by transforming complex runtime security configurations that were originally manually written and prone to errors into standardized patches that can be automatically injected, the comprehensive implementation of security best practices in high-frequency delivery is ensured.

[0014] Optionally, the prior compliance verification specifically includes: The reinforced template is simulated and rendered. The OPA strategy engine is invoked to automatically verify the simulated and rendered template based on predefined strategy rules and output a compliance report.

[0015] As described above, by calling the OPA policy engine for verification during the simulation rendering phase, the compliance status after deployment can be accurately predicted without actually starting resources, and non-compliant versions can be blocked in a timely manner to prevent their deployment. Furthermore, by automatically generating detailed compliance reports, the verification basis, results, and failed items are clearly recorded, providing structured evidence for security audits and issue tracing.

[0016] Optionally, the predefined policy rules are encoded using OPA's Rego declarative language, including at least one of image repository compliance rules, permission configuration compliance rules, cryptographic specification compliance rules, and system call restriction compliance rules.

[0017] As described above, by utilizing OPA's Rego declarative language, complex logical relationships can be encoded to meet various compliance requirements ranging from simple checks to complex business logic. Rules for different areas such as images, permissions, passwords, and system calls can be modularized, allowing the policy library to be flexibly combined, inherited, and reused like code, greatly improving the efficiency and maintainability of policy management.

[0018] Optional, also includes: If the verification fails, the process will terminate and an alarm will be automatically triggered, a compliance report will be generated and sent to the preset notification terminal.

[0019] As a result, when the verification fails, an alarm is automatically triggered and a report is pushed, ensuring that relevant development, operation and maintenance and security personnel can know the details of the problem as soon as possible, so as to immediately start the repair process, which greatly shortens the average repair time of security incidents.

[0020] Secondly, this application provides a pre-generated security injection and verification system for cloud application templates, including: The template acquisition module is used to obtain the original cloud application template; A security injection module is used to inject a security-specific configuration file into the original cloud application template to generate an intermediate template containing the security-specific configuration file. The dynamic hardening module is used to dynamically harden the intermediate template based on real-time threat intelligence and external compliance benchmarks, and generate a hardened template. The compliance verification module is used to perform pre-compliance verification on the reinforced template and to call the strategy engine to verify the strategy rules during the simulation rendering stage. The release control module is used to push the reinforced template to the security repository if the verification result is passed.

[0021] Thirdly, this application provides a computing device, the computing device comprising: processor; Memory, used to store one or more programs; When the processor executes one or more programs, it enables the processor to implement the above-described method for pre-generating security injection and verification of cloud application templates.

[0022] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a computer, implements the aforementioned method for pre-generating security injection and verification of a cloud application template.

[0023] These and other aspects of this application will become more apparent in the description of the following embodiments(s). Attached Figure Description

[0024] Figure 1 A flowchart illustrating a pre-generation security injection and verification method for a cloud application template provided in this application embodiment; Figure 2 This application provides a structural diagram of a pre-generated security injection and verification system for cloud application templates. Figure 3 This is a structural diagram of a computing device provided in an embodiment of this application.

[0025] It should be understood that the dimensions and shapes of the block diagrams in the above structural diagrams are for reference only and should not constitute an exclusive interpretation of the embodiments of this application. The relative positions and inclusion relationships between the block diagrams presented in the structural diagrams are only schematic representations of the structural relationships between the block diagrams, and are not intended to limit the physical connection methods of the embodiments of this application. Detailed Implementation

[0026] The technical solutions provided in this application will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the system architecture and business scenarios provided in the embodiments of this application are mainly for illustrating possible implementations of the technical solutions of this application and should not be construed as the sole limitation on the technical solutions of this application. Those skilled in the art will recognize that the technical solutions provided in this application are equally applicable to similar technical problems as system architectures evolve and new business scenarios emerge.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. In case of any inconsistency, the meaning set forth in this specification or derived from the content described herein shall prevail. Furthermore, the terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit the scope of this application.

[0028] The solutions provided in this application will now be described in detail with reference to the accompanying drawings and embodiments.

[0029] This application proposes a pre-generation security injection and verification method and system for cloud application templates. It transforms the security and compliance assurance of cloud-native applications from the traditional post-deployment detection and remediation model to a pre-generation model involving injection and verification before rendering. Through this application, all necessary security policy injection, dynamic hardening based on real-time threat intelligence, and pre-verification based on the latest compliance benchmarks can be completed before the actual application deployment manifest is generated, thereby ensuring the security, compliance, and efficiency of application deployment from the source.

[0030] like Figure 1 As shown, this application embodiment provides a pre-generated security injection and verification method for cloud application templates. This method uses the mainstream Helm Chart in the cloud-native field as the cloud application template, employs OPA (Open Policy Agent) as the policy engine, and combines it with automated pipeline tools to achieve full-process automation. It is primarily adapted to application deployment scenarios in Kubernetes cluster environments. (Refer to...) Figure 1 As shown, the method includes: S110: Obtain the original cloud application template.

[0031] In this step, an automated pipeline tool (such as Jenkins) can be used to retrieve the original cloud application template to be released from a version control repository (such as a Git repository) via a pre-defined pipeline script. This template is typically in Helm Chart format and contains core files such as Chart.yaml (metadata file), values.yaml (business configuration file), and templates directory (deployment description files, such as deployment.yaml and service.yaml).

[0032] S120: Generate an intermediate template containing a security-specific configuration file by injecting a security-specific configuration file into the original cloud application template.

[0033] This step aims to embed an independent security policy definition into the original template and ensure the integrity of the template. The injection process of this security metadata specifically includes: Parse the original template structure: use a security injector to parse the directory structure and file content of the original cloud application template to identify entry points that accept external configuration; Generate a security-specific configuration file: Automatically generate a security-specific configuration file (such as security-values.yaml) in the template root directory. This security-specific configuration file is independent of the business configuration file (values.yaml) and is specifically used to define the default values ​​of security attributes and policy switches. Template metadata digital signature: The template's metadata (including the name, version, creation time in Chart.yaml, and the file digest in security-values.yaml) is digitally signed using a digital signature algorithm (such as SHA256 hash algorithm or RSA asymmetric encryption algorithm). The generated signature file (such as signature.bin) is stored in the template's root directory, and a signature digest is added to the annotations field of Chart.yaml to ensure the integrity and immutability of the template's metadata (if a signature mismatch is detected in subsequent processes, the operation will be terminated directly). Output: Generates an intermediate template containing a security-specific configuration file and a digital signature file, completing the security metadata injection.

[0034] In some embodiments, the security-specific configuration file includes multiple configuration items such as ISM schema version, security level preset reference, least privilege enable switch, read-only root file system enforce switch, allowed capability list, required capability list, cryptographic specification configuration, image repository whitelist, and image digest enforce use switch. Among these, the least privilege enable switch and read-only root file system enforce switch implement the least privilege principle from the perspective of permission control and file system protection, reducing the risk of permission abuse and malicious tampering; the image repository whitelist and image digest enforce use switch can block the security risks of pulling infected images from malicious repositories and the tampering or replacement of image tags, ensuring the security of the image supply chain; the cryptographic specification configuration (such as FIPS-140-3) ensures that application data encryption transmission and storage comply with industry compliance standards, meeting the stringent compliance requirements of multiple industries; and the fine-grained capability list configuration (allowed capability list, required capability list) can retain only the Linux capabilities necessary for the application, removing redundant capabilities and reducing the risk of container escape from the system-level permission level.

[0035] S130: Based on real-time threat intelligence and external compliance benchmarks, the intermediate template is dynamically hardened to generate a hardened template.

[0036] This step, based on external real-time intelligence, performs targeted hardening on the intermediate template after the injection of security metadata. This dynamic hardening process specifically includes: Obtaining external data: Call the real-time threat intelligence API and the external compliance benchmark API via HTTP requests. The real-time threat intelligence API returns the latest container security vulnerability information (such as a new container escape vulnerability CVE-2024-XXXX, requiring the disabling of privilege escalation), while the external compliance benchmark API returns the updated security baseline within the enterprise (such as "force containers to run as non-root users" and "enable seccomp default configuration"). Analyze the intermediate template content: The dynamic hardening engine reads the deployment.yaml file in the templates directory of the intermediate template and uses the kube-bench tool to analyze the security risks in the current configuration (such as whether the root user is enabled and whether privilege escalation is allowed). Generate security patch files: Based on external data and risk analysis results, generate security patch files that conform to Kubernetes configuration specifications. For example, this security patch file includes configuration items such as forcing containers to run as non-root users, enabling the default Seccomp configuration file, disabling container process privilege escalation, and removing all Linux capabilities. Forcing containers to run as non-root users can prevent the abuse of root privileges and fundamentally reduce the risk of containers escaping and gaining high privileges on the host. Enabling the default Seccomp configuration file can limit the scope of system calls that containers can call, blocking attack paths related to high-risk system calls. Removing all Linux capabilities can retain only the minimum set of permissions necessary for application operation through the list of required capabilities, maximizing the reduction of the attack surface and further implementing the principle of least privilege. Apply patches in situ: Use Helm plugins (such as helm patch) or the kubectl patch command to replace the corresponding configuration node in deployment.yaml of the intermediate template with the security patch file in situ, and generate a hardened template. This process does not require reconstructing the overall template structure, ensuring that the original business functions of the application are not affected.

[0037] S140: Perform pre-compliance verification on the reinforced template, and call the strategy engine to verify the strategy rules during the simulation rendering stage.

[0038] The pre-compliance verification process in this step can be performed using the Helm simulation rendering tool and the OPA policy engine, and specifically includes: Simulate rendering of the hardened template: By calling Helm's built-in helm template command or similar technology, the hardened template is combined with its configuration values ​​(including security-values.yaml) to render the final Kubernetes resource list, but it is not actually deployed to the cluster; The process involves invoking the OPA policy engine to perform verification: The simulated, rendered resource list is submitted to the OPA (Open Policy Agent) policy engine. This engine loads predefined policy rules written in the Rego declarative language for automated verification and outputs a compliance report, clearly indicating which rule entries passed or failed verification, along with the specific resources involved. These predefined policy rules can cover multiple dimensions, such as image repository compliance rules, permission configuration compliance rules, cryptographic compliance rules, and system call restriction compliance rules.

[0039] S150: If the verification passes, the reinforced template will be pushed to the security repository.

[0040] Based on the compliance report generated by the above steps, when the verification passes, the signed and hardened complete template package (including security-values.yaml and the signature file) will be automatically pushed to a trusted security repository (such as Harbor's HelmChart repository) for direct use in subsequent deployments.

[0041] S160: If the verification fails, terminate the process and generate a compliance report.

[0042] When verification fails, the entire release process is immediately terminated and a compliance report is generated. The system will also automatically trigger an alarm and send the compliance report to a preset notification terminal so that relevant development, operation and maintenance and security personnel can know the details of the problem as soon as possible and start the repair process immediately. This process will not produce any insecure intermediate products.

[0043] Through the above-described processing flow for successful or failed verification, it can be ensured that only compliant templates enter the deployment stage, while non-compliant templates are intercepted and reported in real time, forming a closed-loop management of "verification-decision-disposal".

[0044] In summary, the pre-generation security injection and verification method for cloud application templates provided in this application addresses the core pain point of post-deployment security in traditional cloud application deployments. Through a standardized toolchain and automated process, it completes security configuration injection, dynamic hardening, and compliance verification before the cloud application template is rendered into the actual deployment list. This transforms the security process from post-deployment remediation to pre-deployment defense, ultimately achieving a dual improvement in security and efficiency. It provides a feasible solution for the automation of security compliance for cloud-native applications.

[0045] like Figure 2 As shown, this application also provides a pre-generation security injection and verification system for cloud application templates. This system can be used to implement any step of the above-described pre-generation security injection and verification method for cloud application templates and its optional embodiments, as described above. Figure 2 As shown, the system includes a template acquisition module 210, a security injection module 220, a dynamic hardening module 230, a compliance verification module 240, and a release control module 250.

[0046] The template acquisition module 210 is used to acquire the original cloud application template; the security injection module 220 is used to inject a security-specific configuration file into the original cloud application template to generate an intermediate template containing the security-specific configuration file; the dynamic hardening module 230 is used to dynamically harden the intermediate template based on real-time threat intelligence and external compliance benchmarks to generate a hardened template; the compliance verification module 240 is used to perform pre-compliance verification on the hardened template and call the policy engine to verify policy rules during the simulation rendering stage; the release control module 250 is used to push the hardened template to the security repository if the verification results are passed, and terminate the process and generate a compliance report if the verification fails.

[0047] It should be understood that the systems or modules in the embodiments of this application can be implemented by software, for example, by computer programs or instructions having the above-described functions. The corresponding computer programs or instructions can be stored in the internal memory of the terminal, and the processor reads the corresponding computer programs or instructions from the memory to implement the above functions. Alternatively, the systems or modules in the embodiments of this application can also be implemented by hardware. Or, the systems or modules in the embodiments of this application can also be implemented by a combination of a processor and software modules.

[0048] It should be understood that the processing details of the system or module in the embodiments of this application can be found by referring to... Figure 1 The descriptions of the embodiments and related extended embodiments shown will not be repeated in this application.

[0049] Figure 3 This is a structural diagram of a computing device 1000 provided in an embodiment of this application. The computing device 1000 includes: a processor 1010, a memory 1020, a communication interface 1030, and a bus 1040.

[0050] It should be understood that Figure 3 The communication interface 1030 in the computing device 1000 shown can be used to communicate with other devices.

[0051] The processor 1010 can be connected to the memory 1020. The memory 1020 can be used to store the program code and data. Therefore, the memory 1020 can be a storage unit inside the processor 1010, an external storage unit independent of the processor 1010, or a component that includes both the storage unit inside the processor 1010 and the external storage unit independent of the processor 1010.

[0052] Optionally, the computing device 1000 may also include a bus 1040. The memory 1020 and communication interface 1030 can be connected to the processor 1010 via the bus 1040. The bus 1040 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus 1040 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0053] It should be understood that in the embodiments of this application, the processor 1010 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. Alternatively, the processor 1010 may employ one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0054] The memory 1020 may include read-only memory and random access memory, and provides instructions and data to the processor 1010. A portion of the processor 1010 may also include non-volatile random access memory. For example, the processor 1010 may also store device type information.

[0055] When the computing device 1000 is running, the processor 1010 executes the computer execution instructions in the memory 1020 to perform the operation steps of the above method.

[0056] It should be understood that the computing device 1000 according to the embodiments of this application can correspond to the corresponding subject in executing the methods according to the various embodiments of this application, and the other operations and / or functions of each module in the computing device 1000 are respectively for implementing the corresponding processes of the methods of this embodiment. For the sake of brevity, they will not be described in detail here.

[0057] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. 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.

[0058] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0059] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0060] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0061] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0062] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0063] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to perform the above-described method, which includes at least one of the schemes described in the above embodiments.

[0064] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0065] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0066] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0067] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0068] It should be noted that the embodiments described in this application are merely some embodiments, not all embodiments. The components of the embodiments of this application typically described and shown in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the above detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0069] The terms "first, second, third, etc." or similar terms such as module A, module B, module C, etc., used in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of objects. It is understood that a specific order or sequence may be interchanged where permitted so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0070] In the above description, the labels indicating the steps do not necessarily mean that the steps will be executed. They may include intermediate steps or be replaced by other steps. Where permissible, the order of the steps may be interchanged or executed simultaneously.

[0071] The term "comprising" as used in the specification and claims should not be construed as limiting itself to what follows; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the mentioned feature, integral, step, or component, but does not exclude the presence or addition of one or more other features, integrals, steps, or components, or groups thereof. Thus, the statement "device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0072] The terms "an embodiment" or "an embodiment" as used in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in at least one embodiment of this application. Therefore, the terms "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. Furthermore, in the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between different embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0073] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present application has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, all of which fall within the scope of protection of the present invention.

Claims

1. A method for pre-generating security injection and verification of cloud application templates, characterized in that, The method comprises the following steps: obtaining an original cloud application template; generating an intermediate template containing a security special configuration file by injecting a security special configuration file into the original cloud application template; based on real-time threat intelligence and external compliance benchmarks, dynamically reinforcing the intermediate template to generate a reinforced template; performing pre-compliance verification on the reinforced template, and calling a policy engine for policy rule verification in the simulation rendering stage; if the verification result is passed, pushing the reinforced template to a security warehouse.

2. The method of claim 1, wherein, The generation of the intermediate template containing the security special configuration file specifically comprises the following steps: parsing the directory structure and file content of the original cloud application template; generating a security special configuration file under the directory structure of the original cloud application template, which is used to define the default values and policy switches of security attributes; digitally signing the metadata of the original cloud application template.

3. The method of claim 2, wherein, The security special configuration file comprises at least one of the following configuration items: an ISM schema version, a security level preset reference, a minimum permission enable switch, a read-only root file system forced switch, an allowed capability list, a required capability list, a cryptography specification configuration, an image warehouse whitelist, and an image digest forced use switch.

4. The method of claim 1, wherein, The dynamic reinforcement specifically comprises the following steps: obtaining real-time threat intelligence and external compliance benchmark APIs; based on the real-time threat intelligence feedback and external compliance benchmarks, analyzing the content of the intermediate template, generating a security patch file and applying it to the intermediate template in situ to generate the reinforced template.

5. The method of claim 4, wherein, The security patch file comprises at least one of the following configuration items: forcing the container to run as a non-root user, enabling the default Seccomp configuration file, disabling the container process privilege escalation, and removing all Linux capabilities.

6. The method of claim 1, wherein, The pre-compliance verification specifically comprises the following steps: performing simulation rendering on the reinforced template, calling an OPA policy engine, automatically verifying the simulated rendered template based on pre-defined policy rules, and outputting a compliance report.

7. The method of claim 6, wherein, The pre-defined policy rules are encoded by the Rego declarative language of OPA, and comprise at least one of the following: an image warehouse compliance rule, a permission configuration compliance rule, a cryptography specification compliance rule, and a system call limitation compliance rule.

8. The method of claim 1, wherein, Further comprising: terminating the process and automatically triggering an alarm when the verification fails, generating a compliance report and sending it to a preset notification terminal.

9. A system for pre-generated secure injection and validation of cloud application templates, comprising: The method comprises the following steps: a template acquisition module for obtaining an original cloud application template; a security injection module for injecting a security special configuration file into the original cloud application template to generate an intermediate template containing a security special configuration file; a dynamic reinforcement module for dynamically reinforcing the intermediate template based on real-time threat intelligence and external compliance benchmarks to generate a reinforced template; a compliance verification module for performing pre-compliance verification on the reinforced template and calling a policy engine for policy rule verification in the simulation rendering stage; a release control module for pushing the reinforced template to a security warehouse if the verification result is passed.

10. A computing device, comprising: The method comprises the following steps: a processor; a memory for storing one or more programs; When the one or more programs are executed by the processor, the processor implements a pre-generated secure injection and verification method of a cloud application template as claimed in any one of claims 1 to 8.

Images