Constrained environment container mirror image credible construction method and device, equipment and medium

Abstract

The invention provides a trusted construction method and device for a mirror image of a container in a restricted environment, equipment and a medium. The method comprises the following steps: submitting three types of materials, namely Dockerfile, a dependency list and a project source code, to a version control system; performing static security scanning on the submitted Dockerfile through a vulnerability scanning tool; an authenticated basic mirror image is pulled from a controlled basic mirror image project of a controlled mirror image warehouse, and construction of a service mirror image is completed in combination with the Dockerfile; performing set scanning on the constructed service mirror image; pushing the mirror image passing the compliance check to a mirror image warehouse, and exporting the mirror image as an archived file; in a limited production environment in which only internal necessary services are allowed to be accessed and no extranet access authority exists, loading the mirror image passing the consistency verification, completing container deployment according to the deployment list, and after deployment is completed, carrying out basic operation state verification and service function verification; and the mirror image security is obviously improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for building trusted container images in a confined environment. Background Technology

[0002] With the rapid application of AI technology in the securities industry, enterprises are increasingly demanding AI model inference and data processing services. However, the securities industry has high security requirements, and production environments are typically isolated from the external network, prohibiting developers from performing uncontrolled operations directly on production servers.

[0003] In the current technology landscape, small and medium-sized securities institutions generally face the following challenges: 1. There is a lack of mature DevOps toolchains, making it difficult to introduce professional pipelines and lacking mirror supply chain management capabilities.

[0004] 2. Developers build Docker images themselves, and the content of the images is uncontrollable. They may contain malicious code, unknown dependencies, or untrusted base images.

[0005] 3. The pip source and base image source are not controlled, and the trustworthiness of the dependency source cannot be verified, which poses a risk of supply chain attacks.

[0006] 4. The image lacks a unified version management mechanism, making it impossible to roll back, audit, or reproduce the environment.

[0007] 5. The permissions for development and production environments are mixed, and developers can directly inject images into the production environment, which poses a risk of audit gaps and human error.

[0008] Therefore, existing technologies cannot meet the securities industry's needs for the construction and deployment of secure, traceable, auditable, and source-controllable AI containers. Summary of the Invention

[0009] The technical problem to be solved by the present invention is to provide a method, apparatus, device and medium for building trusted container images in a restricted environment, which significantly improves the security of the images.

[0010] In a first aspect, the present invention provides a method for building a trusted container image in a constrained environment, comprising the following steps: S1. Submit three types of materials to the version control system: Dockerfile, dependency list, and project source code. S2. Perform static security scanning on the submitted Dockerfile using vulnerability scanning tools, and classify and handle the scan results according to preset risk classification rules; the risk classification rules include four levels: severe risk, high risk, medium risk, and low risk, and each level corresponds to different identification scope and handling strategies; S3. Pull the certified base image from the controlled base image project of the controlled image repository, and combine it with the Dockerfile to complete the construction of the service image; S4. Perform a configuration scan on the completed service image. The scan scope includes system-level vulnerabilities, dependency-level vulnerabilities, license agreement compliance, and image configuration compliance. Proceed to the next step only if the scan results meet the preset compliance standards. S5. Push the images that have passed the compliance check to the image repository and manage the versions according to the preset version naming rules; developers only have image pull permissions, while operations and maintenance personnel have full permissions for image push, pull and permission management; S6. Export the image as an archive file, generate and record the hash value of the archive file in the build audit log; transmit it to the production environment through a controlled and secure channel, and recalculate the hash value of the received archive file before deployment and perform a consistency check with the original hash value in the build audit log; S7. In a restricted production environment where access to necessary internal services is permitted but external network access is not allowed, load the image that has passed consistency verification and complete container deployment according to the deployment manifest. After deployment, perform basic operational status verification and business function verification.

[0011] Secondly, the present invention provides a trusted construction apparatus for container images in a constrained environment, comprising: The version control module submits three types of materials to the version control system: Dockerfile, dependency list, and project source code. The static scanning module performs static security scans on the submitted Dockerfile using vulnerability scanning tools, and classifies and handles the scan results according to preset risk classification rules. The risk classification rules include four levels: severe risk, high risk, medium risk, and low risk, with each level corresponding to different identification scopes and handling strategies. The image building module pulls certified base images from the controlled base image project of the controlled image repository and combines them with the Dockerfile to complete the construction of the service image; The vulnerability scanning module performs a pre-defined scan on the completed service image. The scan scope includes system-level vulnerabilities, dependency-level vulnerabilities, license agreement compliance, and image configuration compliance. It proceeds to the next step only if the scan results meet the preset compliance standards. The image management module pushes images that have passed compliance checks to the image repository and manages their versions according to preset version naming rules. Developers only have image pull permissions, while operations and maintenance personnel have full permissions for image push, pull, and permission management. The secure distribution module exports the image as an archive file, generates and records the hash value of the archive file in the build audit log; it then transmits the image to the production environment through a controlled secure channel, recalculates the hash value of the received archive file before deployment, and performs a consistency check with the original hash value in the build audit log. The restricted deployment module loads the image that has passed consistency verification and completes container deployment according to the deployment manifest in a restricted production environment where access to necessary internal services is only permitted and external network access is not allowed. After deployment, it performs basic operational status verification and business function verification.

