A k8s container image security policy enforcement method and system

Abstract

This invention relates to the technical field of enforcing security policies for Kubernetes container images, specifically to a method and system for enforcing security policies for Kubernetes container images. The method includes the following steps: obtaining the composition information of the container image and the runtime status information of the deployment environment; assessing the risk level of the container image and generating a pre-deployment security check plan and a runtime security protection plan corresponding to the risk level; performing security checks on the container image and determining the deployment permission for the container image based on the results of the security checks; protecting and monitoring the runtime behavior of the container image, determining whether the runtime behavior of the container image deviates from the runtime security protection plan, and triggering an alarm when the runtime behavior of the container image deviates from the runtime security protection plan, adjusting the protection strength of the runtime security protection plan, or terminating the operation of the container image. This application improves the end-to-end security of container images.

Description

Technical Field

[0001] This invention relates to the technical field of enforcing security policies for Kubernetes container images, and specifically to a method and system for enforcing security policies for Kubernetes container images. Background Technology

[0002] In industrial internet platforms, to ensure production continuity and data security, platform operations teams typically use Kubernetes (K8s) container orchestration systems to manage and deploy various industrial applications. These applications exist as container images, carrying multiple functions from device data acquisition and edge computing analysis to central control decision-making. The platform usually establishes a strict container image security access mechanism to conduct preliminary security reviews of images. This includes verifying the image's digital signature to confirm its legitimacy and using integrated vulnerability scanning tools to compare against the latest vulnerability databases and check for known security vulnerabilities in the image's internal components. Only after an image passes all preset security checks and is marked as "security compliant" is the K8s system allowed to enter the deployment process.

[0003] However, the Industrial Internet environment places extremely high demands on the speed of application updates and iterations. Equipment control logic, data acquisition modules, and edge analytics algorithms on production lines often need to be rapidly adjusted and deployed based on actual production conditions, new product requirements, or sudden failures. To address this rapid response requirement, platforms often design an "emergency deployment channel" mechanism, allowing authorized maintenance personnel or automated systems to quickly deploy container images marked as "critical business" or "urgent repair" under extremely special circumstances. In this mode, the centralized security policy enforcement module skips some time-consuming deep scanning steps; for example, it may no longer perform a complete software bill of materials analysis or execute behavior-pattern-based sandbox simulation tests, only performing basic digital signature verification and critical configuration checks to significantly shorten the time from image submission to runtime.

[0004] As the platform's business continues to expand, the types and number of deployed applications have increased dramatically, making security policy configuration increasingly complex. To achieve granular management, the security team has defined hundreds of detailed security policies for different business domains, security levels, and deployment environments. These policies are linked to container images and Kubernetes deployment configurations through tags. While this granular management improves flexibility and better adapts to the needs of different business scenarios, it also inadvertently increases configuration complexity and the probability of errors. Operations personnel are prone to leaving configuration vulnerabilities when faced with such a large set of policies. Summary of the Invention

[0005] The purpose of this invention is to address the aforementioned shortcomings by proposing a method and system for enforcing security policies for K8s container images.

[0006] The present invention adopts the following technical solution: A method for enforcing security policies for Kubernetes container images, comprising the following steps: Obtain the composition information of the container image and the running status information of the deployment environment. The composition information of the container image is related information used to characterize the internal composition and source trustworthiness of the container image, and the running status information of the deployment environment is related information used to characterize the current status of the target deployment node and its network environment. Based on the composition information of the container image, the runtime status information of the deployment environment, and the preset policy rules, the risk level of the container image is assessed, and a pre-deployment security check plan and runtime security protection plan corresponding to the risk level are generated. The policy rules are used to specify the risk level of the container image for different scenarios, as well as the pre-deployment security check plan and runtime security protection plan corresponding to the risk level of different container images. According to the pre-deployment security check plan, a security check is performed on the container image, and the deployment license of the container image is determined based on the results of the security check. At the same time, the security check integrity information and deployment license information are attached to the deployment configuration of the container image. The deployment configuration is the K8s resource configuration used to initiate the deployment of the container image, and the security check integrity information is the information used to characterize the scope and completion status of this pre-deployment security check. After the container image is deployed, the runtime security protection plan and security check integrity information are used to protect and monitor the runtime behavior of the container image, determine whether the runtime behavior of the container image deviates from the runtime security protection plan, and when the runtime behavior of the container image deviates from the runtime security protection plan, an alarm is triggered and the protection strength of the runtime security protection plan is adjusted or the runtime of the container image is terminated.

[0007] This technical solution addresses the security blind spot issue in existing technologies caused by the simplification of centralized scanning strategies and improper or drifting runtime strategies in emergency deployment channels, ensuring continuous and consistent end-to-end security of container images.

[0008] This application also discloses a K8s container image security policy enforcement system, which, applying the above-described K8s container image security policy enforcement method, includes: The acquisition module acquires the composition information of the container image and the running status information of the deployment environment. The composition information of the container image is related to the internal composition and source trustworthiness of the container image, and the running status information of the deployment environment is related to the current status of the target deployment node and its network environment. The generation module assesses the risk level of the container image based on its composition information, the runtime status information of the deployment environment, and preset policy rules, and generates a pre-deployment security check plan and a runtime security protection plan corresponding to the risk level. The inspection module performs security checks on the container image according to the pre-deployment security inspection plan, and determines the deployment license of the container image based on the results of the security inspection. At the same time, it attaches the security inspection integrity information and deployment license information to the deployment configuration of the container image. The deployment configuration is the K8s resource configuration used to initiate the deployment of the container image, and the security inspection integrity information is the information used to characterize the scope and completion status of this pre-deployment security inspection. After the container image is deployed, the processing module protects and monitors the runtime behavior of the container image based on the runtime security protection plan and security check integrity information. It determines whether the runtime behavior of the container image deviates from the runtime security protection plan. When the runtime behavior of the container image deviates from the runtime security protection plan, it triggers an alarm and adjusts the protection strength of the runtime security protection plan or terminates the runtime of the container image.

[0009] This technical solution provides an integrated system that, through modular design, enables the automated enforcement of security policies for K8s container images, effectively improving the efficiency and consistency of security management.

[0010] This application can flexibly adjust security policies according to actual conditions, effectively improving the overall security protection capabilities of container images while ensuring business continuity, and avoiding potential security risks caused by simplified security policies or configuration drift.

[0011] To further understand the features and technical content of the present invention, please refer to the following detailed description and drawings of the present invention. However, the drawings provided are for reference and illustration only and are not intended to limit the present invention. Attached Figure Description

[0012] Figure 1 This is a flowchart of the method for enforcing the security policy of a K8s container image according to the present invention; Figure 2 This is a schematic diagram of the structure of the K8s container image security policy enforcement system of the present invention. Detailed Implementation

[0013] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can understand the advantages and effects of the present invention from the content disclosed in this specification. The present invention can be implemented or applied through other different specific embodiments, and various details in this specification can also be modified and changed based on different viewpoints and applications without departing from the spirit of the present invention. Furthermore, the accompanying drawings of the present invention are for simple illustrative purposes only and are not depictions of actual dimensions; this is stated in advance. The following embodiments will further describe the relevant technical content of the present invention in detail, but the disclosed content is not intended to limit the scope of protection of the present invention.

[0014] This embodiment provides a method and system for enforcing security policies for Kubernetes container images, combined with... Figure 1 and Figure 2 As shown.

