A container operation safety management method, electronic equipment and storage medium

Abstract

Embodiments of the present application disclose a container operation safety management method, an electronic device and a storage medium. The method comprises: analyzing a real-time safety management policy by a policy controller of a management server, the real-time safety management policy being implemented in a self-defined resource type; the policy content of the real-time safety management policy comprising: a rule for preventing and controlling a violation event and a matching label of a protected container group; determining a policy execution node based on the matching label, and issuing the rule for preventing and controlling the violation event to a node execution agent of the policy execution node, the policy execution node being a host node where the protected container group is located; generating and deploying a kernel-level prevention and control rule based on the rule for preventing and controlling the violation event issued by the policy controller of the management server through the node execution agent of the policy execution node, and executing the kernel-level prevention and control rule by a security module of the policy execution node. Embodiments of the present application can realize dynamic updating and unified control of a container operation safety policy.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a container operation safety management method, electronic device, and storage medium. Background Technology

[0002] When containers are running in a cluster, attackers may exploit application vulnerabilities to gain command-line interaction privileges, enabling them to execute malicious operations beyond the scope of the container's specifications—such as stealing temporary credentials by accessing cloud instance metadata services and loading kernel modules to create backdoors. Existing runtime security management solutions impose runtime restrictions through pre-defined system call filtering or file access control policies. However, these policies must be pre-written and loaded when the container starts, making them unable to be dynamically updated. Furthermore, these policies exist as host machine files and are not part of the cluster's native resources, lacking unified management. Static policy persistence and decentralized rule management can further lead to problems such as delayed security responses, a surge in operational complexity, and limitations in scaling and fault recovery. Summary of the Invention

[0003] This invention provides a container operation security management method, electronic device, and storage medium, which can realize dynamic updating and unified management of container operation security policies.

[0004] In a first aspect, embodiments of the present invention provide a container operation security management method, comprising: The real-time security management policy is parsed by the policy controller on the management server. The real-time security management policy is implemented using custom resource types. The policy content of the real-time security management policy includes: violation event prevention and control rules and matching tags of the protected container groups corresponding to the violation event prevention and control rules. The policy execution node is determined based on the matching tags, and the violation event prevention and control rules are sent to the node execution agent of the policy execution node. The policy execution node is the host node where the protected container group is located. The node execution agent of the policy execution node generates and deploys kernel-level prevention and control rules based on the violation event prevention and control rules issued by the policy controller of the management server, and uses the security module of the policy execution node to execute the kernel-level prevention and control rules to perform operational security management of the protected container group.

[0005] Secondly, embodiments of the present invention also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the container operation security management method as described in any of the embodiments of the present invention.

[0006] Thirdly, embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the container operation security management method as described in any of the embodiments of the present invention.

[0007] This invention provides a container runtime security management method, electronic device, and storage medium. The method involves a management server's policy controller parsing real-time security management policies and determining policy execution nodes and node execution agents that distribute violation prevention rules to these nodes based on matching tags in the security management policies. Furthermore, the node execution agents of these policy execution nodes generate and deploy kernel-level prevention rules based on the violation prevention rules distributed by the management server's policy controller. Finally, a security policy execution backend executes these kernel-level prevention rules to manage the runtime security of protected container groups. This security management can be achieved through CRD (Custom Resource Definition) structures. This policy enables security administrators to adopt a declarative configuration management approach, submitting resource configurations to the cluster via command-line tools and querying resource status and details in real time. Simultaneously, this CRD mechanism fully integrates security policy operations into the cluster's native management model, preventing security policies from being statically formatted as files. Instead, they become dynamic resources subject to unified scheduling and hot updates. Security teams no longer need to maintain a separate security policy distribution toolchain, thus eliminating the risk of configuration inconsistencies caused by fragmented rule management. This effectively alleviates issues such as delayed security response, increased operational complexity, and limitations on scaling and fault recovery, ultimately improving the security and operational efficiency of the container runtime environment. Attached Figure Description

[0008] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a flowchart illustrating a container operation security management method provided in an embodiment of the present invention; Figure 2 This is another flowchart illustrating the container operation security management method provided in this embodiment of the invention; Figure 3 This is another flowchart illustrating the container operation security management method provided in this embodiment of the invention; Figure 4 This is another flowchart illustrating the container operation security management method provided in this embodiment of the invention; Figure 5This is another flowchart illustrating the container operation security management method provided in this embodiment of the invention; Figure 6 This is a schematic diagram of a container operation safety management device provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0010] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0011] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0012] Figure 1 This is a flowchart illustrating a container runtime security management method provided in an embodiment of the present invention. This embodiment is applicable to the runtime management of container groups in a Kubernetes cluster. The method can be executed by the container runtime security management device provided in this embodiment, which can be implemented in software and / or hardware. In a specific embodiment, the device can be integrated into an electronic device, such as a computer or server. The following embodiments will illustrate this using the integration of the device into an electronic device as an example. (Reference) Figure 1 The method may specifically include the following steps: Step 101 involves parsing the real-time security management policy through the policy controller on the management server. The real-time security management policy is implemented using a Custom Resource Definition (CRD). The policy content includes violation event prevention rules and matching tags for the protected container groups corresponding to these rules. Based on the matching tags, the policy execution node is determined, and the violation event prevention rules are distributed to the node execution agent of the policy execution node, which is the host node where the protected container group resides. This step, by implementing the security management policy in the form of a CRD, enables security administrators to adopt a declarative configuration management approach. They can submit resource configurations to the cluster via command-line tools and query resource status and view details in real time. Simultaneously, this CRD mechanism fully integrates the operation and maintenance of security policies into the native Kubernetes management model, ensuring that security policies are no longer static files but rather dynamic resources subject to unified scheduling and hot updates.