[0012] Thirdly, the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect.

[0013] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0014] One or more technical solutions provided by this invention have at least the following technical effects or advantages: 1. Preventing the risk of manual injection at the source: Developers only submit Dockerfile, requirements.txt and project code, and do not participate in image building, thus eliminating the security risks introduced by malicious injection or accidental operation on the development side from the process; at the same time, the materials are managed through Git throughout the process to ensure that the submitted content is traceable and rollbackable.

[0015] 2. Multi-layer scanning achieves hierarchical prevention and control: The dual verification mechanism of "static scanning of Dockerfile + full compliance scanning after image building" is adopted, combined with a four-level risk classification strategy. There is "zero tolerance" for serious / high-risk issues, "double confirmation" for medium-risk issues, and "optimization guidance" for low-risk issues. This ensures core security while avoiding excessive control that affects efficiency.

[0016] 3. Trusted base image eliminates supply chain risks: Pulling base images synchronized from official sources from the Harbor controlled repository eliminates vulnerabilities or backdoors introduced by unauthorized or unknown source images; unified base image version management also improves the consistency and reproducibility of service image building.

[0017] 4. Strict isolation of permissions and environment: Harbor repository has clear permission division. Developers only have pull permissions, while operations and maintenance control push and permission management to prevent images from being tampered with or distributed without authorization. The production environment is a restricted network environment with no external network access, avoiding risks such as unauthorized dependency downloads and remote code execution during deployment. Developers cannot access production image files and servers, achieving a three-layer isolation of "development-operations-production".

[0018] 5. End-to-end integrity verification and traceability: The SHA-256 algorithm is used to perform hash verification on the image file, verifying the integrity of the image throughout the entire process from building, transmission to deployment, and preventing tampering during transmission; the construction audit log records key information of the image, and the entire deployment operation is recorded in the audit system, realizing end-to-end traceability of "build-distribution-deployment" and meeting compliance audit requirements.

[0019] 6. Standardized and regulated management: Image naming follows a unified standard, clearly distinguishing between projects, environments, and versions, facilitating image classification, retrieval, and version management; a checklist review is performed before deployment, covering dimensions such as image information, runtime configuration, network configuration, and storage configuration, ensuring that deployment behavior complies with the principle of least privilege and avoiding resource abuse or permission proliferation.

[0020] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0021] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0022] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the device in Embodiment 2 of the present invention.

[0023] Figure 3 This is a diagram of the architecture of the present invention. Detailed Implementation

[0024] The overall concept of the technical solution in this application is as follows: like Figure 3 As shown, this invention proposes a trusted construction and deployment method for container images in restricted network environments within the securities industry. With end-to-end controllability of the "development-build-deployment" chain as its core, it achieves security and trustworthiness through the following key points: 1. Establish role isolation: Developers should only submit Dockerfiles and dependency files and should not build images themselves; the operations team should build the images in a controlled environment.

[0025] 2. Controlled base image system: All images must be based on the official base image in Harbor, and version management and updates must be performed by operations and maintenance personnel.

[0026] 3. Image security scanning: Perform Trivy scans on both the Dockerfile and the built image to block insecure instructions and known vulnerabilities.

[0027] 4. Unified management of pip and software sources: All sources are locked as secure and trusted sources (such as the TUNA Tsinghua source) to ensure that dependencies are traceable.

[0028] 5. Harbor Private Repository Storage and Permission Isolation: Implements strict permission control for test images, production images, and base image spaces. Developers can only pull (download images from the image repository to their local machine, hereinafter referred to as pull), and cannot push (upload locally built images to the image repository, hereinafter referred to as push).

[0029] 6. Deployment in restricted environments: After being packaged by operations and maintenance personnel, the image is transferred to the production environment through controlled channels to ensure that the image has not been tampered with.