[0015] refer to Figure 1 A method for enforcing a security policy for a Kubernetes container image, comprising the following steps: Obtain the composition information of the container image and the running status information of the deployment environment. The composition information of the container image is related information used to characterize the internal composition and source trustworthiness of the container image, and the running status information of the deployment environment is related information used to characterize the current status of the target deployment node and its network environment. Based on the composition information of the container image, the runtime status information of the deployment environment, and the preset policy rules, the risk level of the container image is assessed, and a pre-deployment security check plan and runtime security protection plan corresponding to the risk level are generated. The policy rules are used to specify the risk level of the container image for different scenarios, as well as the pre-deployment security check plan and runtime security protection plan corresponding to the risk level of different container images. According to the pre-deployment security check plan, a security check is performed on the container image, and the deployment license of the container image is determined based on the results of the security check. At the same time, the security check integrity information and deployment license information are attached to the deployment configuration of the container image. The deployment configuration is the K8s resource configuration used to initiate the deployment of the container image, and the security check integrity information is the information used to characterize the scope and completion status of this pre-deployment security check. After the container image is deployed, the runtime security protection plan and security check integrity information are used to protect and monitor the runtime behavior of the container image, determine whether the runtime behavior of the container image deviates from the runtime security protection plan, and when the runtime behavior of the container image deviates from the runtime security protection plan, an alarm is triggered and the protection strength of the runtime security protection plan is adjusted or the runtime of the container image is terminated.

[0016] The "container image composition information" refers to information used to characterize the internal composition and source trustworthiness of a container image. This may include, but is not limited to, the image's Software Bill of Materials (SBOM), digital signature, build history, base image information, and the versions and dependencies of the packages it contains. This information is fundamental to assessing the static security of an image. The "deployment environment runtime status information" refers to information used to characterize the current state of the target deployment node and its network environment. This may include the resource usage of the target Kubernetes node (such as CPU, memory, disk, network bandwidth), network topology, security group configuration, the load of other deployed containers, and the status of the security agent running on the node. This information is crucial for assessing the dynamic risks of an image in a specific environment. "Policy rules" are a set of pre-defined rules used to define the risk level of container images in different scenarios, as well as the pre-deployment security check schemes and runtime security protection schemes corresponding to different risk levels. These rules can be defined based on business needs, compliance requirements, security best practices, etc., and can be dynamically adjusted according to actual conditions. The "pre-deployment security check scheme" is a detailed plan of security checks that need to be performed on a specific container image before deployment. The "Safety Plan" is dynamically generated based on the risk level of the container image and may include one or more checks such as digital signature verification, critical configuration checks, vulnerability scanning, malicious code analysis, and sandbox behavior simulation. The "Runtime Security Protection Plan" is a detailed plan of security protection and monitoring measures that need to be performed on the container image during runtime. This plan is also dynamically generated based on the risk level of the container image and may include one or more protection measures such as system call restrictions, file access control, network communication policies, process behavior monitoring, and resource usage restrictions. "Deployment Configuration" refers to the Kubernetes resource configuration used to initiate container image deployment, such as YAML or JSON files for Kubernetes resource objects like Deployment, Pod, and StatefulSet. These configurations contain all the information required for deployment, including the container image name, version, environment variables, mounted volumes, and port mappings. "Security Check Completeness Information" refers to information used to characterize the scope and completion status of security checks performed before this deployment. For example, it can record which checks were performed, the results, whether any checks were skipped, and the reasons for skipping them. This information is crucial for subsequent adjustments and auditing of runtime security protection. "Container image runtime behavior" refers to the various operations exhibited by a container image when it is actually executed in a Kubernetes environment, including system call behavior, file access behavior, process behavior, and network communication behavior. Monitoring these behaviors is crucial for discovering potential security threats.

[0017] The core of the K8s container image security policy enforcement method proposed in this application lies in ensuring the security of container images through dynamic risk assessment, customized security solutions, and full lifecycle protection and monitoring.

[0018] Firstly, there are several ways to obtain information about the composition of container images and the runtime status of the deployment environment. For example, the deployment configuration of a container image can be obtained through the Kubernetes API Server, from which basic information such as the image name and tags can be extracted. Then, detailed composition information of the image, including its software bill of materials, digital signature, and build logs, can be obtained through the API interface of the image repository (such as Harbor or Docker Hub). Regarding the runtime status information of the deployment environment, monitoring tools such as Kubernetes Metrics Server and Prometheus can be used to collect real-time data on the CPU, memory, and network bandwidth usage of the target deployment nodes. Simultaneously, network policies, security group configurations, and other deployed Pod information on the nodes can be obtained through the Kubernetes API. Furthermore, agent programs deployed on the nodes can collect more low-level system information, such as kernel version, loaded modules, and file system status.

[0019] Secondly, a risk assessment engine can be built to assess the risk level of a container image based on its composition information, the runtime status information of the deployment environment, and preset policy rules, and to generate pre-deployment security check plans and runtime security protection plans corresponding to the risk level. This engine can receive the aforementioned composition and runtime status information as input. For example, if the container image's SBOM contains components with known high-risk vulnerabilities, or if its digital signature verification fails, the risk level will be increased. Similarly, if a node in the deployment environment has a known security configuration flaw, or if the network environment has a large exposure surface, the risk level will also be increased accordingly. The preset policy rules can be a rule-based system that defines the mapping relationship between various scenarios and risk levels, as well as security check and protection plan templates corresponding to different risk levels. For example, for a container image marked as "urgently patched," the policy rules might stipulate a higher initial risk level, but allow skipping some time-consuming deep scans and instead focusing on runtime behavior monitoring. Based on these rules, the risk assessment engine comprehensively analyzes the input information, calculates the final risk level of the container image, and selects or dynamically generates corresponding pre-deployment security check schemes and runtime security protection schemes from the preset scheme template library.

[0020] Furthermore, in performing security checks on container images according to the pre-deployment security check plan, and determining the deployment permission for the container image based on the security check results, while attaching the security check integrity information and deployment permission information to the container image's deployment configuration, multiple security check tools can be integrated. For example, the pre-deployment security check plan may require digital signature verification, in which case tools such as OpenSSL can be used to verify the digital signature of the image. If the plan requires critical configuration checks, the Dockerfile or Kubernetes deployment configuration of the container image can be parsed to check for configurations such as privileged mode operation, sensitive port exposure, and insecure mount points. For vulnerability scanning, open-source or commercial vulnerability scanning tools such as Clair and Trivy can be used to scan the internal components of the image. The security check result can be "pass," "fail," or "risk exists but deployment is possible." Based on these results, the system will decide whether to grant a container image deployment permission. For example, if a high-risk vulnerability exists that cannot be patched, deployment may be rejected; if a low-to-medium risk vulnerability exists but the business is urgent, deployment may be allowed but the runtime protection strength will be increased. Security check integrity information records which items were performed during the check, the results of each item, and whether any items were skipped and the reasons why. This information, along with deployment license information, can be attached to the container image's deployment configuration as a Kubernetes annotation or label, ensuring that this information flows with the deployment configuration and providing context for subsequent runtime protection.

[0021] Finally, after container image deployment, the runtime behavior of the container image is protected and monitored based on the runtime security protection scheme and security check integrity information. This involves determining whether the container image's behavior deviates from the runtime security protection scheme. When such deviation is detected, an alarm is triggered, and the protection strength of the runtime security protection scheme is adjusted, or the container image's operation is terminated. This can be achieved using Kubernetes' Admission Controller and Runtime Security Agent. For example, the Runtime Security Agent can be deployed on each Kubernetes node, using technologies such as eBPF, seccomp, and AppArmor to monitor and restrict the container image's system call behavior, file access behavior, process behavior, and network communication behavior in real time. The runtime security protection scheme defines a series of restriction rules, such as allowed file paths, allowed network connection targets, and prohibited system calls. Security check integrity information can be used to adjust the granularity of runtime protection. For example, if a pre-deployment check reveals a known vulnerability in an image but it is still allowed to be deployed, the runtime protection scheme may be strengthened to more strictly monitor and restrict the specific behavior of that image. When the system detects that the behavior of a container image deviates from the preset protection scheme—such as attempting to access sensitive files, initiating abnormal network connections, or executing unauthorized system calls—it will immediately trigger an alarm to notify operations and maintenance personnel. Simultaneously, the system can automatically adjust the protection strength of the runtime security scheme based on the severity of the deviation. For example, it can switch from monitoring mode to forced blocking mode, or directly terminate the container image's operation when the behavior deviates severely and meets preset termination conditions, to prevent potential security incidents from escalating further.