[0013] Specifically, the policy controller mentioned above can be deployed on the cluster control plane as a Kubernetes Deployment.

[0014] Specifically, security administrators can write the above security management policies declaratively using YAML.

[0015] Specifically, the matching tags of the aforementioned protected container groups are used to define which container groups the real-time security management policy applies to. The mapping relationship between containers and the corresponding security management policies can be stored in key-value pairs.

[0016] Specifically, the matching tags mentioned above may include application category identifiers, such as app:nginx, deployment environment identifiers, such as env:production, and / or identifiers that specify the effective namespace, i.e., matchNamespaces.

[0017] Specifically, multiple matching tag conditions can be combined, and the corresponding container group will be identified as a protected container group only when multiple matching tags are met at the same time.

[0018] Optionally, the rules for preventing violations include: process access rules, file access control rules, network access control rules, and kernel capability access rules.

[0019] Specifically, the above process admission rules can be understood as rules for preventing violations of processes that are allowed or prohibited from executing within a container.

[0020] Specifically, the aforementioned process access rules may include: path information, control operation information, and user information. Path information may include the absolute path of the executable file and / or wildcard matching patterns; control operation information may include allowing execution and denying execution; and user information includes process user account information, such as "super administrator information, i.e., root information" or "system account information, i.e., www-data information."

[0021] Specifically, the above file access control rules can be understood as rules for preventing violations of the rules used to define the file paths and operation types that are allowed or prohibited within the container.

[0022] Specifically, the above file access control rules may include: path information, file operation type, and control operation information; among which, file operation type may include, for example, operations such as: read, write, append, delete, rename, and / or move.

[0023] Specifically, the aforementioned network access control rules can be understood as rules for preventing violations of network communication targets or protocols that are allowed or prohibited by the container.

[0024] Specifically, the aforementioned network access control rules may include: target network segment / network address, target port, communication protocol, and prevention and control operation information.

[0025] Specifically, the above kernel capability admission rules can be understood as defining kernel capabilities that are allowed but then prohibited within a container.

[0026] Specifically, the aforementioned kernel capability admission rules may include kernel capabilities used for prevention and control and prevention and control operation information; among which, the kernel capabilities used for prevention and control include system management capabilities (CAP_SYS_ADMIN), raw network socket capabilities (CAP_NET_RAW), BPF operation capabilities, and / or kernel module loading capabilities, etc.

[0027] In practical applications, real-time security management strategies can also include a general execution mode for prevention and control rules, which is used to define the overall execution mode of the rules for preventing and controlling violations.

[0028] Specifically, the overall execution modes of the aforementioned prevention and control rules may include: forced blocking mode, audit-only mode, and / or explicit allow mode; among which, forced blocking mode can be a mode in which all violations are directly blocked by the kernel, the attack operation is ineffective and the violation event is recorded, and this mode is suitable for production scenarios; audit-only mode can be a mode in which violations are allowed by the kernel but the violation event is recorded, which is used for policy trial operation and gray-scale verification; explicit allow mode is a mode in which whitelist exceptions are opened for specific operations.

[0029] Specifically, in this embodiment of the invention, the operating system of the policy execution node can be Linux (an open-source operating system).

[0030] Specifically, there can be multiple rules for preventing and controlling violations.

[0031] Specifically, the process of determining policy execution nodes based on matching tags may include: determining protected container groups according to the matching tags corresponding to each violation prevention and control rule; grouping the protected container groups according to their host nodes, constructing a node-prevention and control rule mapping relationship based on the grouping, and further determining the host nodes that have a node-prevention and control rule mapping relationship with each node as the policy execution nodes of the corresponding rules.

[0032] Specifically, the process of distributing violation prevention and control rules to the node execution agent of the policy execution node may include: distributing the violation prevention and control rules to the node execution agent of the policy execution node through the CRD status channel or gRPC (a high-performance communication protocol within the cluster).

[0033] Step 102 involves using the node execution agent of the policy execution node to generate and deploy kernel-level prevention and control rules based on the violation event prevention and control rules issued by the policy controller on the management server. The security module of the policy execution node then executes these kernel-level prevention and control rules to manage the operational security of the protected container group. Building upon step 101, this step allows the security management policies on the policy execution node to move beyond being static files and become dynamic resources subject to unified scheduling and hot updates. The security team no longer needs to maintain a separate security policy distribution toolchain, thus eliminating the risk of inconsistent configurations caused by fragmented rule management. This effectively alleviates problems such as delayed security response, increased operational complexity, and limited scaling and fault recovery, thereby improving the security and operational efficiency of the container runtime environment.

[0034] Specifically, the process of generating and deploying kernel-level prevention and control rules based on the violation event prevention and control rules issued by the policy controller on the management server may include: translating the violation event prevention and control rules into kernel-level prevention and control rules, generating a security check program based on the kernel-level prevention and control rules, and inserting the security check program into the security check hook of the Linux security module to perform policy verification on the system call path.

[0035] Specifically, the aforementioned security check hooks may include process startup check hooks, file access control hooks, network communication control hooks, and / or kernel capability control hooks.

[0036] Specifically, the process of executing kernel-level prevention and control rules using the security module of the policy execution node can include: when the kernel execution of the security module reaches the corresponding security check hook, it triggers a security check program generated based on the kernel-level prevention and control rules to perform policy verification.