[0030] 7. Traceable Deployment and Version Rollback: Each image is named according to specifications and has a fixed version number, supporting historical version auditing and rollback.

[0031] Using the methods described above, even without relying on a professional DevOps toolchain, it is possible to achieve the high-security deployment required by the securities industry.

[0032] I. System Overall Architecture (Virtual Device) The system consists of the following modules: 1. Development and submission module: Developers submit Dockerfile, requirements.txt and service code to the Git repository.

[0033] 2. Dockerfile Static Analysis Module: Operations and maintenance personnel use Trivy to perform static security checks on Dockerfiles.

[0034] 3. Controlled image building module: Operations and maintenance build the target image based on the Harbor base image.

[0035] 4. Image vulnerability scanning module: Uses Trivy to perform vulnerability scanning and compliance checks on the built image.

[0036] 5. Harbor Image Repository Module: Used to store base images, test images, and production images; and provides RBAC permission isolation.

[0037] 6. Image Packaging and Transmission Module: After the image is exported as tar, it is verified and then transmitted to the deployment environment through a controlled channel.

[0038] 7. Deployment and Execution Module: Runs the image as a service according to the deployment documentation.

[0039] 8. Service Verification Module: Develops and verifies whether the deployment is normal.

[0040] II. Methods and Steps Step S1: Developers submit content; Developers only submit: Dockerfile, requirements.txt, and project code, all of which are controlled via Git.

[0041] Developers cannot build images to avoid the risk of "manual injection".

[0042] Step S2: Perform a security scan on the Dockerfile; The operations team uses Trivy to perform static security scans on the Dockerfile and categorizes and processes the scan results according to preset risk classification rules. The scan rules include four risk levels: Critical, High, Medium, and Low. The identification scope and processing strategy for each risk level are as follows: (1) Critical risk The scope of identification includes, but is not limited to: using base images from uncontrolled or unknown sources, executing high-risk instructions as a root user, including instructions that arbitrarily download and execute scripts, such as curl URL|sh or wget URL|bash, the presence of publicly disclosed high-risk RCE (Remote Code Execution) vulnerabilities, and malicious persistence behavior in Dockerfiles (such as adding scheduled tasks or hiding processes). Handling strategy: Immediately halt the build process, return to development for modification, and proceed to the next step only after the operations team has reviewed and confirmed the fix; (2) High risk The scope of identification includes, but is not limited to: using unauthorized but source-identifiable base images, containing high-risk system vulnerabilities (such as high-risk versions of OpenSSL), enabling dangerous capabilities, using uncontrolled software or image sources, and not explicitly specifying dependency version numbers (which may lead to uncontrollable upgrades). Handling strategy: Prohibit the build; modifications must be made before proceeding, and the modifications must be confirmed to have been eliminated in the Trivy scan; (3) Medium risk The scope of identification includes, but is not limited to: medium-risk dependency library vulnerabilities, use of instructions that may reduce the reproducibility of the image (such as apt-get upgrade without version locking), unlocked system package versions, and image bloat caused by failure to clear cache; Handling strategy: The build process can proceed, but it requires confirmation from development and operations. A second scan will be performed after the image is built. If medium-risk vulnerabilities still exist, it is necessary to assess whether to eliminate them. (4) Low risk The scope of identification includes, but is not limited to: low-risk CVEs, images where best practices are not fully followed (e.g., not using .dockerignore), and image size / structural issues that do not affect security; Handling strategy: Allow the build to continue, add "follow-up optimization suggestions" to the deployment documentation, and do not interrupt the main process; Step S3: Build an image based on a controlled base image The operations team pulls base images from Harbor's base-images (pre-stored images pulled from official images), such as ubuntu22.04:v1, python311-slim:v1, and pytorch-cuda12:v2, ensuring the image source is trustworthy. Then, the service image is built based on the base images and the Dockerfile submitted by the developers. Step S4: Image vulnerability scanning and compliance check; After the build is complete, run Trivy scan again: system vulnerabilities, dependency vulnerabilities, license compliance, and configuration compliance; only allow to proceed to the next step after the scan passes.

[0043] Step S5: Push the image to Harbor and perform version management; Mirrors shall be managed in accordance with the following specifications: AI + NLP + Project Name + test / prod + Version Number For example, AI-NLP-reranker-prod-v3, where reranker represents the project name, prod means selecting prod from "test / prod", and v3 indicates the third version. test represents the test environment, and prod represents the production environment.