[0022] The proposed method for enforcing security policies for Kubernetes container images combines the composition information of the container image with the runtime status information of the deployment environment to achieve dynamic assessment of the risk level of the container image. This assessment method not only considers the static security attributes of the image itself but also incorporates the real-time context of its deployment environment, making the risk assessment more comprehensive and accurate. Based on the dynamically assessed risk level, this application can generate customized pre-deployment security check schemes and runtime security protection schemes, thereby avoiding the rigidity and shortcomings of traditional fixed policies. Before deployment, customized security checks are performed, and their integrity information and deployment licenses are attached to the deployment configuration, ensuring the transparency and traceability of security decisions. After the container image is deployed, this application further utilizes the runtime security protection scheme and the integrity information of the security checks to continuously protect and monitor the runtime behavior of the container image. When deviations in runtime behavior are detected, alarms can be triggered in a timely manner, and the protection strength can be adjusted or the operation can be terminated according to the actual situation, thus forming a closed-loop security enforcement mechanism.

[0023] This application further proposes the following steps for assessing the risk level of a container image based on its composition information, the runtime status information of the deployment environment, and preset policy rules, and generating a pre-deployment security check plan and a runtime security protection plan corresponding to the risk level: Obtain preset business tags, which are identification information that developers or operations personnel attach to the container image or Kubernetes deployment configuration before the container image is built, submitted, or deployed; The composition information of the container image is parsed to identify components that are not normally recorded, and the identification results are obtained. Check if the mounting point is abnormal and obtain the test results; The integrity of the container image content is determined based on the identification and detection results. The system collects operational status information from multiple sources and detects inconsistencies or incompleteness in the data to determine the integrity of the deployment environment's data. Based on the results of content integrity assessment, data integrity assessment, and preset business tags, the risk level of the container image is adjusted in conjunction with preset policy rules. When the risk level is adjusted, a pre-deployment security check plan and a runtime security protection plan corresponding to the adjusted risk level are generated. The pre-deployment security check plan is used to perform at least one of the following on the container image: digital signature verification, critical configuration check, special deep scan, and sandbox behavior simulation. The runtime security protection plan is used to restrict and monitor the runtime behavior of the container image.

[0024] Specifically, obtaining pre-defined business tags refers to the identification information that developers or operations personnel actively configure for container images or their Kubernetes deployments throughout the entire lifecycle of a container image. These business tags may include metadata such as application type, sensitive data processing level, compliance requirements, and the business line to which they belong. Their purpose is to provide business-level contextual information for subsequent risk assessments, enabling risk assessments to be conducted in conjunction with the specific needs and sensitivities of the business scenario.

[0025] This involves parsing the composition information of container images to identify components not routinely documented. Specifically, this refers to a deep analysis of the container image's internal file system, package manifest, and dependency libraries to discover binaries, scripts, or configuration items not listed in the standard manifest or injected through unconventional methods. This step aims to reveal potential malicious implants, backdoors, or unauthorized modifications, with the goal of uncovering hidden threats.

[0026] In practical applications, detecting mount point anomalies specifically refers to checking whether the volume mount points configured during container image deployment conform to the expected security policies. For example, checking for sensitive host machine directories mounted inside the container or devices that should not be accessible to the container. The purpose is to prevent privilege escalation, data leaks, or lateral movement attacks through mount points.

[0027] Furthermore, judging the integrity of the container image's content based on the identification and detection results means comprehensively considering the identification results of components not routinely recorded and the detection results of mount point anomalies, assessing whether the internal composition of the container image has been tampered with, whether it contains unexpected content, and whether its connection with external resources is secure and reliable.

[0028] Furthermore, multi-source collection of operational status information from the deployment environment, along with detection of inconsistencies or incompleteness, is crucial for assessing data integrity. This involves gathering real-time operational status data from multiple sources, including the Kubernetes cluster's control plane, node agents, network devices, and storage systems. Data includes node resource usage, network traffic, security group configurations, and storage volume status. By comparing this multi-source data, inconsistencies or missing information in data reports can be identified, allowing for the determination of whether the deployment environment itself has been tampered with, misconfigured, or has monitoring blind spots. The goal is to ensure that the environmental information upon which risk assessment relies is accurate and reliable.

[0029] Therefore, adjusting the risk level of a container image based on content integrity assessment results, data integrity assessment results, and preset business tags, combined with preset policy rules, means taking the aforementioned assessment results and business tags as input and matching them with preset policy rules that define the risk level adjustment logic under different scenarios. For example, if a container image is found to contain components that are not routinely recorded, or if there are data integrity issues in the deployment environment, its initial risk level may be increased, even if it is low. Business tags can further refine the risk assessment; for example, a container image that processes sensitive data may have its risk level significantly increased even with only minor anomalies.

[0030] Once the risk level is adjusted, a pre-deployment security check plan and a runtime security protection plan corresponding to the adjusted risk level are generated. The pre-deployment security check plan performs at least one of the following on the container image: digital signature verification, critical configuration checks, specialized deep scanning, and sandboxed behavior simulation. The runtime security protection plan restricts and monitors the runtime behavior of the container image. Specifically, the adjusted risk level directly determines the stringency and coverage of the generated security check and protection plans. For example, for high-risk container images, pre-deployment may require more comprehensive digital signature verification, more in-depth configuration checks, specialized deep scanning targeting specific vulnerabilities, and even behavior simulation in a sandbox environment to detect potential malicious behavior; during runtime, stricter system call restrictions, file access control, and network communication monitoring rules will be configured.

[0031] This application's solution effectively addresses the blind spots and inaccuracies inherent in traditional risk assessments by introducing a multi-dimensional, fine-grained information collection and analysis mechanism. First, the introduction of business tags allows risk assessments to fully consider the business sensitivity and compliance requirements of container images, integrating business context into security decisions. Second, in-depth analysis of container image composition information and identification of components not routinely recorded can reveal hidden threats that are difficult to detect through traditional static analysis, such as malicious code injection or backdoors. Simultaneously, the detection of abnormal mount points effectively prevents privilege escalation and data leakage risks caused by insecure mount configurations. These judgments regarding the integrity of the container image itself, combined with multi-source collection of deployment environment runtime status information and data integrity checks, ensure that the input data relied upon for risk assessment is comprehensive, accurate, and reliable. Finally, based on these refined judgment results and business tags, and combined with preset policy rules, the risk level of the container image is dynamically adjusted, enabling the risk level to more accurately reflect the true security posture of the container image and its deployment environment. Therefore, the generated pre-deployment security check scheme and runtime security protection scheme will be highly matched with the adjusted risk level, thus providing more targeted and effective security protection.