[0037] Optionally, the process of using the security module of the policy execution node to execute kernel-level control rules to perform runtime security management of the protected container group includes: before the system call of the policy execution node completes permission checks and creates a new program image, and before the target program starts execution, the process startup check hook of the policy execution node checks whether the target program is allowed to execute based on process admission rules; if the target program is allowed to execute, at least one of the following three items is executed: before the process corresponding to the target program operates on a file, the file access control hook of the policy execution node checks whether the process corresponding to the target program is allowed to operate on the corresponding file based on file access control rules; before the process corresponding to the target program performs network communication, the network communication control hook of the policy execution node checks whether the process corresponding to the target program is allowed to perform network communication based on network access control rules; before the execution of an operation of the process corresponding to the target program that depends on a specific kernel capability triggers the specific kernel capability, the kernel capability control hook of the policy execution node checks whether the process corresponding to the target program is allowed to use the specific kernel capability.

[0038] It is understood that, by implementing kernel-level prevention rules at the moment the attack process triggers system calls, the kernel performs security checks, and permission determinations, this embodiment of the invention can prevent attacks from even taking the first step. Furthermore, before the process operates on files, conducts network communication, and / or triggers specific kernel capabilities when performing operations that rely on specific kernel capabilities, this embodiment further checks the corresponding permissions during process execution. Regardless of the step an attacker takes or the method used to attempt an attack—whether by creating malicious processes, tampering with critical files, or establishing external network connections—the attacker will be caught by the security check hooks on the corresponding path. This ensures zero-delay, unbypassable interception of violations, guaranteeing that all illegal operations are blocked before they are actually executed, effectively improving the security of the container runtime environment.

[0039] Optionally, the process of using the security module of the policy execution node to execute kernel-level prevention and control rules to perform runtime security management of the protected container group includes: identifying whether a violation event has occurred in the protected container group based on the kernel-level prevention and control rules; if a violation event occurs, reading the violation event from the kernel cache or parsing the violation event from the kernel audit log, converting the violation event into an alarm resource object, and writing the alarm resource object to the resource management center (Kubernetes API Server) so that the security administrator can view the violation event in real time; the alarm resource object is implemented using a custom resource type.

[0040] Specifically, the process of reading violation events from the kernel cache or parsing them from the kernel audit log if a violation event occurs can include: reading violation events through the BPF ring buffer when the security policy execution backend is a BPFLinux backend; obtaining violation events by parsing AppArmor rejection events in the kernel audit log (audit.log) when the security policy execution backend is an AppArmor backend; and obtaining violation events by parsing SELinux rejection events in the audit log when the security policy execution backend is an SELinux backend.

[0041] Specifically, the aforementioned alarm resource objects may include the timestamp corresponding to the violation event, container group identifier, namespace identifier, container identifier, process identifier, full path of the process, security policy identifier, prevention and control rule identifier, violation operation information, source IP address, and / or the cumulative number of violations under the same rule, wherein the cumulative number of violations under the same rule can be used for trend analysis.

[0042] The embodiments of the present invention can obtain the security status map of the cluster during runtime through a single query entry, enabling security operation and maintenance personnel to query the real-time security status of the entire cluster, further reducing the complexity of operation and maintenance.

[0043] The following further describes the container operation security management method provided by the embodiments of the present invention, such as... Figure 2 As shown, it may also include the following steps executed by the policy controller on the management server: Step 201: Analyze the real-time security management strategy.

[0044] Step 202: Determine the policy execution node based on the matching tags, and send the violation prevention and control rules to the node execution agent of the policy execution node.

[0045] Step 203: Monitor container group creation events, container group deletion events, and security policy update events.

[0046] Step 204A: After detecting the container group creation event, determine whether the newly created container group is a protected container group based on the matching tag; if the newly created container group is a protected container group, determine the host node where the newly created container group is located as the newly added policy execution node, and send the violation event prevention and control rules to the newly added policy execution node.

[0047] Step 204B: After detecting a container group deletion event, send a container deletion notification to the agent of the node corresponding to the deleted container group.

[0048] Step 204C: After detecting a security policy update event, determine the details of the real-time security management policy change, and restart the execution of the policy execution node determined by matching tags based on the change details, or restart the execution of the node execution agent that distributes the violation event prevention and control rules to the policy execution node.

[0049] Specifically, the node execution agent provided in this embodiment of the invention can clean up kernel-level prevention and control rules after receiving a container deletion notification, so as to release the corresponding kernel resources.

[0050] The embodiments of the present invention can continuously track the lifecycle of container groups, and automatically configure security management policies without manual intervention when adding or deleting container groups or updating policies, thereby reducing operation and maintenance costs.

[0051] The following further describes the container operation security management method provided by the embodiments of the present invention, such as... Figure 3 As shown, it can also include the following steps of node execution agent execution: Step 301: Detect and determine the security policy execution backend of the policy execution node based on the security module types supported by the policy execution node.

[0052] Optionally, the policy enforcement node supports one or more of the following security module types: BPFLinux (Berkeley Package Filtering Framework implemented in the Linux kernel), AppArmor (Application Security Protection Module), and SELinux (Security Enhanced Linux).