[0044] Harbor access control: Development (guest): pull only; Operations and maintenance (admin): push / pull / permission management; Step S6: Image packaging and distribution in restricted environments; After exporting an image to a .tar file using the `docker save` command, the operations and maintenance team needs to perform integrity verification on the exported image file to ensure that the image has not been tampered with during transmission. This invention uses SHA-256 as the image integrity verification algorithm. Specific verification rules include: (1) Generation of mirror hash value The operations team executes the following command on the build server: sha256sum[image file name].tar, to obtain the SHA-256 hash value of the image file.

[0045] (2) Construct audit log records Write the following information to the build audit log (which can be a text file, database, or internal audit system): image name, image version number, build time, operations account identifiers involved in the build operation, and SHA-256 image hash value. This log is used to ensure traceability of the build process and prevent duplicate uploads or forged images.

[0046] (3) Controlled channel transmission Image files are only delivered to the restricted production environment through controlled methods (such as internal tiered storage devices, internal cloud disks, and other secure transmission tools), and developers cannot directly access image files or production servers.

[0047] (4) Consistency verification before deployment Before loading the image into the production deployment environment, the operations and maintenance personnel must recalculate the SHA-256 value of the received image file and compare it with the value recorded in the build audit log. The specific steps are as follows: Calculate the hash value on the deployment machine: sha256sum[image file name].tar; If the hash values ​​in the logs match, the `docker load` process is allowed to continue. If the hash values ​​do not match, the deployment process is immediately halted, and a new image transfer request is made. Step S7: Deployment and Validation in Constrained Environments The deployment phase takes place in a restricted production environment, with operations and maintenance personnel performing the deployment operations based on the deployment documentation provided by development. To ensure the security, consistency, and traceability of the deployment environment, this invention adds deployment checklist parsing, security review, and configuration verification steps before deployment. Specifically, this includes the following: (1) Pre-deployment preparation and environmental verification The operations and maintenance team first verifies the received deployment materials, including image files, deployment documents, and related configuration files. The deployment list is then parsed and undergoes a security review, which includes: Image information verification: complete image name (including namespace), image version number, image SHA-256 checksum consistent with build audit logs; runtime configuration review; CPU limits (e.g., CPU quota, CPU shares); memory limits (memory limit / swap limit); container restart policy; process running user (whether a non-root user is used); network configuration review; container internal listening port; host machine port mapping relationship; network mode (bridge / host / none, etc.); whether the scope of inter-service communication complies with the principle of least privilege; storage configuration review; data volume mount list; correspondence between host machine source path and container internal path; data volume permissions (read / write / read-only); environment variable list (including sensitive information check). The above review ensures that the deployment process will not introduce uncontrolled resource access paths or risks of permission proliferation.

[0048] (2) Deployment and execution in a secure isolation environment After reviewing the deployment checklist, operations and maintenance personnel execute the deployment in a restricted production environment. The deployment environment's network is restricted, allowing only access to essential internal services and denying external network access to prevent unauthorized dependency downloads or remote execution risks during deployment.

[0049] Deployment operations include: loading a verified image (docker load), creating a container or orchestrating a service according to the deployment manifest, starting the container, and recording the deployment time and operation account; All deployment operations are recorded in the audit system to ensure that the deployment process is traceable.

[0050] (3) Environmental parameter configuration After the container starts, the operations and maintenance personnel need to configure the production environment parameters according to the deployment checklist, including but not limited to: setting the service running user and permissions, configuring resource limits (such as CPU, memory, IO limits), configuring health checks (livenessProbe / readinessProbe), configuring container log paths and log rotation policies, configuring network ACLs and access whitelists, configuring service startup environment variables, and configuring internal load balancing or service registration information (if any). The above configuration ensures that the service runs securely and stably in a restricted environment.

[0051] (4) Verification after deployment After the container starts, the operations and maintenance personnel need to perform basic verification, including: the liveness status of processes inside the container, the availability of service listening ports, whether logs are output normally, and whether communication with internal dependent services (such as databases and message queues) is normal. After the basic verification is passed, the developers are notified to conduct business-level service verification to confirm that the response results and functions meet expectations.

[0052] The DevOps toolchain is a collection of automated tools that span the entire software development, testing, deployment, and operation lifecycle, aiming to achieve rapid, reliable, and continuous software delivery.

[0053] A Dockerfile is a plain text file containing a series of instructions for automating the building of Docker images.

[0054] The pip source is the mirror repository address for downloading software packages using the Python package manager pip.

[0055] An image is a lightweight, standalone executable package that contains everything needed to run an application: code, runtime, system tools, libraries, and settings.

[0056] Harbor is an enterprise-grade container image repository that provides security, access control, vulnerability scanning, image copying, and other functionalities.