[0032] In some preferred embodiments, suppose a new container image needs to be deployed in a Kubernetes cluster, which claims to be a stateless web service. First, when obtaining preset business tags, it is found that the container image has been marked by the developers as "handling sensitive user data" and "requiring PCI DSS compliance." These business tags immediately increase the concern about the potential risks of the image. Next, the composition information of the container image is parsed to identify components not routinely recorded. Through deep scanning, the system finds that the image contains a binary file not declared in the Dockerfile or package manifest, and that this file attempts to make abnormal network connections during sandbox simulation. This is marked as a high-risk item in the identification results. Simultaneously, the mount point is checked for anomalies. The system finds that the Kubernetes deployment configuration of the container image unexpectedly configures a read-write mount to the / var / log directory on the host machine, which is determined to be an abnormal mount point. Based on the above identification and detection results, the system judges that the integrity of the container image's content has serious problems, and it may have been tampered with or contain malicious components. Furthermore, the runtime status information of the deployment environment is collected from multiple sources. The system collected data from the K8s API Server, kubelet, and network monitoring tools. It discovered a slight discrepancy between the resource utilization reported by the kubelet of one of the target deployment nodes and the network traffic reported by the network monitoring tool. This was flagged as a potential data integrity issue in the deployment environment. Based on the combined results of the content integrity assessment (high risk), the data integrity assessment (potential issue), and the preset business tag (handling sensitive data, requiring compliance), the system, along with preset policy rules, adjusted the risk level of this container image from the initial "medium" to "high risk."

[0033] Once the risk level is adjusted to "high risk," the system generates a pre-deployment security check plan and a runtime security protection plan corresponding to the adjusted risk level. The pre-deployment security check plan is configured to perform digital signature verification, a dedicated deep scan of the abnormal binary file, and comprehensive behavioral simulation in an isolated sandbox. The runtime security protection plan is configured to strictly restrict the container's network egress, allowing access only to whitelisted ports, and to monitor all system calls and file access in real time. If any behavior deviating from the preset behavioral pattern is detected, an alarm is immediately triggered, and termination of the container's operation is considered. In this way, even a seemingly ordinary web service image can be identified and rigorously protected due to its potential deep-seated risks.

[0034] Specifically, the steps described above for parsing the composition information of container images and identifying components not typically recorded include: Dynamic behavior simulation is performed on components in container images whose internal logic has not been identified by conventional static analysis. Record the system call sequence, memory access pattern, and network communication attempts of the component to be analyzed during dynamic behavior simulation to obtain behavioral data; By comparing behavioral data with features in a pre-defined malicious behavior pattern library, it can be determined whether the component to be analyzed has potential malicious behavior features or hidden vulnerability exploitation attempts. When a component to be analyzed exhibits potential malicious behavior or hidden exploit attempts, the component to be analyzed will be marked as a component that is not normally logged.

[0035] The dynamic behavior simulation of components within container images whose internal logic is not readily apparent through conventional static analysis refers to placing components whose internal logic or behavioral patterns are difficult to fully understand using traditional static analysis methods—such as obfuscated, encrypted, or dynamically loaded components—in a controlled runtime environment for actual execution to observe their true behavior at runtime. This approach aims to compensate for the shortcomings of static analysis when dealing with complex or evasive code.

[0036] Furthermore, during dynamic behavior simulation, the system call sequences, memory access patterns, and network communication attempts of the component under analysis are recorded in detail, yielding behavioral data. System call sequences reflect the component's interaction with the operating system kernel, such as file operations and process management; memory access patterns reveal the component's read and write behavior to memory regions, potentially indicating buffer overflows or data tampering; and network communication attempts expose the component's connection intentions and data transmission behaviors with external network resources. This behavioral data is crucial for assessing component security.

[0037] The acquired behavioral data is then compared with features in a pre-defined malicious behavior pattern library. This library contains signatures, behavioral patterns, or heuristic rules for known malware, exploit code, or suspicious behavior. This comparison determines whether the behavioral data of the component being analyzed matches malicious features in the library, thereby identifying potential malicious behavior or hidden exploit attempts.

[0038] When the comparison results indicate that the component under analysis exhibits potential malicious behavior or hidden vulnerability exploitation attempts, the component will be marked as not being routinely logged. This marking signifies that the component poses a high security risk, requires special attention, and will be given priority consideration in subsequent risk assessments and the development of security protection plans.

[0039] This application's solution overcomes the limitations of traditional static analysis when dealing with complex, obfuscated, or dynamically loaded code by dynamically simulating the internal behavior of components in container images that are difficult to identify through conventional static analysis. By executing the component under analysis in a controlled environment and recording detailed behavioral data such as its system call sequences, memory access patterns, and network communication attempts, the true behavioral characteristics of the component during actual runtime can be obtained. Subsequently, this behavioral data is compared with a pre-defined library of malicious behavior patterns, enabling the effective identification and judgment of even malicious code designed to evade static detection or hidden exploit attempts. Therefore, this application can uncover potential security threats that are difficult to detect using traditional methods, thus providing a more comprehensive and in-depth insight into the risk assessment of container images.

[0040] Specifically, the steps for dynamically simulating the behavior of components in a container image whose internal logic has not been identified by conventional static analysis include: Load the components to be analyzed into an isolated sandbox runtime environment; Based on the functional type of the component to be analyzed, construct the input data or call request to trigger the operation of the component to be analyzed; The component to be analyzed is executed in a sandbox environment, and system call sequences, file access patterns and network communication attempts generated during the operation of the component to be analyzed are continuously collected within a preset simulation duration.

[0041] Loading the component to be analyzed into an isolated sandbox runtime environment refers to creating a controlled execution space isolated from the target production deployment environment for securely running suspicious or unknown components within the container image. This sandbox runtime environment is designed to restrict the network access scope, file system access scope, and system call execution scope of the component to be analyzed, thereby preventing potential malicious behavior from impacting the host machine or network.

[0042] Furthermore, based on the functional type of the component to be analyzed, constructing input data or call requests to trigger its operation means generating or simulating corresponding external interactions for different types of components (e.g., web services, command-line tools, library files, etc.) to activate their internal logic. For example, for a web service component, an HTTP request can be constructed; for a command-line tool, specific command-line parameters can be provided; for a library file, its API calls can be simulated. This aims to ensure that the component to be analyzed can be fully activated in the simulation environment, thereby exposing its complete behavioral patterns.

[0043] Furthermore, the component to be analyzed is executed in a sandbox environment, and system call sequences, file access patterns, and network communication attempts generated during the component's operation are continuously collected within a preset simulation duration. This means that while the component is activated and running, the system records in real time its interactions with the operating system kernel (system call sequences), read and write operations on the file system (file access patterns), and connection attempts with external network resources (network communication attempts). The preset simulation duration is used to balance the depth and efficiency of the analysis, ensuring that as many behavioral characteristics of the component as possible are captured within a limited time.

[0044] This application's solution effectively overcomes the shortcomings of traditional static analysis in identifying complex, obfuscated, or dynamically loaded malicious code by placing the component to be analyzed in an isolated sandbox environment for dynamic behavior simulation. By constructing specific input data or call requests to trigger component execution, it can be forced to expose its true behavior under normal operating conditions. During this process, continuous collection of system call sequences, file access patterns, and network communication attempts allows the system to obtain detailed data on the component's interaction with the environment at runtime—data that static analysis cannot directly obtain. Therefore, even if the component's internal logic is deliberately hidden or encrypted, its actual execution behavior in the sandbox is still fully recorded, providing crucial evidence for subsequent behavioral data comparison and malicious feature determination.

[0045] Specifically, an isolated sandbox runtime environment is a controlled execution environment isolated from the target production deployment environment, restricting the network access scope, file system access scope, and system call execution scope of the component being analyzed. The isolated sandbox runtime environment refers to a security boundary specifically designed for executing potentially untrusted code. This environment is completely separated from the actual production deployment environment, ensuring that any abnormal behavior or malicious operation of the component being analyzed during simulation will not affect the production system. Specifically, this isolation can be achieved through virtualization technology, container technology, or operating system-level security mechanisms. For example, virtual machines or independent container instances can be used to host the sandbox environment, configured with strict network isolation policies to prevent direct access to production network resources.