[0053] Understandably, in Linux systems, the extension of kernel security capabilities is typically achieved through the Linux Security Module (LSM) framework. Based on this framework, the system can employ various mandatory access control (MAC) implementation schemes. Among them, BPFLinux, as a flexible kernel programming framework, supports the development of efficient runtime security programs and can serve as a flexible supplement to LSM. Based on or running parallel to BPFLinux, AppArmor and SELinux are two mainstream LSM implementations: the former focuses on lightweight permission restrictions on applications via pathnames, while the latter provides fine-grained tagging management of all resources within the system.

[0054] Optional, such as Figure 4 As shown, step 301 may include: Step 3011: Probe whether the policy execution node supports BPFLinux.

[0055] Optionally, the process of detecting whether a policy execution node supports BPFLinux includes: attempting to mount the smallest running unit of the BPF program to the kernel security module check hook of the policy execution node through the BPF system of the policy execution node; if the mounting is successful, it is determined that the policy execution node supports BPFLinux; otherwise, it is determined that the policy execution node does not support BPFLinux.

[0056] Specifically, you can also use BPF management tools to check whether the policy execution node supports BPFLinux.

[0057] Step 3012: If BPFLinux is supported, the security policy execution backend is determined to be the BPFLinux backend; otherwise, the policy execution node is probed to see if it supports AppArmor.

[0058] Optionally, the process of detecting whether the policy execution node supports AppArmor includes: checking whether the kernel interface path of AppArmor ( / sys / kernel / security / apparmor) exists in the file system of the policy execution node; if it exists, it is determined that the policy execution node supports AppArmor; otherwise, it is determined that the policy execution node does not support AppArmor.

[0059] Step 3013: If AppArmor is supported, the security policy execution backend is determined to be the AppArmor backend; otherwise, the policy execution node is probed to see if it supports SELinux.

[0060] Optionally, the process of detecting whether the policy execution node supports SELinux includes: checking whether the SELinux kernel interface path ( / sys / fs / selinux) exists in the file system of the policy execution node. If it exists, the policy execution node is determined to support SELinux; otherwise, the policy execution node is determined to support SELinux.

[0061] Step 3014: If SELinux is supported, the security policy execution backend is determined to be the AppArmor backend.

[0062] Specifically, the process of detecting and determining the security policy execution backend of the policy execution node based on the security module types supported by the policy execution node may also include: detecting whether the policy execution node supports BPFLinux, AppArmor, and SELinux in any order.

[0063] Specifically, the process of determining the security policy execution backend of the policy execution node based on the security module type supported by the policy execution node may include: the agent selects the backend according to priority—BPFLSM is preferred (lowest kernel-level performance overhead, widest hook coverage, and minimum dynamic loading latency). If it is unavailable, it falls back to AppArmor. If it is still unavailable, it falls back to SELinux.

[0064] Understandably, probing and selecting backends in descending order of priority for BPFLinux, AppArmor, and SELinux can improve probing efficiency and ensure the efficiency of loading and maintaining security controls for subsequent container operation.

[0065] Step 302: Configure the security module of the policy execution node as the security policy execution backend.

[0066] Step 303: Generate and deploy kernel-level prevention and control rules based on the security module type corresponding to the security policy execution backend and the violation event prevention and control rules issued by the policy controller of the management server.

[0067] Optionally, the process of generating and deploying kernel-level prevention and control rules based on the security module type corresponding to the security policy execution backend and the policy controller issued by the management server includes: when the security policy execution backend is a BPF Linux backend, compiling each prevention and control rule into a BPF security check program; attaching each BPF security check program to the corresponding security module check hook; and associating each BPF security check program with the control group where the protected container group is located.

[0068] Specifically, the above prevention and control rules may include one or more of the following four types of rule parameters: path, operation, network segment / network address, and / or kernel capability.

[0069] Specifically, the process of compiling each prevention and control rule into a BPF security check program may include: writing the rule parameters into a read-only data segment of the BPF security check program.

[0070] Optionally, the process of generating and deploying kernel-level prevention and control rules based on the security module type corresponding to the security policy execution backend and the policy controller issued by the management server includes: When the security policy execution backend is an AppArmor backend, each prevention rule is converted into an AppArmor rule statement, and an AppArmor configuration file is generated using each AppArmor rule statement; the AppArmor configuration file is loaded into the security module; and the AppArmor configuration file is configured to take effect on the protected container group.

[0071] Specifically, the process of converting each control rule into an AppArmor rule statement can include: converting each file access control rule into an AppArmor file permission statement, such as: deny / etc / shadowr means denying reading files under the path / etc / shadow.

[0072] Specifically, the process of converting each control rule into an AppArmor rule statement may include: converting each network access control rule into a network permission statement, such as deny network inettcp, which means denying TCP network communication.

[0073] Specifically, the process of converting each prevention and control rule into an AppArmor rule statement may include: converting each kernel capability admission rule into a kernel capability permission statement, such as denycapability sys_module, which means denying the loading of kernel modules.

[0074] Specifically, the process of configuring the AppArmor configuration file to take effect on the protected container group may include: writing the AppArmor configuration file into the process attribute of the process corresponding to the protected container group, or binding the AppArmor configuration file to the protected container group through the AppArmor annotation mechanism.

[0075] Specifically, the process of using the security module of the policy execution node to execute kernel-level prevention and control rules to perform runtime security management of the protected container group may include: before the process of the protected container group performs file management operations, conducts network communication, or triggers kernel capabilities, it is determined whether the corresponding operation is allowed based on the AppArmor configuration file bound to the protected container group. If allowed, it returns normally; otherwise, it returns EACCES and rejects the corresponding operation.