[0057] Trivy is a simple and comprehensive container image vulnerability scanning tool used to detect security vulnerabilities. Other scanning tools can be used instead of the Trivy mentioned in this patent.

[0058] RBAC (Role-Based Access Control) is a type of access control that uses roles to assign permissions, enabling fine-grained permission management.

[0059] Tar is an important file format. Tar stands for "Tape Archive". It was originally designed to combine multiple files and directories together for storage on media such as magnetic tape, but it is now widely used for archiving files.

[0060] The effects of the above embodiments: 1. Development and deployment are completely separated, eliminating the risk of manual injection. Technical characteristics: Only allows operations and maintenance personnel to build images. →Result: Developers are unable to insert malicious commands or hide behaviors into the image, significantly improving security.

[0061] 2. The build process is traceable, and the mirror source is trustworthy. Technical features: • Controlled base image Force commit of Dockerfile Trivy dual scan →Effect: The mirror software supply chain is transparent and reproducible, blocking potential supply chain attacks.

[0062] 3. pip sources and dependency sources are controlled. Technical features: Unified locking of pip source, such as Tsinghua University source. →Effect: Prevents dependency contamination and ensures dependency security and traceability.

[0063] 4. Harbor Private Warehouse Precise Access Control Technical features: Multi-space isolation of test images, production images, and base images. →Result: Developers cannot tamper with the production image; the image can be traced back and version management is unified.

[0064] 5. Achieve highly secure supply chain management without relying on complex DevOps tools. Technical features: Employs lightweight tools (Harbor + Trivy + Dockerfile) →Result: It solves the pain point of small and medium-sized securities firms lacking professional DevOps tools but still needing to deploy them securely.

[0065] 6. Suitable for offline environments and restricted networks Technical features: Images can be transferred in a controlled manner via tar packages. →Result: Meets the common isolation network deployment scenarios in the securities industry. Example 1

[0066] like Figure 1 As shown, this embodiment provides a trusted method for building container images in a restricted environment, including the following steps: S1. Submit three types of materials to the version control system: Dockerfile, dependency list, and project source code. S2. Perform static security scanning on the submitted Dockerfile using vulnerability scanning tools, and classify and handle the scan results according to preset risk classification rules; the risk classification rules include four levels: severe risk, high risk, medium risk, and low risk, and each level corresponds to different identification scope and handling strategies; S3. Pull the certified base image from the controlled base image project of the controlled image repository, and combine it with the Dockerfile to complete the construction of the service image; S4. Perform a configuration scan on the completed service image. The scan scope includes system-level vulnerabilities, dependency-level vulnerabilities, license agreement compliance, and image configuration compliance. Proceed to the next step only if the scan results meet the preset compliance standards. S5. Push the images that have passed the compliance check to the image repository and manage the versions according to the preset version naming rules; developers only have image pull permissions, while operations and maintenance personnel have full permissions for image push, pull and permission management; S6. Export the image as an archive file, generate and record the hash value of the archive file in the build audit log; transmit it to the production environment through a controlled and secure channel, and recalculate the hash value of the received archive file before deployment and perform a consistency check with the original hash value in the build audit log; S7. In a restricted production environment where access to necessary internal services is permitted but external network access is not allowed, load the image that has passed consistency verification and complete container deployment according to the deployment manifest. After deployment, perform basic operational status verification and business function verification.

[0067] In this embodiment, preferably, in step S2, the scope of the serious risk identification includes: using an uncontrolled or unknown source base image, executing high-risk instructions as a root user, including instructions that download and execute remote scripts, the existence of a first-defined remote code execution vulnerability, and malicious persistence behavior contained in the Dockerfile; the handling strategy is to immediately block the image building process, provide feedback to the developers for modification, and proceed to the next step after review and confirmation. In S2, the high-risk identification scope includes: using an unauthorized but identifiable base image, containing system second-set vulnerabilities, enabling dangerous permission capabilities, using uncontrolled software sources, and not explicitly specifying dependency version numbers; the handling strategy is to prohibit the start of the build process, and the build must be modified and resubmitted and verified through a vulnerability scanning tool. In S2, the scope of medium-risk identification includes: third-party setting vulnerabilities in dependency libraries, use of upgrade commands without version locking, unlocked system package versions, and failure to clear cache; the handling strategy is to allow entry into the subsequent build process and perform a secondary scan and evaluation after the image build is completed. In S2, the low-risk identification scope includes: fourth setting vulnerabilities, failure to follow best practices for image building, and image size or structural issues that do not affect security; the handling strategy is to not block the main process and add setting optimization suggestions to the deployment document.