[0046] Furthermore, restricting the network access scope, file system access scope, and system call execution scope of the component being analyzed means that the sandbox environment imposes strict control over the component's external interaction capabilities. For example, network access can be restricted to allowing access only to specific whitelisted addresses or ports, or completely prohibiting external network communication; file system access can be restricted to allowing reading and writing only to specific directories within the sandbox, prohibiting access to the host file system or sensitive data; and system call execution scope can restrict the component to executing only preset secure system calls, prohibiting the execution of dangerous system calls that could lead to system crashes, data leaks, or privilege escalation. These restrictions collectively construct a controlled execution environment, ensuring that the behavior of the component being analyzed is strictly constrained within preset security boundaries.

[0047] This application's solution defines an isolated sandbox runtime environment as a controlled execution environment isolated from the target production deployment environment, restricting the network access scope, file system access scope, and system call execution scope of the component to be analyzed. Its working principle is to ensure the security and controllability of the simulation process when dynamically simulating the behavior of the component to be analyzed within the container image. Through physical or logical isolation from the production environment, it effectively prevents any malicious behavior or unexpected errors that may occur during the simulation process from spreading to the actual production system, thereby protecting the stability of the production environment and data security. Simultaneously, strict restrictions on access to critical resources such as the network, file system, and system calls force the behavior of the component to be analyzed to be constrained within a preset security range. Even if malicious code or vulnerabilities exist within the component, their potential destructive power can be minimized and confined to the sandbox environment, thus providing a safe and reliable foundation for subsequent behavioral data collection and analysis.

[0048] Specifically, the steps for detecting whether a mount point is abnormal may include the following operations: Obtain the mount point configuration information and mount path information of the container image; Compare the mount point configuration information with the preset standard mount configuration rules to identify whether there are any unexpected mount relationships; Check whether the mount path information is consistent with the path association of the components recorded in the software composition manifest in the container image; When there is an unexpected mount relationship or the mount path information is inconsistent with the path association of the components recorded in the software composition manifest in the container image, it is determined that there is an abnormal mount point.

[0049] Obtaining the mount point configuration information and mount path information of the container image refers to collecting detailed data about how the container accesses external storage or the host file system from the container image's metadata, Kubernetes deployment configuration (such as the volume and volume mount fields in the Pod definition), and file system information in the actual runtime environment. This information includes, but is not limited to, the mounted volume type, source path, target path, and access permissions.

[0050] Furthermore, the mount point configuration information is compared with the preset standard mount configuration rules to identify any unexpected mount relationships. The preset standard mount configuration rules can be a set of security policies that specify allowed mount sources, targets, permissions, and prohibited sensitive path mounts. By comparing the actual mount configuration of the container image with these rules, any mount behaviors that do not conform to the security baseline or business expectations can be discovered, such as mounting sensitive directories of the host machine or using insecure shared storage.

[0051] Furthermore, checking the consistency between the mount path information and the path associations of components recorded in the container image's software composition manifest aims to verify the consistency between the file system access paths declared or expected by components within the container and the actual mount paths. For example, if the container image's software composition manifest indicates that an application needs to access a specific data path, but the actual mount points to a different path on the host machine, an anomaly may exist. The purpose is to identify potentially malicious mounts that may be designed to steal data, escalate privileges, or perform other unauthorized operations.

[0052] Therefore, when there are unexpected mount relationships or mount path information that is inconsistent with the path associations of components recorded in the software manifest of the container image, it can be determined that there is an abnormal mount point. This anomaly determination is an important basis for container image risk assessment.

[0053] This application's solution meticulously acquires and analyzes the mount point configuration information and mount path information of container images, comparing it across multiple dimensions with preset security rules and the expected behavior of internal components. This effectively identifies potential mount point anomalies within container images. Such anomalies may manifest as unexpected mount relationships, such as a container being configured to access sensitive directories on the host machine, or a mount path that does not match the expected access paths of the container's internal software components, suggesting potential hidden malicious behavior or configuration errors. In this way, this solution can deeply reveal potential security risks of container images at the file system and resource access level.

[0054] In some of the embodiments described above in this application, a scheme is proposed to assess the risk level of a container image based on the composition information of the container image, the running status information of the deployment environment, and preset policy rules, and to generate a pre-deployment security check scheme and a runtime security protection scheme corresponding to the risk level. However, in its implementation, when the target deployment node is a resource-constrained industrial edge node, the traditional scheme may not be able to effectively balance the security protection strength and system resource consumption, making it difficult to implement the security scheme or affecting the normal operation of business.

[0055] This application further proposes the following steps for generating a pre-deployment security check plan and an operational security protection plan corresponding to the adjusted risk level when the target deployment node is a resource-constrained industrial edge node: The system obtains real-time resource usage data of industrial edge nodes and determines the available resources of these nodes based on this data. The real-time resource usage data includes CPU utilization, memory utilization, and network bandwidth utilization. Identify the core security protection requirements of container images, which include at least one of the following: network egress control, file integrity monitoring, system call restriction, and process behavior monitoring. Based on the adjusted risk level, the available resources of the industrial edge node, and the preset inspection priority rules, the priority inspection items in the pre-deployment security inspection plan are determined. The priority inspection items include at least one of the following: digital signature verification, critical configuration inspection, special in-depth scanning of high-risk components, and sandbox behavior simulation. Based on core security protection requirements and available resources at industrial edge nodes, lightweight security protection components are selected and combined from a pre-defined security policy component library. These lightweight security protection components include at least one of the following: eBPF-based network filtering rules, critical file monitoring rules, and critical system call sequence anomaly detection rules. Adjust the parameters of the lightweight security protection component, including at least one of the following: network connection whitelist set, file monitoring path range, and CPU-intensive security detection threshold, to optimize resource consumption of industrial edge nodes; Based on the identified priority inspection items, generate a pre-deployment security inspection plan corresponding to the adjusted risk level, and based on the adjusted lightweight security protection components and their configuration parameters, generate an operational security protection plan corresponding to the adjusted risk level.

[0056] Specifically, industrial edge nodes can be understood as devices deployed in industrial sites, typically characterized by limited computing power, small storage space, and constrained network bandwidth. Real-time resource usage refers to the occupancy status of critical resources such as the CPU, memory, and network bandwidth on an industrial edge node at a specific point in time. By acquiring this real-time data, the available resources of the current node can be accurately assessed, providing a quantitative basis for the customization of subsequent security solutions. For example, this resource data can be collected through APIs provided by the operating system or specific monitoring agents.

[0057] The core security requirements for container images refer to the most basic and critical security requirements that must be met for the container image to run on industrial edge nodes. These requirements may include ensuring that containers cannot access unauthorized external networks (network egress control), preventing critical files from being tampered with (file integrity monitoring), restricting containers from executing sensitive system calls (system call restriction), and monitoring abnormal behavior of processes within the container (process behavior monitoring). These requirements are derived from a comprehensive assessment based on the container image's business functions, sensitive data processing, and potential threat models.

[0058] In practical applications, priority checks in pre-deployment security checks refer to security checks that need to be performed first when resources are limited. For example, for high-risk container images, even with limited resources, digital signature verification should be prioritized to confirm their source credibility, or critical configuration checks should be performed to ensure they meet security baselines. Specific deep scans and sandboxed behavioral simulations of high-risk components are used to discover potential malicious behaviors or vulnerabilities. These priority checks are determined based on adjusted risk levels, available resources at industrial edge nodes, and pre-defined check priority rules, aiming to achieve maximum security benefits with minimal resource consumption.