[0076] Optionally, the process of generating and deploying kernel-level prevention and control rules based on the security module type corresponding to the security policy execution backend and the policy controller issued by the management server includes: when the security policy execution backend is an SELinux backend, converting each prevention and control rule into an SELinux control rule and generating an SELinux access control rule package using each SELinux control rule; loading the SELinux access control rule package into the security module; and configuring the SELinux access control rule package to take effect on the protected container group.

[0077] Specifically, the aforementioned SELinux control rules may include: file access type enforcement rules, network context rules, and kernel capability object category operation vectors.

[0078] Specifically, file access type enforcement rules can be understood as the rules in the SELinux type enforcement mechanism that define the access permissions of the master process to guest files, granting specific processes access permissions to specific types of files; network context can be understood as a set of declarative rules used to define the security context (type labels) of network objects; and kernel capability object category operation vectors can be understood as a set of permissions in SELinux used to describe and determine whether a process has specific kernel operation permissions.

[0079] Specifically, the process of converting each control rule into an SELinux control rule can include converting each file access control rule into an SELinux file access type enforcement rule.

[0080] Specifically, the process of converting each control rule into an SELinux control rule can include converting each network access control rule into a network context rule.

[0081] Network context rules can include: network interface context rules for setting security contexts for network interfaces, network interface context rules for setting security contexts for network nodes, and network port context rules for setting security contexts for network ports.

[0082] Specifically, the process of converting each prevention and control rule into an SELinux control rule may include: converting each kernel capability admission rule into a kernel capability object category operation vector. Specifically, the process of generating SELinux access control rule packages using various SELinux control rules can include: compiling each SELinux control rule into a rule package.

[0083] Specifically, the process of configuring the SELinux access control rule package to take effect on the protected container group may include: setting the security context of each SELinux control rule for the protected container group, so that the SELinux Access Vector Cache (AVC) component of the security module kernel executes the SELinux control rules when checking the access of resources such as files, networks, and capabilities in the process.

[0084] Step 304: Execute kernel-level control rules using the security module of the policy execution node to manage the operational security of the protected container group.

[0085] Specifically, the process of using the security module of the policy execution node to execute kernel-level control rules to perform runtime security management on the protected container group may include: when a process of the protected container group triggers a response system call, extracting the actual value corresponding to the rule parameter from the corresponding check hook parameter, and returning an indication value indicating permission, such as 0, to the process that initiated the system call based on the rule parameter and the corresponding actual value; or returning an indication value indicating denial, such as EPERM; and blocking the corresponding process in place when the returned indication value is EPERM.

[0086] Specifically, the process of using the security module of the policy execution node to execute kernel-level prevention and control rules to perform runtime security management of the protected container group may include: before the process of the protected container group performs file management operations, network communication, or triggers kernel capabilities, it determines whether the corresponding operation is allowed based on the AppArmor configuration file bound to the protected container group. If allowed, it returns normally; otherwise, it returns EACCES and rejects the corresponding operation.

[0087] The following further describes the container operation security management method provided by the embodiments of the present invention.

[0088] Optionally, there may be multiple rules for preventing violations, including at least two of the following three levels: cluster-level rules, namespace-level rules, and container group-level rules. Cluster-level rules have a lower priority than namespace-level rules, and namespace-level rules have a lower priority than container group-level rules.

[0089] Specifically, the above cluster-level rules can be understood as rules for preventing violations of regulations for each container group within the cluster; the above namespace-level rules can be understood as rules for preventing violations of regulations for container groups within a specific namespace; and the above container group-level rules can be understood as rules for preventing violations of regulations for specific containers.

[0090] Optional, such as Figure 5 As shown, that is Figure 1 Step 102 may include the following steps: Step 1021: Determine whether there are conflicting rules of different levels among the multiple rules for preventing and controlling violations.

[0091] Specifically, the aforementioned conflicting violation prevention rules at different levels are as follows: Cluster-level rule A: Allows write operations to / etc / nginx / nginx.conf; Namespace-level rule B: Prohibits write operations to / etc / nginx / nginx.conf; Container-level rule C: Allows write operations to / etc / nginx / nginx.conf, where the application object is container group 1.2. A and B, and B and C are conflicting violation prevention rule pairs at different levels.

[0092] Step 1022: If they exist, identify the rule with higher priority among the conflicting rule for preventing and controlling violations at different levels as the priority rule, and determine the effective rule based on the priority rule.

[0093] Specifically, the process of determining the rule with higher priority among conflicting rules for preventing and controlling violations of different levels includes: for conflicting rules A and B of different levels, B is determined as the priority rule because A has a lower priority than B; for conflicting rules B and C, C is determined as the priority rule because B has a lower priority than C.

[0094] Specifically, the process of determining effective prevention and control rules based on priority prevention and control rules may include: determining priority prevention and control rules as effective prevention and control rules.

[0095] Specifically, the process of determining effective prevention and control rules based on priority prevention and control rules may include: if there are other violation event prevention and control rules that are different from and conflict with the priority prevention and control rules, then the violation event prevention and control rule with the higher priority level among the priority prevention and control rules and the other violation event prevention and control rules shall be used as the effective prevention and control rule.

[0096] In a specific instance, there exists another violation prevention rule C that is different from and conflicts with the priority prevention rule B. Since C has a higher priority, C is determined to be the effective prevention rule.

[0097] Step 1023: Deploy the effective prevention and control rules to take effect.

[0098] Specifically, embodiments of the present invention also include: refusing to deploy non-priority violation prevention and control rules in pairs of violation prevention and control rules that have different and conflicting levels.