[0068] In this embodiment, preferably, in step S3, the base image in the controlled base image project is an image that has been pulled from the official source and stored in the image repository in advance.

[0069] In this embodiment, preferably, in step S5, the preset version naming rule is formatted as: Project Identifier - Project Name - Environment Identifier - Version Number; wherein, the environment identifier includes a test environment identifier and a production environment identifier.

[0070] In this embodiment, preferably, in step S6, the hash value is calculated using the SHA-256 algorithm; the information recorded in the build audit log includes: image name, image version number, build time, operation and maintenance account identifier, and hash value; the controlled security channels include internal hierarchical storage devices and internal cloud disks.

[0071] In this embodiment, preferably, in step S7, the deployment list needs to undergo a security review before deployment, specifically including: Image information verification: Verify the consistency of the image name, version number, and hash value with the build audit logs; Run configuration review: Review CPU limits, memory limits, container restart policy, and process running users; Network configuration review: Review container listening ports, host port mapping relationships, network modes, and inter-service communication range; Storage configuration review: Review the data volume mount list, the correspondence between host machine and container paths, and the list of data volume permissions and environment variables; After security verification, the deployment checklist will be deployed.

[0072] In this embodiment, preferably, the basic running status verification in S7 includes: verification of the survival status of processes within the container, verification of the availability of service listening ports, verification of normal log output, and verification of the stability of communication with internal dependent services.

[0073] In this embodiment, preferably, in step S7, the deployment operation further includes environment parameter configuration, which includes: setting the service running user and permissions, configuring resource limits, configuring health checks, configuring container log paths and log rotation policies, configuring network access control lists and access whitelists, configuring service startup environment variables, and configuring internal load balancing or service registration information.

[0074] Based on the same inventive concept, this application also provides an apparatus corresponding to the method in Embodiment 1, as detailed in Embodiment 2. Example 2

[0075] like Figure 2 As shown, this embodiment provides a trusted container image building apparatus for constrained environments, including: The version control module submits three types of materials to the version control system: Dockerfile, dependency list, and project source code. The static scanning module performs static security scans on the submitted Dockerfile using vulnerability scanning tools, and classifies and handles the scan results according to preset risk classification rules. The risk classification rules include four levels: severe risk, high risk, medium risk, and low risk, with each level corresponding to different identification scopes and handling strategies. The image building module pulls certified base images from the controlled base image project of the controlled image repository and combines them with the Dockerfile to complete the construction of the service image; The vulnerability scanning module performs a pre-defined scan on the completed service image. The scan scope includes system-level vulnerabilities, dependency-level vulnerabilities, license agreement compliance, and image configuration compliance. It proceeds to the next step only if the scan results meet the preset compliance standards. The image management module pushes images that have passed compliance checks to the image repository and manages their versions according to preset version naming rules. Developers only have image pull permissions, while operations and maintenance personnel have full permissions for image push, pull, and permission management. The secure distribution module exports the image as an archive file, generates and records the hash value of the archive file in the build audit log; it then transmits the image to the production environment through a controlled secure channel, recalculates the hash value of the received archive file before deployment, and performs a consistency check with the original hash value in the build audit log. The restricted deployment module loads the image that has passed consistency verification and completes container deployment according to the deployment manifest in a restricted production environment where access to necessary internal services is only permitted and external network access is not allowed. After deployment, it performs basic operational status verification and business function verification.

[0076] In this embodiment, preferably, the scope of serious risk identification in the static scanning module includes: using an uncontrolled or unknown source base image, executing high-risk instructions as a root user, including instructions that download and execute remote scripts, the existence of a first-defined remote code execution vulnerability, and malicious persistence behavior contained in the Dockerfile; the handling strategy is to immediately block the image building process, provide feedback to the developers for modification, and proceed to the next step after review and confirmation. In the static scanning module, the high-risk identification scope includes: using an unauthorized but identifiable base image, containing system second-set vulnerabilities, enabling dangerous permission capabilities, using uncontrolled software sources, and not explicitly specifying dependency version numbers; the handling strategy is to prohibit the start of the build process, and the image must be modified, resubmitted, and verified by the vulnerability scanning tool. In the static scanning module, the identification scope of medium risk includes: third-party setting vulnerabilities in dependency libraries, use of upgrade commands without version locking, unlocked system package versions, and failure to clear cache; the handling strategy is to allow entry into the subsequent build process and perform a secondary scan and evaluation after the image build is completed. In the static scanning module, the low-risk identification scope includes: fourth-level setting vulnerabilities, failure to follow best practices for image building, and image size or structural issues that do not affect security; the handling strategy is to not block the main process and add setting optimization suggestions to the deployment document.