[0059] Furthermore, lightweight security protection components refer to security protection modules specifically designed for resource-constrained environments, characterized by low resource consumption and high efficiency. For example, network filtering rules based on eBPF (extended Berkeley Packet Filter) can directly implement efficient network traffic control at the kernel level, avoiding the performance overhead of user-space proxies; critical file monitoring rules can focus on the integrity of only a few critical files, rather than performing a full scan; and critical system call sequence anomaly detection rules identify abnormal behavior by monitoring specific system call patterns, rather than performing complex behavioral analysis. The selection and combination of these components aim to achieve core security protection requirements with minimal resource cost.

[0060] Furthermore, adjusting the parameters of lightweight security components is to further optimize resource consumption at industrial edge nodes. For example, a network connection whitelist can precisely limit the network communication range of containers, reducing unnecessary network monitoring overhead; a file monitoring path range can narrow the scope of file integrity checks, focusing only on core business files; and CPU-intensive security detection thresholds can control the execution frequency or complexity of certain security detection tasks, avoiding excessive CPU usage when resources are scarce. By finely adjusting these parameters, the security solution can be highly matched to the actual resource conditions of industrial edge nodes.

[0061] This application's solution addresses the performance bottlenecks and deployment challenges that traditional solutions may face in resource-constrained environments by fully considering the resource-limited characteristics of industrial edge nodes when generating security policies. Specifically, firstly, by acquiring real-time resource usage data of industrial edge nodes, the system accurately grasps the available resources of the current nodes, providing a quantitative basis for subsequent policy customization. Secondly, identifying the core security protection requirements of container images ensures that even under resource constraints, the most critical security protection points are prioritized, avoiding unnecessary resource waste from comprehensive protection. Thirdly, based on adjusted risk levels, available resources, and inspection priority rules, priority inspection items in the pre-deployment security inspection plan are determined, allowing limited inspection resources to be concentrated on the most likely risky areas, improving inspection efficiency and effectiveness. Finally, by selecting and combining lightweight security protection components and fine-tuning their parameters, this solution can construct a runtime security protection plan that meets core security requirements while minimizing resource consumption. This customized policy generation method transforms security protection from a "one-size-fits-all" approach into an intelligently adaptable solution tailored to the specific deployment environment, achieving a balance between security and performance on industrial edge nodes.

[0062] In some preferred embodiments, suppose an industrial edge node is deployed in a production workshop, with its CPU utilization at 70%, memory utilization at 80%, and network bandwidth nearing saturation. In this case, a new container image needs to be deployed. This image is assessed as having a medium-to-high risk level, and its core security requirements are identified as network egress control and file integrity monitoring.

[0063] This solution first obtains the real-time resource usage of the industrial edge node, confirming that its available resources are very limited. Then, based on the moderately high risk level, limited available resources, and preset inspection priority rules, the system prioritizes digital signature verification and critical configuration checks as the key items for the pre-deployment security inspection, quickly confirming the image's legitimacy and basic security, while abandoning time-consuming and resource-intensive in-depth scanning.

[0064] In generating the operational security protection scheme, the system selected eBPF-based network filtering rules and critical file monitoring rules as lightweight security protection components from the security policy component library, based on the core security requirements of network egress control and file integrity monitoring. Subsequently, the system further adjusted the parameters of these components. For example, the network connection whitelist was limited to allow communication only with the internal data server of the workshop, the file monitoring path was narrowed to monitor the integrity of specific configuration files and data files within containers, and a low CPU-intensive security detection threshold was set to avoid triggering high-overhead detection tasks when resources are scarce.

[0065] Ultimately, the system generated a pre-deployment security check scheme that included digital signature verification and critical configuration checks, as well as a runtime security protection scheme that included eBPF network filtering rules with optimized parameters and critical file monitoring rules. In this way, the container image received the necessary rapid security verification before deployment and received targeted, resource-friendly security protection during runtime, ensuring the effective implementation of security policies on resource-constrained industrial edge nodes.

[0066] Specifically, the runtime behavior of a container image includes its system call behavior, file access behavior, process behavior, and network communication behavior.

[0067] System call behavior of a container image refers to various requests made by applications running inside the container to the operating system kernel, such as file operations, memory management, process control, and network socket operations. File access behavior refers to operations performed by processes within the container on the file system, including reading, writing, modifying, deleting, and creating files, such as access to configuration files, data files, log files, and executable files. Process behavior refers to activities such as the creation, startup, termination, state transitions, resource usage, and parent-child process relationships of processes within the container. Network communication behavior refers to activities such as establishing connections, transmitting data, and listening on ports between processes within the container and external network environments (such as the Internet, other Kubernetes cluster services) or other containers within the same Kubernetes cluster.

[0068] This application's solution refines the runtime behavior of container images into system call behavior, file access behavior, process behavior, and network communication behavior, enabling more comprehensive and granular protection and monitoring of the container's runtime state. The runtime security protection scheme can set detailed restriction rules for these specific behavior types, such as restricting specific system calls, monitoring access to sensitive files, detecting the start or termination of abnormal processes, and restricting unexpected network connections. This fine-grained definition provides a clear benchmark and quantifiable indicators for subsequently determining whether the container image's runtime behavior deviates from the runtime security protection scheme.

[0069] Specifically, based on the runtime security protection plan and security check integrity information, the runtime behavior of container images is protected and monitored. It is determined whether the runtime behavior of the container image deviates from the runtime security protection plan. When a deviation is detected, an alarm is triggered, and the protection strength of the runtime security protection plan is adjusted, or the runtime of the container image is terminated. The steps include: Based on the runtime security protection plan and security check integrity information, the system call behavior, file access behavior, process behavior and network communication behavior of the container image are protected and monitored to obtain runtime behavior data; The runtime behavior data is compared with the restriction rules corresponding to the runtime security protection scheme to determine whether the runtime behavior of the container image deviates from the runtime security protection scheme. An alarm is triggered when the behavior of a container image deviates from the runtime security protection plan. Adjust the protection strength of the operational safety protection scheme according to the deviation of operational behavior, or terminate the operation of the container image when the deviation of operational behavior meets the preset termination conditions.

[0070] Specifically, protecting and monitoring the system call behavior, file access behavior, process behavior, and network communication behavior of container images involves deploying lightweight agents on nodes of the Kubernetes cluster or utilizing technologies such as eBPF to collect real-time behavioral data on system calls, file operations, process creation / destruction, and network connections within the container. This behavioral data is continuously collected and forms a runtime behavior data stream. The runtime security protection solution provides preset security policies, such as lists of allowed system calls, whitelists of accessible file paths, and permitted network communication targets. The security check integrity information ensures that the scope and results of security checks performed before deployment are taken into account, thereby making runtime protection and monitoring more accurate and effective.

[0071] The comparison of runtime behavior data with the corresponding restrictions in the runtime security protection scheme involves matching the real-time collected runtime behavior data against the various restrictions defined in the runtime security protection scheme. For example, if the runtime security protection scheme stipulates that a container image can only access specific file directories, then any attempt to access files in other directories will be considered a deviation. This comparison process aims to identify whether the container image has performed behavior beyond its expected or permitted scope.

[0072] When a container image's behavior deviates from the runtime security protection plan, an alarm is triggered. This means that once a container image's behavior is detected to be inconsistent with preset restriction rules, the system will immediately generate and send an alarm message. This alarm message may include the type of deviation, the time of occurrence, the identifier of the container image involved, and the severity of the deviation, so that operations and maintenance personnel can respond promptly.