[0099] The embodiments of the present invention enable cluster administrators to define only one global baseline policy in large-scale cluster scenarios, and each team can add more refined namespace-level rules on the baseline as needed, thereby making management more efficient.

[0100] Figure 6 This is a structural diagram of a container operation safety management device provided in an embodiment of the present invention. This device is suitable for executing the container operation safety management method provided in an embodiment of the present invention. Figure 6 As shown, the device may specifically include: The policy controller 601, deployed on the management server, parses real-time security management policies. These policies are implemented using custom resource types. The policy content includes violation event prevention rules and matching tags for the protected container groups corresponding to those rules. Based on the matching tags, the policy execution node is determined, and the violation event prevention rules are distributed to the node execution agent of that node. The policy execution node is the host node where the protected container group resides. By implementing security management policies in the form of CRDs (Custom Resource Definitions), security administrators can adopt a declarative configuration management approach, submitting resource configurations to the cluster via command-line tools and querying resource status and details in real time. Simultaneously, this CRD mechanism fully integrates security policy operation and maintenance into the native Kubernetes management model, ensuring that security policies are no longer static files but rather dynamic resources subject to unified scheduling and hot updates.

[0101] Optionally, the rules for preventing violations include: process access rules, file access control rules, network access control rules, and kernel capability access rules.

[0102] Optionally, the policy controller 601 can be specifically used to monitor container group creation events, and after detecting a container group creation event, determine whether the newly created container group is a protected container group based on matching tags; if the newly created container group is a protected container group, then the host node where the newly created container group is located is determined as a newly added policy execution node, and the violation event prevention and control rules are sent to the newly added policy execution node.

[0103] Optionally, the policy controller 601 can be specifically used to: monitor container group deletion events and security policy update events through the policy controller on the management server; after detecting a container group deletion event, send a container deletion notification to the node execution agent corresponding to the deleted container group; and after detecting a security policy update event, determine the change details of the real-time security management policy, and restart the execution of the policy execution node determined by matching tags based on the change details, or restart the execution of the node execution agent that distributes the violation event prevention and control rules to the policy execution node.

[0104] The node execution agent 602, deployed on the policy execution node, generates and deploys kernel-level prevention and control rules based on the violation event prevention and control rules issued by the policy controller on the management server. It also utilizes the security module of the policy execution node to execute these kernel-level prevention and control rules for operational security management of protected container groups. Working in conjunction with the policy controller 601, it ensures that security management policies on the policy execution node are no longer fixed as static files, but rather treated as dynamic resources subject to unified scheduling and hot updates. The security team no longer needs to maintain a separate security policy distribution toolchain, thus eliminating the risk of inconsistent configurations caused by decentralized rule management. This effectively alleviates problems such as delayed security response, increased operational complexity, and limited scaling and fault recovery, improving the security and operational efficiency of the container runtime environment.

[0105] Optionally, the node agent execution 602 can be specifically used to, before the system call of the policy execution node completes permission checks and creates a new program image, and before the target program begins execution, check whether the target program is allowed to execute based on process admission rules through the process startup check hook of the policy execution node; if the target program is allowed to execute, then execute at least one of the following three: before the process corresponding to the target program operates on a file, check whether the process corresponding to the target program is allowed to operate on the corresponding file based on file access control rules through the file access control hook of the policy execution node; before the process corresponding to the target program performs network communication, check whether the process corresponding to the target program is allowed to perform network communication based on network access control rules through the network communication control hook of the policy execution node; before the execution of the process corresponding to the target program depends on a specific kernel capability and triggers the specific kernel capability, check whether the process corresponding to the target program is allowed to use the specific kernel capability through the kernel capability control hook of the policy execution node.

[0106] Optionally, the node agent execution 602 can be specifically used to: detect and determine the security policy execution backend of the policy execution node based on the security module type supported by the policy execution node; configure the security module of the policy execution node as the security policy execution backend; and generate and deploy kernel-level prevention and control rules based on the security module type corresponding to the security policy execution backend and the violation event prevention and control rules issued by the policy controller of the management server.

[0107] Optionally, the policy enforcement node supports one or more of the following security module types: BPFLinux, AppArmor, and SELinux.

[0108] Optionally, the node agent's execution of 602 can be specifically used to: detect whether the policy execution node supports BPFLinux; if it supports BPFLinux, then the security policy execution backend is determined to be a BPFLinux backend; otherwise, detect whether the policy execution node supports AppArmor; if it supports AppArmor, then the security policy execution backend is determined to be an AppArmor backend; otherwise, detect whether the policy execution node supports SELinux; if it supports SELinux, then the security policy execution backend is determined to be an AppArmor backend.

[0109] Optionally, the node agent's execution of 602 can be specifically used to: attempt to mount the smallest running unit of the BPF program to the kernel security module check hook of the policy execution node through the BPF system of the policy execution node; if the mounting is successful, it is determined that the policy execution node supports BPFLinux; otherwise, it is determined that the policy execution node does not support BPFLinux; check if the kernel interface path of AppArmor exists in the file system of the policy execution node; if it exists, it is determined that the policy execution node supports AppArmor; otherwise, it is determined that the policy execution node does not support AppArmor; check if the kernel interface path of SELinux exists in the file system of the policy execution node; if it exists, it is determined that the policy execution node supports SELinux; otherwise, it is determined that the policy execution node supports SELinux.