[0077] In this embodiment, preferably, in the image building module, the base image in the controlled base image project is an image that has been pulled from the official source and stored in the image repository in advance.

[0078] In this embodiment, preferably, the preset version naming rule in the image management module is formatted as: Project Identifier - Project Name - Environment Identifier - Version Number; wherein, the environment identifier includes test environment identifier and production environment identifier.

[0079] In this embodiment, preferably, the hash value in the secure distribution module is calculated using the SHA-256 algorithm; the information recorded in the build audit log includes: image name, image version number, build time, operation and maintenance account identifier, and hash value; the controlled security channels include internal hierarchical storage devices and internal cloud disks.

[0080] In this embodiment, preferably, in the restricted deployment module, the deployment list needs to undergo security review before deployment, specifically including: Image information verification: Verify the consistency of the image name, version number, and hash value with the build audit logs; Run configuration review: Review CPU limits, memory limits, container restart policy, and process running users; Network configuration review: Review container listening ports, host port mapping relationships, network modes, and inter-service communication range; Storage configuration review: Review the data volume mount list, the correspondence between host machine and container paths, and the list of data volume permissions and environment variables; After security verification, the deployment checklist will be deployed.

[0081] In this embodiment, preferably, the basic operational status verification in the restricted deployment module includes: verification of the survival status of processes within the container, verification of the availability of service listening ports, verification of normal log output, and verification of the stability of communication with internal dependent services.

[0082] In this embodiment, preferably, the deployment operation in the restricted deployment module further includes environment parameter configuration, which includes: setting service running users and permissions, configuring resource limits, configuring health checks, configuring container log paths and log rotation policies, configuring network access control lists and access whitelists, configuring service startup environment variables, and configuring internal load balancing or service registration information.

[0083] Since the apparatus described in Embodiment 2 of the present invention is an apparatus used to implement the method of Embodiment 1 of the present invention, those skilled in the art can understand the specific structure and variations of the apparatus based on the method described in Embodiment 1 of the present invention, and therefore will not be described again here. All apparatuses used in the method of Embodiment 1 of the present invention fall within the scope of protection of the present invention.

[0084] Based on the same inventive concept, this application provides an electronic device embodiment corresponding to Embodiment 1, as detailed in Embodiment 3. Example 3

[0085] This embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement any of the implementation methods in Embodiment 1.

[0086] Since the electronic device described in this embodiment is the device used to implement the method in Embodiment 1 of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in Embodiment 1 of this application. Therefore, how the electronic device implements the method in the embodiment of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiment of this application falls within the scope of protection of this application.

[0087] Based on the same inventive concept, this application provides a storage medium corresponding to Embodiment 1, as detailed in Embodiment 4. Example 4

[0088] This embodiment provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it can implement any of the implementation methods in Embodiment 1.

[0089] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied 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.

[0090] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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 illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0091] 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.

[0092] 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.

[0093] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for building a trusted container image in a constrained environment, characterized in that: Includes the following steps: S1. Submit three types of materials to the version control system: Dockerfile, dependency list, and project source code. S2. Perform static security scanning on the submitted Dockerfile using vulnerability scanning tools, and classify and handle the scan results according to preset risk classification rules; the risk classification rules include four levels: severe risk, high risk, medium risk, and low risk, and each level corresponds to different identification scope and handling strategies; S3. Pull the certified base image from the controlled base image project of the controlled image repository, and combine it with the Dockerfile to complete the construction of the service image; S4. Perform a configuration scan on the completed service image. The scan scope includes system-level vulnerabilities, dependency-level vulnerabilities, license agreement compliance, and image configuration compliance. Proceed to the next step only if the scan results meet the preset compliance standards. S5. Push the images that have passed the compliance check to the image repository and manage the versions according to the preset version naming rules; developers only have image pull permissions, while operations and maintenance personnel have full permissions for image push, pull and permission management; S6. Export the image as an archive file, generate and record the hash value of the archive file to the build audit log; The archived files are transmitted to the production environment through controlled and secure channels. Before deployment, the hash value of the received archived files is recalculated and checked for consistency with the original hash value in the build audit log. S7. In a restricted production environment where access to necessary internal services is permitted but external network access is not allowed, load the image that has passed consistency verification and complete container deployment according to the deployment manifest. After deployment, perform basic operational status verification and business function verification.