[0073] Furthermore, the system can adjust the protection strength of the runtime security protection scheme based on deviations in operational behavior, or terminate the container image's operation when the deviations meet preset termination conditions. This means the system doesn't simply issue alerts, but can take dynamic response measures based on the severity and nature of the deviation. For example, for minor deviations, protection strength can be increased, such as increasing monitoring granularity or restricting more system resources or network access; for severe deviations that meet preset termination conditions, such as detecting malicious file writing, tampering with critical system files, or unauthorized network connections, the container image's operation can be terminated directly to prevent potential security threats from escalating further.

[0074] This application's solution achieves refined security management of the runtime phases of a container image's lifecycle by refining the protection and monitoring mechanisms for the container image's operational behavior. Specifically, through comprehensive monitoring of system call behavior, file access behavior, process behavior, and network communication behavior, it can obtain real-time behavioral data of the container image during runtime. This data is then rigorously compared with the restriction rules in the pre-defined runtime security protection scheme, thereby accurately and promptly identifying any abnormal behavior that deviates from expectations or authorized scope. Once a deviation is detected, the system not only triggers alarms to notify relevant personnel, but more importantly, it can dynamically adjust the strength of the protection strategy based on the severity and nature of the deviation, or directly terminate the container image's operation when necessary. This dynamic response mechanism ensures that even after the container image is deployed, its operational behavior continues to be effectively constrained and protected, thereby effectively responding to unknown threats or zero-day exploits that may occur during runtime.

[0075] refer to Figure 2 A Kubernetes container image security policy enforcement system, applying the aforementioned Kubernetes container image security policy enforcement method, the system includes: The acquisition module acquires the composition information of the container image and the running status information of the deployment environment. The composition information of the container image is related to the internal composition and source trustworthiness of the container image, and the running status information of the deployment environment is related to the current status of the target deployment node and its network environment. The generation module assesses the risk level of the container image based on its composition information, the runtime status information of the deployment environment, and preset policy rules, and generates a pre-deployment security check plan and a runtime security protection plan corresponding to the risk level. The inspection module performs security checks on the container image according to the pre-deployment security inspection plan, and determines the deployment license of the container image based on the results of the security inspection. At the same time, it attaches the security inspection integrity information and deployment license information to the deployment configuration of the container image. The deployment configuration is the K8s resource configuration used to initiate the deployment of the container image, and the security inspection integrity information is the information used to characterize the scope and completion status of this pre-deployment security inspection. After the container image is deployed, the processing module protects and monitors the runtime behavior of the container image based on the runtime security protection plan and security check integrity information. It determines whether the runtime behavior of the container image deviates from the runtime security protection plan. When the runtime behavior of the container image deviates from the runtime security protection plan, it triggers an alarm and adjusts the protection strength of the runtime security protection plan or terminates the runtime of the container image.

[0076] The container image's composition information is defined as relevant information characterizing its internal components and source trustworthiness, such as image layers, package manifests, dependency libraries, digital signatures, and source repositories. The deployment environment's runtime status information is defined as relevant information characterizing the current state of the target deployment node and its network environment, such as node resource utilization, network topology, security group configurations, and deployed services. This acquisition module can integrate various data collectors, such as Kubernetes API clients, image repository scanning tools, and node monitoring agents, to ensure the comprehensiveness and real-time nature of the information.

[0077] The policy rules are pre-defined to specify the risk level of container images for different scenarios, as well as the pre-deployment security check plan and runtime security protection plan corresponding to the risk level of different container images. This generation module uses a built-in risk assessment engine to comprehensively analyze collected information and dynamically calculate the risk level of container images based on the policy rules defined by the administrator. Based on this risk level, the module can intelligently generate customized pre-deployment checklists and runtime protection policies.

[0078] Deployment configuration is defined as the Kubernetes resource configuration used to initiate container image deployment, such as Deployment and Pod definitions. Security check integrity information is defined as information characterizing the scope and completion status of security checks performed before deployment, such as executed scans, scan result summaries, unexecuted items and their reasons. This check module intervenes before the actual deployment of the container image, performing various checks specified in the plan, such as vulnerability scanning, configuration compliance checks, and digital signature verification, and decides whether to allow container image deployment based on the check results.

[0079] The processing module acts as a runtime security agent, continuously monitoring the actual running status of the container, such as system calls, file access, and network communication, and comparing it with preset protection schemes. Once abnormal behavior is detected, the module can respond immediately, taking measures such as alerting, enhancing protection, or forcibly terminating the container to ensure its safe operation.

[0080] This application's system automates, continuously enforces, and mandates the execution of security policies by personifying the logical steps of the K8s container image security policy enforcement method into independent, collaborative modules. Specifically, the acquisition module, acting as the system's perception layer, is responsible for comprehensively and in real-time collecting various security-related data about container images and their deployment environments, providing a foundation for subsequent risk assessments. The generation module, acting as the system's decision-making layer, uses this data and pre-defined policy rules to intelligently assess the potential risks of container images and generate targeted pre-deployment checks and runtime protection policies, ensuring the accuracy of security measures. The inspection module intervenes at critical stages of container deployment, rigorously reviewing container images according to the generated inspection plan, effectively intercepting insecure images before deployment, and attaching the inspection results and deployment permission information to the deployment configuration, providing context for subsequent runtime protection. Finally, the processing module, acting as the system's execution and response layer, continuously monitors the behavior of containers during runtime and, based on pre-defined protection plans and pre-deployment inspection information, promptly detects and responds to any deviations from expected behavior, thus forming a closed-loop security protection mechanism. It is precisely because of this modular design and automated process that the security policies of Kubernetes container images can be executed efficiently, accurately, and enforceably.

[0081] Through the above technical solutions, the K8s container image security policy enforcement system of this application can achieve automated security management of the entire lifecycle of container images from construction and deployment to operation. Compared with pure methodologies, this system encapsulates the method steps into specific software modules, greatly reducing the need for manual intervention and improving the efficiency and consistency of security policy enforcement. The system can acquire and analyze dynamic information of container images and deployment environments in real time, making risk assessment and security solution generation more accurate and timely. Furthermore, by performing mandatory checks before deployment and continuous protection and monitoring during runtime, the system can effectively prevent the deployment of insecure containers and respond promptly to security threats that arise during runtime, thereby significantly improving the overall security of the K8s cluster and reducing potential security risks and operating costs.

[0082] The content disclosed above is only a preferred and feasible embodiment of the present invention, and is not intended to limit the scope of protection of the present invention. Therefore, all equivalent technical changes made based on the content of the present invention specification and drawings are included within the scope of protection of the present invention. Furthermore, the elements therein can be updated as technology develops.

Claims

1. A method for enforcing security policies for Kubernetes container images, characterized in that, The method includes the following steps: Obtain the composition information of the container image and the running status information of the deployment environment. The composition information of the container image is related to the internal composition and source trustworthiness of the container image, and the running status information of the deployment environment is related to the current status of the target deployment node and its network environment. Based on the composition information of the container image, the runtime status information of the deployment environment, and the preset policy rules, the risk level of the container image is assessed, and a pre-deployment security check plan and runtime security protection plan corresponding to the risk level are generated. The policy rules are used to specify the risk level of the container image for different scenarios, as well as the pre-deployment security check plan and runtime security protection plan corresponding to the risk level of different container images. According to the pre-deployment security check plan, a security check is performed on the container image, and the deployment license of the container image is determined based on the results of the security check. At the same time, the security check integrity information and deployment license information are attached to the deployment configuration of the container image. The deployment configuration is the K8s resource configuration used to initiate the deployment of the container image, and the security check integrity information is the information used to characterize the scope and completion status of this pre-deployment security check. After the container image is deployed, the runtime security protection plan and security check integrity information are used to protect and monitor the runtime behavior of the container image, determine whether the runtime behavior of the container image deviates from the runtime security protection plan, and when the runtime behavior of the container image deviates from the runtime security protection plan, an alarm is triggered and the protection strength of the runtime security protection plan is adjusted or the runtime of the container image is terminated.