[0110] Optionally, the node agent's execution of 602 can be specifically used for the following purposes: when the security policy execution backend is a BPF Linux backend, compiling each prevention rule into a BPF security check program; attaching each BPF security check program to the corresponding security module check hook; and associating each BPF security check program with the control group where the protected container group resides; when the security policy execution backend is an AppArmor backend, converting each prevention rule into an AppArmor rule statement and generating an AppArmor configuration file using each AppArmor rule statement; loading the AppArmor configuration file into the security module; and configuring the AppArmor configuration file to take effect on the protected container group; when the security policy execution backend is an SELinux backend, converting each prevention rule into an SELinux control rule and generating an SELinux access control rule package using each SELinux control rule; loading the SELinux access control rule package into the security module; and configuring the SELinux access control rule package to take effect on the protected container group.

[0111] Optionally, the node agent's execution of a 602 error can be specifically used to clean up kernel-level prevention rules after receiving a container deletion notification.

[0112] Optionally, there may be multiple rules for preventing violations, including at least two of the following three levels: cluster-level rules, namespace-level rules, and container group-level rules. Cluster-level rules have a lower priority than namespace-level rules, and namespace-level rules have a lower priority than container group-level rules.

[0113] Optionally, the node agent's execution of 602 can be specifically used to determine whether there are conflicting pairs of violation event prevention and control rules among multiple violation event prevention and control rules; if so, the violation event prevention and control rule with the higher priority among the conflicting pairs of violation event prevention and control rules is determined as the priority prevention and control rule, and the effective prevention and control rule is determined based on the priority prevention and control rule; and the effective prevention and control rule is deployed to take effect.

[0114] Optionally, the node agent's execution of 602 can be specifically used to identify whether a violation event has occurred in a protected container group based on kernel-level prevention and control rules; if a violation event occurs, it reads the violation event from the kernel cache or parses the violation event from the kernel audit log; it converts the violation event into an alarm resource object and writes the alarm resource object to the resource management center so that the security administrator can view the violation event in real time; the alarm resource object is implemented using a custom resource type.

[0115] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is merely an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the functional modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0116] This invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the container operation security management method provided in any of the above embodiments.

[0117] This invention also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the container operation security management method provided in any of the above embodiments.

[0118] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the container operation security management method as described in any of the embodiments of this invention.

[0119] The following is for reference. Figure 7It shows a schematic diagram of the structure of a computer system 700 suitable for implementing an electronic device according to embodiments of the present invention. Figure 7 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0120] like Figure 7 As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 702 or programs loaded from storage section 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the system 700. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0121] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0122] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit (CPU) 701, it performs the functions defined above in the system of this invention.

[0123] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0125] The modules and / or units described in the embodiments of this invention can be implemented in software or hardware. The described modules and / or units can also be located in a processor. The names of these modules do not, in some cases, constitute a limitation on the module itself.

[0126] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include: parsing a real-time security management policy through a policy controller of a management server, wherein the real-time security management policy is implemented using a custom resource type; the policy content of the real-time security management policy includes: violation event prevention rules and matching tags for protected container groups corresponding to the violation event prevention rules; determining a policy execution node based on the matching tags and distributing the violation event prevention rules to a node execution agent of the policy execution node, wherein the policy execution node is the host node where the protected container group resides; generating and deploying kernel-level prevention rules based on the violation event prevention rules distributed by the policy controller of the management server through the node execution agent of the policy execution node; and executing the kernel-level prevention rules using the security module of the policy execution node to perform runtime security management on the protected container group.

[0127] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for managing the safety of container operation, characterized in that, include: The real-time security management policy is parsed by the policy controller on the management server, and the real-time security management policy is implemented using a custom resource type. The real-time security management policy includes: violation event prevention and control rules and matching tags for the protected container groups corresponding to the violation event prevention and control rules; determining the policy execution node based on the matching tags, and distributing the violation event prevention and control rules to the node execution agent of the policy execution node, wherein the policy execution node is the host node where the protected container group is located; The node execution agent of the policy execution node generates and deploys kernel-level prevention and control rules based on the violation event prevention and control rules issued by the policy controller of the management server, and uses the security module of the policy execution node to execute the kernel-level prevention and control rules to perform operational security management of the protected container group.

2. The container operation safety management method according to claim 1, characterized in that, The rules for preventing and controlling violations include: process access control rules, file access control rules, network access control rules, and kernel capability access control rules; The security module of the policy execution node executes the kernel-level prevention and control rules to manage the operational security of the protected container group, including: Before the system call of the policy execution node completes the permission check and new program image and starts executing the target program, the process startup check hook of the policy execution node checks whether the target program is allowed to execute based on the process admission rules. If the target program is allowed to execute, then execute at least one of the following three: Before the target program's corresponding process operates on the file, the file access control hook of the policy execution node checks whether the target program's corresponding process is allowed to operate on the corresponding file based on the file access control rules; Before the process corresponding to the target program can perform network communication, the network communication control hook of the policy execution node checks whether the process corresponding to the target program is allowed to perform network communication based on the network access control rules. Before triggering the specific kernel capability when the execution of the process corresponding to the target program depends on the specific kernel capability, the kernel capability control hook of the policy execution node checks whether the process corresponding to the target program is allowed to use the specific kernel capability.