2. The method for building a trusted container image in a confined environment according to claim 1, characterized in that: In S2, the scope of identification of serious risks includes: using base images from uncontrolled or unknown sources, executing high-risk instructions as a root user, including instructions that download and execute remote scripts, the existence of a first-defined remote code execution vulnerability, and malicious persistence behavior contained in the Dockerfile; the handling strategy is to immediately block the image building process, provide feedback to the developers for modification, and proceed to the next step after review and confirmation. In S2, the high-risk identification scope includes: using an unauthorized but identifiable base image, containing system second-set vulnerabilities, enabling dangerous permission capabilities, using uncontrolled software sources, and not explicitly specifying dependency version numbers; the handling strategy is to prohibit the start of the build process, and the build must be modified and resubmitted and verified through a vulnerability scanning tool. In S2, the scope of medium-risk identification includes: third-party setting vulnerabilities in dependency libraries, use of upgrade commands without version locking, unlocked system package versions, and failure to clear cache; the handling strategy is to allow entry into the subsequent build process and perform a secondary scan and evaluation after the image build is completed. In S2, the low-risk identification scope includes: fourth setting vulnerabilities, failure to follow best practices for image building, and image size or structural issues that do not affect security; the handling strategy is to not block the main process and add setting optimization suggestions to the deployment document.

3. The method for building a trusted container image in a confined environment according to claim 1, characterized in that: In S3, the base image in the controlled base image project is an image that has been pulled from the official source and stored in the image repository in advance.

4. The method for building a trusted container image in a confined environment according to claim 1, characterized in that: In step S5, the preset version naming rule is formatted as follows: Project Identifier - Project Name - Environment Identifier - Version Number; wherein, the environment identifier includes the test environment identifier and the production environment identifier.

5. The method for building a trusted container image in a confined environment according to claim 1, characterized in that: In step S6, the hash value is calculated using the SHA-256 algorithm; the information recorded in the build audit log includes: image name, image version number, build time, operation and maintenance account identifier, and hash value; the controlled security channels include internal tiered storage devices and internal cloud disks.

6. The method for building a trusted container image in a confined environment according to claim 1, characterized in that: In step S7, the deployment list needs to undergo a security review before deployment, specifically including: Image information verification: Verify the consistency of the image name, version number, and hash value with the build audit logs; Run configuration review: Review CPU limits, memory limits, container restart policy, and process running users; Network configuration review: Review container listening ports, host port mapping relationships, network modes, and inter-service communication range; Storage configuration review: Review the data volume mount list, the correspondence between host machine and container paths, and the list of data volume permissions and environment variables; After security verification, the deployment checklist will be deployed.

7. The method for building a trusted container image in a confined environment according to claim 1, characterized in that: In S7, the basic running status verification includes: verification of the survival status of processes within the container, verification of the availability of service listening ports, verification of normal log output, and verification of the stability of communication with internal dependent services. In S7, the deployment operation also includes environment parameter configuration, which includes: setting the service running user and permissions, configuring resource limits, configuring health checks, configuring container log paths and log rotation policies, configuring network access control lists and access whitelists, configuring service startup environment variables, and configuring internal load balancing or service registration information.

8. A trusted construction apparatus for container images in a confined environment, characterized in that: include: The version control module submits three types of materials to the version control system: Dockerfile, dependency list, and project source code. The static scanning module performs static security scans on the submitted Dockerfile using vulnerability scanning tools, and classifies and handles the scan results according to preset risk classification rules. The risk classification rules include four levels: severe risk, high risk, medium risk, and low risk, with each level corresponding to different identification scopes and handling strategies. The image building module pulls certified base images from the controlled base image project of the controlled image repository and combines them with the Dockerfile to complete the construction of the service image; The vulnerability scanning module performs a pre-defined scan on the completed service image. The scan scope includes system-level vulnerabilities, dependency-level vulnerabilities, license agreement compliance, and image configuration compliance. It proceeds to the next step only if the scan results meet the preset compliance standards. The image management module pushes images that have passed compliance checks to the image repository and manages their versions according to preset version naming rules. Developers only have image pull permissions, while operations and maintenance personnel have full permissions for image push, pull, and permission management. The secure distribution module exports the image as an archive file, generates and records the hash value of the archive file to the build audit log; The archived files are transmitted to the production environment through controlled and secure channels. Before deployment, the hash value of the received archived files is recalculated and checked for consistency with the original hash value in the build audit log. The restricted deployment module loads the image that has passed consistency verification and completes container deployment according to the deployment manifest in a restricted production environment where access to necessary internal services is only permitted and external network access is not allowed. After deployment, it performs basic operational status verification and business function verification.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images