2. The method for enforcing a security policy for a Kubernetes container image as described in claim 1, characterized in that, The steps for assessing the risk level of a container image based on its composition information, the operational status information of the deployment environment, and preset policy rules, and then generating a pre-deployment security check plan and a runtime security protection plan corresponding to that risk level, include: Obtain the preset business tags, which are identification information that developers or operations personnel attach to the container image or Kubernetes deployment configuration before the container image is built, submitted, or deployed; The composition information of the container image is parsed to identify components that are not normally recorded, and the identification results are obtained. Check if the mounting point is abnormal and obtain the test results; The integrity of the container image content is determined based on the identification and detection results. The system collects operational status information from multiple sources and detects inconsistencies or incompleteness in the data to determine the integrity of the deployment environment. Based on the results of content integrity assessment, data integrity assessment, and preset business tags, the risk level of the container image is adjusted in conjunction with preset policy rules. When the risk level is adjusted, a pre-deployment security check plan and a runtime security protection plan corresponding to the adjusted risk level are generated. The pre-deployment security check plan is used to perform at least one of the following on the container image: digital signature verification, critical configuration check, special deep scan, and sandbox behavior simulation. The runtime security protection plan is used to restrict and monitor the runtime behavior of the container image.

3. The method for enforcing a security policy for a Kubernetes container image as described in claim 2, characterized in that, The steps for parsing the composition information of a container image and identifying components that are not normally recorded include: Dynamic behavior simulation is performed on components in container images whose internal logic has not been identified by conventional static analysis. Record the system call sequence, memory access pattern, and network communication attempts of the component to be analyzed during dynamic behavior simulation to obtain behavioral data; By comparing behavioral data with features in a pre-defined malicious behavior pattern library, it can be determined whether the component to be analyzed has potential malicious behavior features or hidden vulnerability exploitation attempts. When a component to be analyzed exhibits potential malicious behavior or hidden exploit attempts, the component to be analyzed will be marked as a component that is not normally logged.

4. The method for enforcing a security policy for a Kubernetes container image as described in claim 3, characterized in that, The steps for performing dynamic behavior simulation on components in a container image whose internal logic has not been identified by conventional static analysis include: Load the components to be analyzed into an isolated sandbox runtime environment; Based on the functional type of the component to be analyzed, construct the input data or call request to trigger the operation of the component to be analyzed; The component to be analyzed is executed in a sandbox environment, and system call sequences, file access patterns and network communication attempts generated during the operation of the component to be analyzed are continuously collected within a preset simulation duration.

5. The method for enforcing a security policy for a Kubernetes container image as described in claim 4, characterized in that, An isolated sandbox environment is a controlled execution environment that is isolated from the target production deployment environment and restricts the network access scope, file system access scope, and system call execution scope of the components to be analyzed.

6. The method for enforcing a security policy for a Kubernetes container image as described in claim 2, characterized in that, The steps to check if a mount point is abnormal include: Obtain the mount point configuration information and mount path information of the container image; Compare the mount point configuration information with the preset standard mount configuration rules to identify whether there are any unexpected mount relationships; Check whether the mount path information is consistent with the path association of the components recorded in the software composition manifest in the container image; When there is an unexpected mount relationship or the mount path information is inconsistent with the path association of the components recorded in the software composition manifest in the container image, it is determined that there is an abnormal mount point.

7. The method for enforcing a security policy for a Kubernetes container image as described in claim 2, characterized in that, When the target deployment node is a resource-constrained industrial edge node, the steps for generating a pre-deployment security check plan and an operational security protection plan corresponding to the adjusted risk level after the risk level is adjusted include: The system obtains real-time resource usage data of industrial edge nodes and determines the available resources of these nodes based on this data. The real-time resource usage data includes CPU utilization, memory utilization, and network bandwidth utilization. Identify the core security protection requirements of container images, which include at least one of the following: network egress control, file integrity monitoring, system call restriction, and process behavior monitoring. Based on the adjusted risk level, the available resources of the industrial edge node, and the preset inspection priority rules, the priority inspection items in the pre-deployment security inspection plan are determined. The priority inspection items include at least one of the following: digital signature verification, critical configuration inspection, special in-depth scanning of high-risk components, and sandbox behavior simulation. Based on core security protection requirements and available resources at industrial edge nodes, lightweight security protection components are selected and combined from a pre-defined security policy component library. These lightweight security protection components include at least one of the following: eBPF-based network filtering rules, critical file monitoring rules, and critical system call sequence anomaly detection rules. Adjust the parameters of the lightweight security protection component, including at least one of the following: network connection whitelist set, file monitoring path range, and CPU-intensive security detection threshold, to optimize resource consumption of industrial edge nodes; Based on the identified priority inspection items, generate a pre-deployment security inspection plan corresponding to the adjusted risk level, and based on the adjusted lightweight security protection components and their configuration parameters, generate an operational security protection plan corresponding to the adjusted risk level.

8. The method for enforcing a security policy for a Kubernetes container image as described in claim 1, characterized in that, The runtime behavior of a container image includes its system call behavior, file access behavior, process behavior, and network communication behavior.

9. A method for enforcing a security policy for a Kubernetes container image as described in claim 8, characterized in that, Based on the runtime security protection plan and security check integrity information, the runtime behavior of container images is protected and monitored. It is determined whether the runtime behavior of container images deviates from the runtime security protection plan. When a deviation is detected, an alarm is triggered, and the protection strength of the runtime security protection plan is adjusted, or the runtime of the container image is terminated. The steps include: Based on the runtime security protection plan and security check integrity information, the system call behavior, file access behavior, process behavior and network communication behavior of the container image are protected and monitored to obtain runtime behavior data; The runtime behavior data is compared with the restriction rules corresponding to the runtime security protection scheme to determine whether the runtime behavior of the container image deviates from the runtime security protection scheme. An alarm is triggered when the behavior of a container image deviates from the runtime security protection plan. Adjust the protection strength of the operational safety protection scheme according to the deviation of operational behavior, or terminate the operation of the container image when the deviation of operational behavior meets the preset termination conditions.

10. A Kubernetes container image security policy enforcement system, employing the Kubernetes container image security policy enforcement method described in claim 1, characterized in that, The system includes: The acquisition module acquires the composition information of the container image and the running status information of the deployment environment. The composition information of the container image is related to the internal composition and source trustworthiness of the container image, and the running status information of the deployment environment is related to the current status of the target deployment node and its network environment. The generation module assesses the risk level of the container image based on its composition information, the runtime status information of the deployment environment, and preset policy rules, and generates a pre-deployment security check plan and a runtime security protection plan corresponding to the risk level. The inspection module performs security checks on the container image according to the pre-deployment security inspection plan, and determines the deployment license of the container image based on the results of the security inspection. At the same time, it attaches the security inspection integrity information and deployment license information to the deployment configuration of the container image. The deployment configuration is the K8s resource configuration used to initiate the deployment of the container image, and the security inspection integrity information is the information used to characterize the scope and completion status of this pre-deployment security inspection. After the container image is deployed, the processing module protects and monitors the runtime behavior of the container image based on the runtime security protection plan and security check integrity information. It determines whether the runtime behavior of the container image deviates from the runtime security protection plan. When the runtime behavior of the container image deviates from the runtime security protection plan, it triggers an alarm and adjusts the protection strength of the runtime security protection plan or terminates the runtime of the container image.

Images