3. The container operation safety management method according to claim 1, characterized in that, Before generating and deploying kernel-level prevention and control rules based on the violation event prevention and control rules issued by the policy controller of the management server, the method further includes executing an agent through a node: Detect and determine the security policy execution backend of the policy execution node based on the security module types supported by the policy execution node; Configure the security module of the policy execution node as the backend for the security policy execution; The generation and deployment of kernel-level prevention and control rules based on the violation event prevention and control rules issued by the policy controller of the management server includes: Based on the security module type corresponding to the security policy execution backend and the violation event prevention and control rules issued by the policy controller of the management server, kernel-level prevention and control rules are generated and deployed.

4. The container operation safety management method according to claim 3, characterized in that, The security module types supported by the policy execution node include one or more of the following three types: BPFLinux, AppArmor, and SELinux: The process of detecting and determining the security policy execution backend of the policy execution node based on the security module types supported by the policy execution node includes: Detect whether the policy execution node supports BPFLinux; If BPFLinux is supported, the security policy execution backend will be determined to be a BPFLinux backend; otherwise, it will be detected whether the policy execution node supports AppArmor. If AppArmor is supported, the security policy execution backend will be determined as the AppArmor backend; otherwise, it will be detected whether the policy execution node supports SELinux. If SELinux is supported, the security policy execution backend will be set to the AppArmor backend.

5. The container operation safety management method according to claim 4, characterized in that, The step of detecting whether the policy execution node supports BPFLinux includes: attempting to mount the smallest running unit of the BPF program to the kernel security module check hook of the policy execution node through the BPF system of the policy execution node; if the mounting is successful, it is determined that the policy execution node supports BPFLinux; otherwise, it is determined that the policy execution node does not support BPFLinux. The step of detecting whether the policy execution node supports AppArmor includes: checking whether the kernel interface path of AppArmor exists in the file system of the policy execution node; if it exists, it is determined that the policy execution node supports AppArmor; otherwise, it is determined that the policy execution node does not support AppArmor. The step of detecting whether the policy execution node supports SELinux includes: checking whether the SELinux kernel interface path exists in the file system of the policy execution node; if it exists, the policy execution node is determined to support SELinux; otherwise, the policy execution node is determined to support SELinux.

6. The container operation safety management method according to claim 3, characterized in that, The security policy execution backend is a BPFLinux backend, an AppArmor backend, or an SELinux backend; the violation event prevention and control rules include multiple prevention and control rules; The process of generating and deploying kernel-level prevention and control rules based on the security module type corresponding to the security policy execution backend and the violation event prevention and control rules issued by the policy controller of the management server includes: When the security policy execution backend is a BPFLinux backend, each prevention and control rule is compiled into a BPF security check program; each BPF security check program is mounted to the corresponding security module check hook; and each BPF security check program is associated with the control group where the protected container group is located. When the security policy execution backend is an AppArmor backend, each prevention and control rule is converted into an AppArmor rule statement, and an AppArmor configuration file is generated using each AppArmor rule statement; the AppArmor configuration file is loaded into the security module; and the AppArmor configuration file is configured to take effect on the protected container group. When the security policy execution backend is an SELinux backend, each prevention and control rule is converted into an SELinux control rule, and an SELinux access control rule package is generated using each SELinux control rule; the SELinux access control rule package is loaded into the security module; and the SELinux access control rule package is configured to take effect on the protected container group.

7. The container operation safety management method according to claim 1, characterized in that, Also includes: By managing the policy controller on the server side, the container group creation event is monitored, and after the container group creation event is detected, the newly created container group is determined to be a protected container group based on the matching tag. If the newly created container group is a protected container group, the host node where the newly created container group is located will be determined as the newly added policy execution node, and the violation event prevention and control rules will be issued to the newly added policy execution node.

8. The container operation safety management method according to claim 1, characterized in that, Also includes: Monitor container group deletion events and security policy update events through the policy controller on the management server; Upon detecting a container group deletion event, a container deletion notification is sent to the agent on the node corresponding to the deleted container group. And after detecting a security policy update event, determine the details of the real-time security management policy change, and restart the execution of the policy execution node determined based on the matching tag according to the change details, or restart the execution of the node execution agent that distributes the violation event prevention and control rules to the policy execution node; as well as The node execution agent of the policy execution node cleans up the kernel-level prevention and control rules after receiving the container deletion notification.

9. The container operation safety management method according to claim 1, characterized in that, The number of violation prevention and control rules is multiple, including rules at least two of the three levels of rules: cluster-level rules, namespace-level rules, and container group-level rules. The priority of the cluster-level rules is lower than that of the namespace-level rules, and the priority of the namespace-level rules is lower than that of the container group-level rules. The generation and deployment of kernel-level prevention and control rules based on the violation event prevention and control rules issued by the policy controller of the management server includes: Determine whether there are conflicting pairs of violation prevention and control rules of different levels among the multiple violation prevention and control rules; If such rules exist, the rule with the higher priority among the conflicting violation prevention rules at different levels will be designated as the priority prevention rule, and an effective prevention rule will be determined based on the priority prevention rule; and The effective prevention and control rules shall be deployed and put into effect.

10. The container operation safety management method according to claim 1, characterized in that, The security module of the policy execution node executes the kernel-level prevention and control rules to manage the operational security of the protected container group, including: Based on the kernel-level prevention and control rules, it is possible to identify whether a violation event has occurred in the protected container group; If a violation occurs, the violation event is read from the kernel cache or parsed from the kernel audit log; The violation event is converted into an alarm resource object and written to the resource management center so that the security administrator can view the violation event in real time; The alarm resource object is implemented using a custom resource type.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the container operation security management method as described in any one of claims 1 to 10.

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

Images