A cluster security checking method, device, equipment and storage medium

Abstract

Embodiments of the present application disclose a cluster security checking method and device, equipment and a storage medium, which can be applied to cloud technology, artificial intelligence and various scenes. The method can include: a master node creating a daemon process set in response to a create process set instruction sent by a back-end server through calling a cluster management interface; the master node calling the daemon process set and deploying an agent client and a container replica to each worker node according to a preset deployment strategy; and the master node distributing a checking task to the container replica of each worker node, so that the agent client of each worker node acquires the checking task from the corresponding container replica, executes the checking task on a target component and a workload, and sends a checking result to the back-end server. In the embodiments of the present application, the master node deploys the agent client to the worker node according to the preset deployment strategy, which can improve the stability and controllability of the agent client and is conducive to the safe operation of the cluster in a cloud-native environment.

Description

Technical Field

[0001] This application relates to the field of cloud security technology, and in particular to a cluster security inspection method, apparatus, device and storage medium. Background Technology

[0002] Cloud computing is a network that provides resources, including computing and storage capabilities, and is characterized by elasticity, agility, resource pooling, and service-orientation. In recent years, cloud computing has become a strategic focus for the development of the information technology industry, with global IT companies transforming towards cloud computing. Cloud-native is a new backend service architecture model developed based on cloud computing. Cloud-native technology architecture fully leverages the characteristics of cloud computing, changing the design, development, deployment, and operation modes of cloud applications, and providing a more convenient way for backend deployment and smooth upgrades. With the development of cloud computing, cloud-native has received increasing attention, leading to widespread concern about the secure deployment of cloud-native clusters. Cloud-native technology requires the decomposition and deployment of traditional services into microservices; therefore, cloud-native environments strive to achieve independent deployment of each environment and weaken environment permissions.

[0003] Currently, cloud-native security deployments are primarily based on the traditional Host-based Intrusion Detection System (HIDS) architecture. As a monitor and analyzer of a computer system, HIDS does not operate on external interfaces but focuses on the internal workings of the system, monitoring all or part of the system's dynamic behavior and the overall state of the computer system. However, agents deployed on the user's host (or node) in traditional solutions install drivers within the system, possessing high privileges. Furthermore, excessive agent resource consumption can lead to host resource exhaustion; if the agent malfunctions, the user environment will lose connection with the backend, directly impacting multiple business environments. Therefore, this approach suffers from low stability and controllability, hindering the secure operation of clusters in a cloud-native environment. Summary of the Invention

[0004] This application provides a cluster security inspection method, apparatus, device, and storage medium, which can improve the stability and controllability of proxy clients, thereby improving the effectiveness and stability of cluster security inspection and facilitating the secure operation of clusters in a cloud-native environment.

[0005] In a first aspect, embodiments of this application provide a cluster security inspection method, applied to a target business cluster comprising multiple nodes, including a master node and worker nodes, the method comprising:

[0006] The master node responds to the backend server's command to create a process set by calling the cluster management interface, and creates a daemon process set;

[0007] The master node invokes the daemon process set and deploys the agent client and container replica to each worker node according to the preset deployment strategy, which includes one or more of the following: resource control strategy, permission control strategy, and process management strategy.

[0008] The master node distributes the inspection tasks to the container replicas of each worker node, so that the agent client of each worker node can obtain the inspection tasks from the corresponding container replica, perform the inspection tasks on the target components and workloads, and send the inspection results to the backend server.

[0009] Secondly, embodiments of this application provide another cluster security inspection method, applied to a target business cluster comprising multiple nodes, including a master node and worker nodes, the method comprising:

[0010] The worker node receives the agent client and container replicas deployed by the master node according to the preset deployment strategy. The preset deployment strategy includes one or more of the following: resource control strategy, permission control strategy, and process management strategy.

[0011] The worker node calls the proxy client to obtain the inspection task distributed by the master node from the corresponding container replica;

[0012] The worker node calls the proxy client to perform inspection tasks on the target component and workload, and obtains the inspection results;

[0013] The worker nodes call the proxy client to send the inspection results to the backend server, so that the backend server can generate a target file based on the inspection results sent by the proxy clients of each worker node. The target file includes the security inspection results of the target business cluster.

[0014] Thirdly, embodiments of this application provide a cluster security inspection device applied to a target business cluster comprising multiple nodes, including a master node and worker nodes. The device includes:

[0015] The creation module is used to create a daemon process set in response to the creation process set command sent by the backend server through the cluster management interface;

[0016] The deployment module is used to invoke the daemon set and deploy the agent client and container replica to each worker node according to the preset deployment strategy. The preset deployment strategy includes one or more of the following: resource control strategy, permission control strategy, and process management strategy.

[0017] The task processing module is used to distribute inspection tasks to the container replicas of each worker node, so that the agent client of each worker node can obtain the inspection task from the corresponding container replica, perform the inspection task on the target component and workload, and send the inspection results to the backend server.

[0018] Fourthly, embodiments of this application provide another cluster security inspection device, applied to a target business cluster comprising multiple nodes, including a master node and worker nodes. The device includes:

[0019] The receiving module is used to receive the agent client and container replica deployed by the master node according to the preset deployment strategy. The preset deployment strategy includes one or more of the following: resource control strategy, permission control strategy, and process management strategy.

[0020] The acquisition module is used to call the agent client to obtain the inspection tasks distributed by the master node from the corresponding container replica;

[0021] The inspection module is used to call the proxy client to perform inspection tasks on the target components and workloads and obtain the inspection results;

[0022] The sending module is used to call the proxy client to send the inspection results to the backend server, so that the backend server can generate a target file based on the inspection results sent by the proxy clients of each worker node. The target file includes the security inspection results of the target business cluster.

[0023] Fifthly, embodiments of this application provide a computer device including a processor, a communication interface, and a memory, which are interconnected. The memory stores a computer program, and the processor is used to call the computer program to execute the cluster security check method provided in embodiments of this application.

[0024] Sixthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the cluster security check method provided in embodiments of this application.

[0025] In a seventh aspect, embodiments of this application provide a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the cluster security check method provided in embodiments of this application.

[0026] In this embodiment, the master node responds to the backend server's instruction to create a process set via the cluster management interface, creating a daemon process set. The master node then calls the daemon process set to deploy proxy clients and container replicas to each worker node according to a preset deployment strategy. This preset deployment strategy includes one or more of resource control, access control, and process management strategies. The master node distributes inspection tasks to the container replicas of each worker node, enabling each worker node's proxy client to obtain inspection tasks from its corresponding container replica, perform inspection tasks on the target components and workloads, and send the inspection results to the backend server. By employing this embodiment, the master node deploys proxy clients to worker nodes according to the preset deployment strategy, improving the stability and controllability of the proxy clients, thereby enhancing the effectiveness and stability of cluster security checks and facilitating secure cluster operation in a cloud-native environment. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a framework diagram of a cluster security check provided in an embodiment of this application;

[0029] Figure 2 This is a flowchart illustrating a cluster security inspection method provided in an embodiment of this application;

[0030] Figure 3 This is a schematic diagram of a structure for issuing inspection tasks provided in an embodiment of this application;

[0031] Figure 4 This is a flowchart illustrating another cluster security inspection method provided in an embodiment of this application;

[0032] Figure 5a This is a schematic diagram of a cluster security check process provided in an embodiment of this application;

[0033] Figure 5b This is a flowchart illustrating another cluster security inspection method provided in an embodiment of this application;

[0034] Figure 6 This is a schematic diagram of the interface of a container service cluster node provided in an embodiment of this application;

[0035] Figure 7 This is a schematic diagram of an interface for testing container service workloads provided in an embodiment of this application;

[0036] Figure 8 This is a schematic diagram of the interface after a cluster security check has been performed, provided in an embodiment of this application.

[0037] Figure 9 This is a schematic diagram of an interface for providing cluster security cluster risk details according to an embodiment of this application;

[0038] Figure 10 This is a schematic diagram of a cluster security inspection device provided in an embodiment of this application;

[0039] Figure 11 This is a schematic diagram of another cluster security inspection device provided in an embodiment of this application;

[0040] Figure 12 This is a schematic diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0041] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0042] To facilitate understanding of the embodiments disclosed in this application, some concepts involved in the embodiments of this application will be explained first, including but not limited to the following.

[0043] 1. Cluster

[0044] A cluster is a group of independent computers interconnected by a high-speed network. They form a group and are managed as a single system, providing users with a set of network resources as a whole.

[0045] 2. Master control node

[0046] The master node (or master) is the node responsible for scheduling, updating, scaling up and down of applications in the cluster. A cluster includes one master node.

[0047] 3. Work Nodes

[0048] A worker node (or Node) is a node in a cluster used to execute tasks. A cluster can include multiple worker nodes, which can be virtual machines or physical machines. When a worker node receives a task from the master node, it executes the corresponding task.

[0049] 4. Daemon set

[0050] A daemon set (or daemon process set) is similar to a daemon process, deploying a container replica (or pod) on each matching node. A daemon set ensures that a container replica runs on all (or some) nodes in the cluster. When a new node joins the cluster, a container replica is deployed on the new node. When a node is removed from the cluster, the container replicas deployed on those nodes are also reclaimed.

[0051] To facilitate understanding of the embodiments of this application, the cluster security inspection scheme provided in the embodiments of this application is described below.

[0052] To improve the stability and controllability of proxy clients, thereby facilitating cluster security checks in cloud-native environments, this application provides a cluster security check scheme. Please refer to... Figure 1 , Figure 1 This is a framework diagram of a service management cluster security check provided in an embodiment of this application. Figure 1 As shown, assume that the target business cluster 100 includes a master node 101, worker nodes 102, worker nodes 103, worker nodes 104, and a backend server 105. The following section combines... Figure 1 The general implementation process of the cluster security inspection scheme proposed in this application embodiment is described as follows: First, the master control node 101 in the target business cluster 100 can create a daemon process set in response to the process set creation instruction sent by the backend server 105 through calling the cluster management interface. Then, the master control node 101 calls the daemon process set and deploys the proxy client and container replicas to the worker nodes 102, 103, and 104 according to a preset deployment strategy. The preset deployment strategy includes one or more of resource control strategies, permission control strategies, and process management strategies. Among them, the resource control strategy is used to limit the resource consumption of the proxy client on the worker nodes; the permission control strategy is used to restrict the permissions of the proxy client; and the process management strategy is used to run the proxy client as the first process on the worker nodes. Finally, the master node 101 distributes the inspection tasks to the container replicas corresponding to worker nodes 102, 103, and 104, respectively, so that the proxy clients of worker nodes 102, 103, and 104 can obtain the inspection tasks from their respective container replicas, perform the inspection tasks on the target components and workloads, and send the inspection results to the backend server 105.

[0053] Practice has shown that the cluster security check scheme proposed in this application has the following beneficial effects: ① Resource control strategies can limit the resources occupied by the proxy client to a reasonable range, ensuring that user services are not affected under any circumstances. ② Permission management strategies can weaken environment permissions, which is more in line with the security solutions of cloud-native environments. ③ Process management strategies run the proxy client as the first process on the worker node. When the process exits unexpectedly, the proxy client can be redeployed on the worker node based on the process management strategy, thereby adding a layer of protection for the stability monitoring of the user environment. ④ The master node deploys the proxy client to the worker nodes according to the preset deployment strategy, which can improve the stability and controllability of the proxy client, thereby improving the effectiveness and stability of cluster security checks and facilitating the secure operation of the cluster in a cloud-native environment.

[0054] It should be noted that in the specific implementation, the above scheme allows the terminal to call the interface of the backend service, execute task distribution through the master node, and perform checks and report results on the worker nodes. The master node is a server device, and the worker nodes in the above scheme are also server devices. The terminals mentioned here can include, but are not limited to, smartphones, tablets, laptops, desktop computers, etc.; various clients (applications, apps) can run on the terminals, such as proxy clients, social clients, browser clients, news feed clients, educational clients, etc. The servers mentioned here can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud security, cloud-native security, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, etc.

[0055] Based on the above scheme, this application proposes a cluster security inspection method. Please refer to [link / reference]. Figure 2 , Figure 2 This is a flowchart illustrating a cluster security check method provided in an embodiment of this application. This cluster security check method can be applied to a target business cluster comprising multiple nodes, including a master node and worker nodes. The cluster security check method can be executed by the aforementioned master node, which can be a computer device. Figure 2 As shown, the cluster security check includes the following steps:

[0056] S201. The master node responds to the backend server's command to create a process set by calling the cluster management interface, and creates a daemon process set.

[0057] Optionally, the cluster management interface can be a Kubernetes (or K8S) cluster management interface. Kubernetes is an open-source container orchestration platform for running distributed applications and services at scale. Kubernetes enables rapid and efficient response to user needs, quick and predictable application deployment, rapid application scaling, seamless integration with new application features, resource savings, and optimized hardware resource utilization. When the cluster management interface is a K8S cluster management interface, the master node can respond to the backend server's command to create a process set by calling the K8S cluster management interface, thus creating a Daemonset (i.e., a set of daemons).

[0058] S202, the master node calls the daemon process set and deploys the agent client and container replica to each worker node according to the preset deployment strategy.

[0059] The preset deployment strategy includes one or more of the following: resource control strategy, access control strategy, and process management strategy.

[0060] Taking DaemonSet as an example, when the master node calls DaemonSet to deploy the agent client to each worker node according to the preset deployment strategy, it can call the interface clientset.AppsV1().DaemonSets.Create() to deploy the agent client and container replica to each worker node according to the preset deployment strategy. Since DaemonSet can ensure that each node in the cluster runs a container replica (or pod), the master node can call DaemonSet to deploy the container replica on each worker node.

[0061] In one optional implementation, before the master node calls the daemon set to deploy the agent client and container replica to each worker node according to the preset deployment strategy, it can also receive a resource configuration instruction for the agent client. The resource configuration instruction includes the resource type and the resource quantity threshold corresponding to the resource type. In response to the resource configuration instruction, a resource control policy for the agent client is generated. The resource control policy is used to limit the resource consumption of the agent client on the worker node.

[0062] For example, suppose the master node receives a resource configuration instruction for a proxy client, specifying resource types including Resource Central Processing Unit (ResourceCPU) and Resource Memory. The resource CPU threshold is 250MB (meaning the proxy client can use a maximum of 0.25 CPU cores), and the Resource Memory threshold is 250MB (meaning the proxy client can use a maximum of 250MB of memory). Upon receiving this resource configuration instruction, the master node can respond by generating a resource control policy for the proxy client. This policy limits the proxy client's ResourceCPU to 0.25 cores and its Resource Memory to 250MB, ensuring that user services are not affected under any circumstances. Optionally, the master node can utilize the cgroup feature provided by Kubernetes to generate the resource control policy for the proxy client.

[0063] In one optional implementation, before the master node calls the daemon set to deploy the agent client and container replica to each worker node according to the preset deployment strategy, it can also create a permission set for the agent client, bind the permission set with the corresponding service account, and obtain an authorization file; and call the role-based access control model to generate an access control policy based on the authorization file.

[0064] Optionally, the master node can generate access control policies based on Kubernetes. In this implementation, the service account is an account used by the service to provide identity information for processes in the Pod and external users. Specifically, to enable processes and services in the Pod to access the Kubernetes cluster, the processes and services in the Pod call the Kubernetes cluster's configuration interface API server based on the service account.

[0065] A permission set (or ClusterRole) is a collection of permissions that can authenticate resources or non-resource types across all namespaces and at the cluster level.

[0066] Role-Based Access Control (RBAC): In RBAC, users are no longer directly associated with permissions. Instead, permissions are granted indirectly through the "role" attribute. Users acquire the inherent permissions of the appropriate role by becoming that role, thus decoupling the relationship between users and permissions. Using RBAC can greatly simplify permission management.

[0067] For example, the master node can create a permission set for proxy clients. Suppose this permission set includes three roles, such as role1, role2, and role3. The master node can bind the permissions in this permission set to their corresponding service accounts to obtain authorization files. These authorization files include authorization file 1, authorization file 2, and authorization file 3. Authorization file 1 indicates that role1 can only be used to grant access to resources in namespace1, authorization file 2 indicates that role2 can only be used to grant access to resources in namespace2, and authorization file 3 indicates that role3 can only be used to grant access to resources in namespace3. The master node then invokes the RBAC model to generate an access control policy based on these authorization files. That is, the master node can invoke the RBAC model to allow a user to become role 1, obtain the inherent role1 permission, and thus access resources in namespace1. Similarly, the master node can invoke the RBAC model to allow a user to become role 2, obtain the inherent role2 permission, and thus access resources in namespace2. The master node can also invoke the RBAC model to allow users to become role 3, obtain the inherent permissions of role 3, and thus access resources in namespace 3, etc.

[0068] In one optional implementation, the process management strategy includes having the proxy client run as the first process on each worker node. After the master node calls the daemon set to deploy the proxy client and container replicas to each worker node according to a preset deployment strategy, it can obtain the running status of the proxy client deployed on each worker node. If the proxy client deployed on any worker node fails and stops running, the master node redeploys the proxy client to that worker node based on the process management strategy. Optionally, this implementation can be implemented using Kubernetes (K8S).

[0069] Taking a proxy client deployed on a worker node as an example, the master node can use Kubernetes to run the proxy client as the first process (process ID 1) in the worker node's pod. Subsequently, the master node can obtain the running status of the proxy client. If the process fails and stops running (i.e., the process exits unexpectedly), Kubernetes will detect the process exit through a health check and, based on the process management policy, will restart the proxy client as the first process in the worker node's pod. This improves the stability of the proxy client, thus adding an extra layer of protection for the stability monitoring of the user environment.

[0070] S203. The master node distributes the inspection tasks to the container replicas of each worker node, so that the agent client of each worker node can obtain the inspection tasks from the corresponding container replica, perform the inspection tasks on the target components and workloads, and send the inspection results to the backend server.

[0071] In one optional implementation, the master node may also receive an inspection task configuration instruction sent by the terminal device, the inspection task configuration instruction including asset type and object identifier; and call the task manager to respond to the inspection task configuration instruction and create an inspection task, the inspection task including one or more of task identifier, inspection item and node identifier.

[0072] Optionally, the checks may include, but are not limited to, Apache containerd security vulnerabilities, shared use of host networks, and leakage of version information for the K8S API server component (or Kubernetes API Server).

[0073] Optionally, the master node can receive inspection task configuration instructions (or scan commands) issued by users on terminal devices (or consoles) via a single-node API gateway (API-Gateway). These instructions include the asset type (or backend asset type) and object identifier (or user identifier appid). The backend asset type includes risk types corresponding to hosts (nodes), container replicas, and images; the appid refers to the user identifier of the target business cluster. The master node can then invoke the Task Manager to respond to the inspection task configuration instructions sent by the API-Gateway and create an inspection task. The Subtask Manager within the Task Manager will also query the identifier information (node ​​identifier, or quuid) of each node in the target business cluster based on the appid, and decompose the inspection task into multiple subtasks. Finally, the master node can invoke the Task Scheduler to distribute the inspection task to each node in the target business cluster according to the quuid dimension.

[0074] In one optional implementation, when the master node distributes the inspection task to the container replicas of each worker node, it can first obtain the configuration file of the inspection task and store the configuration file in a distributed storage system. This distributed storage system saves the configuration file and worker nodes in key-value pairs. A configuration resource object is created, and the key-value pairs of the configuration file and worker nodes are obtained from the distributed storage system through the configuration resource object. Based on the key-value pairs, the configuration file is mounted to the corresponding container replica of the worker node. Optionally, this implementation can utilize the Configmap method supported by Kubernetes to distribute the inspection task.

[0075] Please see Figure 3 , Figure 3 This is a schematic diagram of a structure for issuing inspection tasks provided in an embodiment of this application. For example... Figure 3 As shown, when implementing the above method using Kubernetes, the master node first obtains the configuration file for the inspection task and stores it in the distributed key-value store system ETCD. ETCD is a distributed, highly available, consistent key-value store system written in Go, providing reliable distributed key-value storage, configuration sharing, and service discovery functions, and it has disaster recovery capabilities.

[0076] Afterwards, the master node starts ETCD and, based on a strong consistency algorithm for distributed systems (or the Raft protocol), copies the configuration file to all ETCD nodes by replicating the log files; that is, it copies the configuration file based on the Raft protocol. Figure 3 In the system, the data in nodes 1 (ETCD1)(301), 2 (ETCD2)(302), and 3 (ETCD3)(303) is kept consistent, i.e., data synchronization is achieved. Optionally, the master node can also receive etcd snapshot commands from users based on the configuration file at any time to configure the data locally.

[0077] Then, the master node can create configuration resource objects (corresponding to...) Figure 3 The configuration resource object (Configmap)(304) is used to obtain the specific configuration file and key-value pairs of worker nodes from ETCD1(301), ETCD2(302) and ETCD3(303) through Configmap(304).

[0078] Finally, the master node mounts the configuration files to the container replicas of each worker node based on key-value pairs. Specifically, configuration file 1 (Config file1) (305) is mounted to container replica 1 (pod1) (308) corresponding to worker node 1; configuration file 2 (Config file2) (306) is mounted to container replica 2 (pod2) (309) corresponding to worker node 2; and configuration file 3 (Config file3) (307) is mounted to container replica 3 (pod3) (310) corresponding to worker node 3. After mounting is complete, the check task is distributed to the agent client on each worker node for updates.

[0079] In one optional implementation, after receiving the inspection task sent by the proxy client that inspects each worker node, the backend server can generate a target file based on the inspection task. This target file includes the security inspection results of the target business cluster. Optionally, the backend server can also add the target file to a data queue, generate a list of security inspection results based on the target files of at least one business cluster in the data queue, and display the list of security inspection results on a results page. Here, at least one business cluster includes the target business cluster.

[0080] In this embodiment, the master node responds to the backend server's command to create a process set via the cluster management interface, creating a daemon process set. The master node then calls the daemon process set to deploy proxy clients and container replicas to each worker node according to a preset deployment strategy. This preset deployment strategy includes one or more of resource control, access control, and process management strategies. The master node distributes inspection tasks to the container replicas of each worker node, enabling each worker node's proxy client to obtain inspection tasks from its corresponding container replica, perform inspection tasks on the target components and workloads, and send the inspection results to the backend server. By employing this embodiment, the master node deploys proxy clients to worker nodes according to the preset deployment strategy, improving the stability and controllability of the proxy clients, thereby enhancing the effectiveness and stability of cluster security checks and facilitating secure cluster operation in a cloud-native environment.

[0081] It should be noted that the terminal devices mentioned in the embodiments of this application include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, and smart transportation.

[0082] Please see Figure 4 , Figure 4This is a flowchart illustrating another cluster security check method provided in this application embodiment. This cluster security check method can be applied to a target business cluster comprising multiple nodes, including a master node and worker nodes. The cluster security check method can be executed by the aforementioned worker nodes. For ease of description, the following explanation uses a single worker node as an example; this worker node can be a computer device. Figure 4 As shown, the cluster security check includes the following steps:

[0083] S401, The worker node receives the agent client and container copy deployed by the master node according to the preset deployment strategy.

[0084] The preset deployment strategies include one or more of the following: resource control strategy, access control strategy, and process management strategy.

[0085] In one optional implementation, after the worker node receives the proxy client and container replica deployed by the master node according to the preset deployment strategy, it can determine the resource type of the proxy client and the resource quantity threshold corresponding to the resource type according to the resource control strategy; and configure the resource quantity for the resource type of the proxy client, wherein the resource quantity is less than or equal to the resource quantity threshold.

[0086] For example, after the worker node receives the proxy client and container replicas deployed by the master node according to the preset deployment strategy, it can determine the resource types of the proxy client according to the resource control strategy, including ResourceCPU and ResourceMemory. The resource amount threshold of ResourceMemory is 250m (that is, the proxy client occupies a maximum of 0.25 CPU cores) and the resource amount threshold of ResourceMemory is 250Mi (that is, the proxy client occupies a maximum of 250MB of memory). The worker node controls the resource memory usage of the proxy client to be less than or equal to 0.25 cores and to be less than or equal to 250MB.

[0087] In one optional implementation, after receiving the proxy client and container replica deployed by the master node according to a preset deployment strategy, the worker node can control the permissions of the proxy client according to the permission control policy. Optionally, the worker node can invoke a role-based access control model to control the permissions of the proxy client according to the permission control policy.

[0088] In one optional implementation, after the worker node receives the agent client and container copy deployed by the master node according to the preset deployment strategy, it can run the agent client as the first process according to the process management strategy; when the agent client fails and stops running, it sends a redeployment instruction to the master node so that the master node redeploys the agent client.

[0089] S402. The worker node calls the agent client to obtain the inspection task distributed by the master node from the corresponding container replica.

[0090] In one alternative implementation, when a worker node calls the agent client to obtain the inspection task distributed by the master node from the corresponding container replica, it can obtain the configuration file of the inspection task, which is mounted in the container replica by means of a configuration resource object (e.g., a Configmap).

[0091] In one alternative implementation, when a worker node fails to obtain the inspection task distributed by the master node by calling the proxy client, it can call the proxy client to check whether there are any changes in the inspection task in the master node through a fixed path; when it is determined that there are changes in the inspection task, the proxy client is called to obtain the changed inspection task, and the changed inspection task is executed on the target component and the workload.

[0092] It's important to note that the configuration file path for the inspection task is pre-configured, and the configuration file for the inspection task mounted in the container replica is a single configuration file for that inspection task. Different inspection tasks have different configuration files. Understandably, the proxy client will attempt to monitor the configuration file corresponding to the inspection task. If the configuration file does not exist, the proxy client will monitor the inspection tasks in the directory (i.e., Configmap) where the configuration file is located via a pre-configured fixed path. Then, the proxy client can determine if the inspection tasks in that directory have changed. If the inspection task has changed, the proxy client will read and parse the configuration file corresponding to the changed inspection task and execute the changed inspection task on the target component and workload. Optionally, determining whether an inspection task has changed can be done by checking if the inspection task's identifier information (or taskid) is consistent with the previous one. If it's a new taskid, the proxy client will execute the new inspection task corresponding to the new taskid.

[0093] S403. The worker node calls the agent client to perform inspection tasks on the target component and workload, and obtains the inspection results.

[0094] In one optional implementation, the worker node invokes the proxy client to perform inspection tasks on the target component and the workload, and obtains inspection results, including: the worker node invokes the proxy client to obtain a list of inspection item identifiers and a list of node identifiers for performing the inspection; if the list of node identifiers for performing the inspection includes the node identifier of the worker node, then the worker node invokes the proxy client to load the dependency resources associated with the inspection task, and performs item-by-item inspections on the target component and the workload based on the list of inspection item identifiers.

[0095] Optionally, when the list (or array) of check item identifiers is empty, the agent client can check all check items. When the list of node identifiers to perform the check is empty, it can be determined that all worker nodes perform the check task.

[0096] Optionally, target components may include, but are not limited to, runC, Containerd, Docker, Kubelet, kube-api-server, kube-controller-manager, kube-scheduler, and etcd; workloads (or workload resources) include, but are not limited to, all running Pods and their associated resources.

[0097] runC is a lightweight command-line tool used to create and run containers according to the Open Container Initiative (OCI) standard. Newer versions of Docker and Containerd use runC to manage containers.

[0098] Containerd is the most basic runtime component of Kubernetes (K8S), and it is also the runtime component with the best support in K8S. It is also the runtime component of the newer versions of Docker.

[0099] Docker is the most fundamental runtime component of Kubernetes (K8S) and the best-supported runtime component in K8S. Docker uses cgroups and namespaces provided by the Linux system to achieve isolation between components, which is a process-level isolation.

[0100] Kubelet is a process that runs on child nodes in the Kubernetes system. Its main functions include monitoring and reporting child node resources and monitoring the operation of containers.

[0101] The kube-api-server is used to validate and configure data for API objects, including Pods, Services, and so on. The API Server provides REST operations and shared state from the front end to the cluster, through which all other components can interact.

[0102] The kube-controller-manager, composed of a series of controllers, serves as the central management and control unit within the cluster. This component manages the cluster's nodes, pods, endpoints, namespaces, service accounts, and resource quotas. When a node unexpectedly fails, this component promptly detects and executes automated recovery procedures to ensure the cluster remains in its expected working state.

[0103] kube-scheduler is a key module in Kubernetes, acting as a steward and following a set of mechanisms to provide scheduling services for Pods, such as fair scheduling based on resources, scheduling Pods to a specified node, or scheduling Pods that communicate frequently to the same node.

[0104] It should be noted that for a new inspection task, the program will first load the dependent resources related to the inspection task, and then perform the inspection item by item.

[0105] S404. The worker node calls the proxy client to send the inspection results to the backend server, so that the backend server generates a target file based on the inspection results sent by the proxy clients of each worker node. The target file includes the security inspection results of the target business cluster.

[0106] In one optional implementation, each check in the check item identifier list executed by the proxy client produces a result, which includes the check item ID, result status, check information, etc. For the target component, the result status includes check passed, check failed, target not found, and check error, and the check information is evidence information from the check process. For the workload, the result status includes check passed, check failed, and check error, and the check information is the corresponding workload resource. If the resource is generated by upper-layer resource scheduling, it will recursively retrieve the uppermost resource information. For example, CronJob schedules Job resources, and Job schedules Pods. When the checked resource is a Pod generated by CronJob, the upper-layer CronJob information will be recursively retrieved and reported.

[0107] The Job is responsible for processing tasks, executing them only once, and ensuring that one or more Pods in a batch processing task successfully complete. CronJob adds time scheduling to the Job, i.e., scheduled tasks, which means running specified tasks at specified time periods.

[0108] Optionally, the backend server can add the target file to a data queue, generate a security check result list based on the target files of at least one business cluster in the data queue, and display the security check result list on the results page. At least one business cluster includes the target business cluster.

[0109] Since the target business cluster may include multiple worker nodes, each worker node sends its inspection results to the backend server. The backend server then generates a target file (or result file) based on the inspection results from each worker node. This target file contains the security inspection results of the target business cluster. Optionally, the backend server may also report the target file to a messaging system (e.g., Kafka) for processing and storage by backend programs.

[0110] In this embodiment, worker nodes receive proxy clients and container replicas deployed by the master node according to a preset deployment strategy. This preset deployment strategy includes one or more of resource control, access control, and process management strategies. Worker nodes invoke the proxy client to retrieve inspection tasks distributed by the master node from the corresponding container replicas. Worker nodes then invoke the proxy client to perform inspection tasks on target components and workloads, obtaining inspection results. Finally, worker nodes invoke the proxy client to send the inspection results to a backend server, enabling the backend server to generate a target file based on the inspection results sent by the proxy clients of each worker node. The target file includes the security inspection results of the target business cluster. By employing this embodiment, worker nodes utilize proxy clients deployed according to a preset deployment strategy, which improves the stability and controllability of the proxy clients and fully leverages the orchestration capabilities provided by cloud-native systems. This enhances the effectiveness and stability of cluster security inspections, making it more suitable for cluster security inspections in cloud-native scenarios.

[0111] It should be noted that when the embodiments of this application are applied to specific products or technologies, the inspection tasks, inspection results, target documents, etc. involved in the embodiments of this application are obtained only after obtaining the user's permission or consent; and the collection, use and processing of inspection tasks, inspection results, target documents, etc. must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0112] Please see Figure 5a , Figure 5a This is a schematic diagram illustrating a cluster security check process provided in an embodiment of this application. The following is in conjunction with… Figure 5a The cluster security inspection method provided in this application is described.

[0113] First, the master node can deploy the agent client and container replica pod to each worker node according to the aforementioned preset deployment strategy.

[0114] Secondly, users can issue inspection task configuration commands (or scan commands) to the target business cluster in Cloud API 3.0 (502) through the authorized web console Webconsole (501). These inspection task configuration commands include the background asset type (i.e., Figure 5a The asset type in the target service cluster and the user identification information to which the target service cluster belongs (i.e., Figure 5a When the single-node API Gateway (503) receives this instruction, it can send the instruction to the Task Manager (504) in the master node for processing, that is, pass the background asset type and appid parameters to the Task Manager (504) to create an inspection task. Then, the master node can call the Task Scheduler (505) to distribute the inspection task to the agent client of each worker node for processing through the API server component (Kubernetes Engine APIServer, KE API Server) (509) in the cloud container service based on the Kubernetes Engine Software Development Kit (KESDK) (506). When the cloud container service is not found (No KE) (507), the master node can distribute the inspection task to the agent client of each worker node for processing through the K8S API server component (K8S API Server) (508).

[0115] During the process of issuing inspection tasks, the master node can first obtain the configuration file of the inspection task and store it in ETCD. Then, the master node can create a configuration resource object Configmap (510) and obtain the key-value pairs of the configuration file and worker nodes from each node in ETCD through Configmap (510). Finally, based on the key-value pairs, the configuration file is mounted to the corresponding worker node's container replica pod (511), and after the configuration file corresponding to the inspection task is mounted, the inspection task is distributed and updated to the agent client of each worker node. Among them, the master node can pull the corresponding code from the Container Registry (CR) (512) so that the configuration file can be mounted to each pod.

[0116] Then, worker nodes can invoke the proxy client to monitor the configuration file of the inspection task. If the configuration file does not exist, worker nodes can invoke the proxy client to check whether there are any changes to the inspection task in the master node through a fixed path. When it is determined that the inspection task has changed, worker nodes can invoke the proxy client to obtain the changed inspection task and execute the changed inspection task on the target component and workload. When executing the inspection task, worker nodes can invoke the proxy client to obtain the list of inspection item identifiers and the list of node identifiers for execution. If the list of node identifiers for execution includes the node identifier of the worker node, then the proxy client is invoked to load the dependency resources associated with the inspection task and perform item-by-item checks on the target component and workload based on the list of inspection item identifiers.

[0117] Finally, after completing the inspection task, the agent client can report the inspection results to the distributed publish-subscribe messaging system Kafka. During this process, worker nodes can call the agent client to send the inspection result file to the backend server. Since each inspection item executed by the agent client produces a result, when all inspection items are completed, the backend server will receive all inspection results, reorder and organize them, and write them to the result file result_file(513) (i.e., the aforementioned target file generated based on the inspection results). Simultaneously, the backend server will scan the reported result file (i.e.,... Figure 5a The scan results are reported in the database, and the result file is reported to Kafka (515) through a client Kafka-Producer (514) that sends data to Kafka, waiting for the backend program to consume and process it and put it into the database. Figure 5a In the baseline detection cloud container security service product css_baseline(516), on the one hand, the ResultAnalyze(517) module can analyze the inspection results and send the analysis results to the Subtask-Manager(518) of the master node, so that the Subtask-Manager can send the analysis results to the database DataBase(DB)(519) for subsequent processing by the task manager. On the other hand, the data consumption results can be reported to Kafka(515).

[0118] Please see Figure 5b , Figure 5b This is a flowchart illustrating another cluster security inspection method provided in this application embodiment. This method can be applied to a target business cluster comprising multiple nodes, including a master node and worker nodes. Figure 5b As shown, the cluster security check method may include the following steps:

[0119] S501: The master node responds to the backend server's command to create a process set by calling the cluster management interface, and creates a daemon process set.

[0120] S502, the master node calls the daemon process set and deploys the agent client and container replica to each worker node according to the preset deployment strategy.

[0121] In an optional implementation, the specific processes of steps S501 and S502 can be found in the descriptions of S201 and S202 above, and will not be repeated here.

[0122] S503: The terminal device sends the check task configuration command to the master control node through the gateway.

[0123] A gateway, also known as an internetwork connector or protocol converter, operates at the transport layer to achieve network interconnection and is one of the most complex network interconnection devices. Optionally, the gateway may be, for example, a... Figure 5a The single-node API gateway in the middle (i.e. Figure 5a (503 in the middle).

[0124] In one alternative implementation, the terminal device may respond to user requests to a network console (e.g., a...). Figure 5a The login command (501) input in the system generates a target page, which is used to configure and manage the target business cluster. Through the target page, the system receives the inspection task configuration command input for the target business cluster and sends the inspection task configuration command to the master control node through the gateway.

[0125] Optionally, the login command entered by the user to the network console can be that the user enters a username and password on the login interface of the network console and enters a command to confirm the login; or the user can scan a QR code on the login interface through a third-party application that is bound to the network console.

[0126] Optionally, the inspection task configuration instructions include the background asset type (i.e. Figure 5a The asset type in the target service cluster and the user identification information (i.e., the asset type in the target service cluster) Figure 5a (appid in the file). Among them, the backend asset types can include the risk types corresponding to hosts (i.e., nodes), container replicas, images, etc.

[0127] Optionally, the inspection task configuration instruction can be a single instruction corresponding to the target service cluster, or each worker node in the target service cluster can have a different inspection task configuration instruction. When the terminal device receives different inspection task configuration instructions for each worker node in the target service cluster, it can send the inspection task configuration instruction corresponding to each worker node to the master control node through the gateway.

[0128] S504: The master node calls the task manager and responds to the check task configuration command to create a check task.

[0129] S505, the master node calls the task scheduler to distribute the inspection tasks to the container replicas of each worker node.

[0130] In an optional implementation, the specific process of steps S504 and S505 can be found in the relevant description in step S203 above, and will not be repeated here.

[0131] In another optional implementation, if the terminal device sends the inspection task configuration instruction for each worker node to the master control node through the gateway, the master control node can invoke the task manager to respond to the inspection task configuration instruction for each worker node and create the inspection task corresponding to each worker node; it can then invoke the task scheduler to distribute the inspection task corresponding to each worker node to the container replica of the corresponding worker node. It is understood that in this implementation, the task scheduler can directly distribute the inspection task corresponding to each worker node to the container replica of the corresponding worker node, without needing to perform actions such as... Figure 3 The process of issuing inspection tasks is shown.

[0132] Optionally, the master node can invoke the task scheduler (e.g., ...). Figure 5a 505 in the middle), software development kits based on cloud container services (e.g., are Figure 5a The 506 error will trigger the inspection task through the API server component in the cloud container service (e.g., [company name]). Figure 5a The 509 error message is sent to the agent client of each worker node for processing. If no cloud container service is found, the master node can use the Kubernetes API server component (e.g., [example component]). Figure 5a In step 508, the inspection task is distributed to the container replica of each worker node for processing.

[0133] S506. The worker node calls the agent client to obtain the inspection task distributed by the master node from the corresponding container replica, and performs the inspection task on the target component and workload to obtain the inspection result.

[0134] Taking a working node as an example, the specific process of step S506 can be found in the description of steps S402 and S403 above, and will not be repeated here.

[0135] S507, The worker node calls the agent client to send the inspection results to the backend server.

[0136] In an optional implementation, the specific process of step S507 can be found in the relevant description in step S404 above, and will not be repeated here.

[0137] S508: The backend server generates a target file based on the inspection results sent by the proxy clients of each working node. This target file includes the security inspection results of the target business cluster.

[0138] The target file can also be called the result file (i.e. Figure 5a (513 in the middle).

[0139] Since the target business cluster may include multiple worker nodes, the backend server will receive the inspection results sent by the proxy client of each worker node, and reorder and organize all the inspection results to generate the target file.

[0140] S509. The backend server reports the target file to the message system so that the backend program can consume, process, and store the target file in the database.

[0141] Optionally, the backend server can send data via a client (e.g., a client that can send data). Figure 5a 514 in the middle) will target the file (for example, it could be 514) Figure 5a 513) is reported to the messaging system (e.g., it could be...) Figure 5a In step 515), the process awaits the backend program to consume and process the data before storing it in the database.

[0142] Optionally, the backend server can also provide results analysis (e.g., it could be...) Figure 5a (517) Analyzes the inspection results and sends the analysis results to the sub-task manager of the master node (e.g., it could be...). Figure 5a In section 518), the subtask manager is instructed to send the analysis results to the database (e.g., it could be...). Figure 5a In section 519), it is used for subsequent calls and processing by Task Manager.

[0143] Optionally, the backend server can add the target file to a data queue, generate a security check result list based on the target files of at least one business cluster in the data queue, and display the security check result list on the results page of the terminal device. At least one business cluster includes the target business cluster.

[0144] As can be seen, by adopting the embodiments of this application, the master node deploys the proxy client to the worker nodes according to the preset deployment strategy, which can improve the stability and controllability of the proxy client, thereby improving the effectiveness and stability of cluster security checks, and is conducive to the secure operation of the cluster in a cloud-native environment.

[0145] According to the embodiments provided in this application, Figure 2 and Figure 4The cluster security check method shown can be used to check the security of a Kubernetes (K8S) cluster. Optionally, a K8S cluster is typically built by operations personnel deploying K8S-related components on a server cluster themselves, or by directly using managed services or container services provided by a cloud platform. The following description uses a cluster environment created on a cloud container service as an example.

[0146] Please see Figure 6 , Figure 6 This is a schematic diagram of the interface of a container service cluster node provided in an embodiment of this application. For example... Figure 6 As shown, this is a new cluster ke-test created by the user in the cloud container service, which includes two worker nodes, ke_cls-123_worker2 and ke_cls-123_worker1. The Kubernetes master control node is hosted by the container service and does not provide workload capabilities.

[0147] Please see Figure 7 , Figure 7 This is a schematic diagram of an interface for testing container service workloads provided in an embodiment of this application. Figure 7 As shown, this is the busybox workload created by the user in the ke-test cluster for testing.

[0148] Afterwards, the cluster can be seen under the Cluster Security option in the Container Security service. After installing the cluster inspection component, a Kubernetes security check can be performed on the cluster. Following the check, specific risk items and their solutions for the cluster can be obtained. Figure 8 As shown, Figure 8 The dashed box in the image represents the display window after the cluster security check is performed following the installation of the check component. Users can click to view details and access the cluster's risk profile. Figure 9 The image shown is the risk details interface for the ke_test cluster. This interface displays a detailed list of risk items for the ke-test cluster, listing all involved vulnerabilities and their basic information, such as name, description, inspection target, and severity level. After a vulnerability has been patched by operations personnel or administrators, the master node can control the agent client to perform a re-inspection of the cluster to verify whether the vulnerability has been correctly patched.

[0149] Based on the description of the relevant embodiments of the above-mentioned cluster security inspection method, this application also proposes a cluster security inspection device, which can be a computer program (including program code) running on the master node. This cluster security inspection device can execute... Figure 2 The cluster security check method shown; please refer to Figure 10 , Figure 10This application provides a cluster security inspection device that can operate the following modules:

[0150] Create module 1001 to create a daemon process set in response to the backend server's command to create a process set by calling the cluster management interface;

[0151] Deployment module 1002 is used to call the daemon process set and deploy the agent client and container replica to each worker node according to the preset deployment strategy. The preset deployment strategy includes one or more of the following: resource control strategy, permission control strategy, and process management strategy.

[0152] The task processing module 1003 is used to distribute inspection tasks to the container replicas of each worker node, so that the agent client of each worker node can obtain inspection tasks from the corresponding container replica, perform inspection tasks on the target components and workloads, and send the inspection results to the backend server.

[0153] In an optional implementation, before invoking the daemon set and deploying the agent client and container replica to each worker node according to a preset deployment strategy, the deployment module 1002 is further configured to:

[0154] Receive resource configuration instructions for the proxy client. The resource configuration instructions include the resource type and the corresponding resource quantity threshold.

[0155] The resource control policy for the proxy client is generated in response to the resource configuration command. The resource control policy is used to limit the resource consumption of the proxy client on the worker node.

[0156] In an optional implementation, before invoking the daemon set and deploying the agent client and container replica to each worker node according to a preset deployment strategy, the deployment module 1002 is further configured to:

[0157] Create a permission set for the proxy client, bind the permission set to the corresponding service account, and obtain the authorization file;

[0158] Invoke the role-based access control model and generate access control policies based on the authorization file.

[0159] In one optional implementation, the process management strategy includes having the agent client run as the first process on the worker node. After the deployment module 1002 calls the daemon set and deploys the agent client and container replicas to each worker node according to a preset deployment strategy, it is further configured to:

[0160] Obtain the running status of the agent client deployed on each worker node;

[0161] If the agent client deployed on any worker node fails and stops running, the agent client will be redeployed on any worker node based on the process management policy.

[0162] In one optional implementation, the creation module 1001 is further configured to receive an inspection task configuration instruction sent by the terminal device, the inspection task configuration instruction including asset type and object identifier.

[0163] The task manager is invoked to respond to the inspection task configuration command and create an inspection task. The inspection task includes one or more of the following: task identifier, inspection items, and node identifier.

[0164] In one alternative implementation, the task processing module 1003, when distributing inspection tasks to container replicas of each worker node, specifically performs the following:

[0165] The configuration file for the inspection task is obtained and stored in a distributed storage system. The distributed storage system saves the configuration file and worker nodes in the form of key-value pairs.

[0166] Create a configuration resource object and retrieve the key-value pairs of the configuration file and worker nodes from the distributed storage system through the configuration resource object;

[0167] The configuration file is mounted to the container replica of the corresponding worker node based on key-value pairs.

[0168] According to one embodiment of this application, Figure 2 Each step involved in the method shown can be derived from... Figure 10 The various modules within the cluster security management device shown are used to execute this. For example, Figure 2 Step S201 shown can be performed by Figure 6 The creation module 1001 shown is executed, and step S202 can be performed by... Figure 10 The deployment module 1002 shown is executed, and step S203 can be performed by... Figure 10 The task processing module 1003 shown in the figure executes, etc.

[0169] According to one embodiment of this application, Figure 10The modules in the cluster security inspection device shown can be individually or entirely merged into one or more other modules, or some of the modules can be further divided into multiple functionally smaller modules. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above modules are based on logical function division. In practical applications, the function of one module can be implemented by multiple modules, or the function of multiple modules can be implemented by one module. In the embodiments of this application, the cluster security inspection device also includes other modules. In practical applications, these functions can also be implemented with the assistance of other modules, and can be implemented collaboratively by multiple modules.

[0170] Based on the description of the relevant embodiments of the above-described cluster security inspection method, this application also proposes another cluster security inspection device, which can be a computer program (including program code) running on a worker node. This cluster security inspection device can execute... Figure 4 The cluster security check method shown; please refer to Figure 11 , Figure 11 This application provides another cluster security inspection device, which can run the following modules:

[0171] The receiving module 1101 is used to receive the agent client and container replica deployed by the master node according to the preset deployment strategy. The preset deployment strategy includes one or more of the following: resource control strategy, permission control strategy, and process management strategy.

[0172] Module 1102 is used to call the agent client to obtain the inspection tasks distributed by the master node from the corresponding container replica;

[0173] Inspection module 1103 is used to call the proxy client to perform inspection tasks on the target components and workloads and obtain inspection results;

[0174] The sending module 1104 is used to call the proxy client to send the inspection results to the backend server, so that the backend server can generate a target file based on the inspection results sent by the proxy client of each working node. The target file includes the security inspection results of the target business cluster.

[0175] In an optional implementation, the inspection module 1103 is further configured to:

[0176] When a worker node calls the proxy client but does not obtain the inspection task distributed by the master node, it calls the proxy client to check whether there are any changes in the inspection task in the master node through a fixed path;

[0177] When it is determined that the inspection task has changed, the agent client is invoked to obtain the changed inspection task, and the changed inspection task is executed on the target component and the workload.

[0178] In an optional implementation, when the inspection module 1103 calls the proxy client to perform inspection tasks on the target component and workload and obtain inspection results, it is specifically used for:

[0179] Call the proxy client to obtain the list of check item identifiers and the list of node identifiers for which checks are performed;

[0180] If the list of node identifiers to be checked includes the node identifiers of worker nodes, then the proxy client is invoked to load the dependency resources associated with the check task, and the target components and workloads are checked item by item based on the list of check item identifiers.

[0181] According to one embodiment of this application, Figure 4 Each step involved in the method shown can be derived from... Figure 11 The various modules within the cluster security management device shown are used to execute this. For example, Figure 4 Step S401 shown can be performed by Figure 11 The receiving module 1101 shown is executed, and step S402 can be performed by... Figure 11 The acquisition module 1102 shown is executed, and step S403 can be performed by... Figure 11 The inspection module 1103 shown is executed, and step S404 can be performed by... Figure 11 The sending module 1104 shown in the figure performs, etc.

[0182] According to one embodiment of this application, Figure 11 The modules in the cluster security inspection device shown can be individually or entirely merged into one or more other modules, or some of the modules can be further divided into multiple functionally smaller modules. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above modules are based on logical function division. In practical applications, the function of one module can be implemented by multiple modules, or the function of multiple modules can be implemented by one module. In the embodiments of this application, the cluster security inspection device also includes other modules. In practical applications, these functions can also be implemented with the assistance of other modules, and can be implemented collaboratively by multiple modules.

[0183] According to one embodiment of this application, a general-purpose computer device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), can perform operations such as... Figure 2The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 10 The cluster security inspection device shown herein, and the cluster security inspection method for implementing the embodiments of this application. Alternatively, running and executing as follows Figure 4 The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 11 The diagram illustrates a cluster security inspection apparatus, and another cluster security inspection method for implementing embodiments of this application. A computer program may be recorded on, for example, a computer-readable storage medium, loaded onto the aforementioned computing device via the computer-readable storage medium, and run therein.

[0184] It is understood that the specific implementation of each module in the cluster security inspection device provided in this application embodiment and the beneficial effects that can be achieved can be referred to the description of the corresponding cluster security inspection method embodiment above, and will not be repeated here.

[0185] Based on the description of the above method and apparatus embodiments, this application also provides a computer device. Please refer to... Figure 12 The computer device includes at least a processor 1201, a memory 1202, and a communication interface 1203. The processor 1201, memory 1202, and communication interface 1203 can be connected via a bus 1204 or other means. This embodiment of the application takes the connection via a bus 1204 as an example.

[0186] The processor 1201 (or CPU (Central Processing Unit)) is the computing and control core of the computer device. It can parse various instructions and process various data within the computer device. For example, the CPU can parse power-on / off commands sent by the user and control the computer device to perform power-on / off operations; it can also transmit various interactive data between internal structures of the computer device. The communication interface 1203 may optionally include standard wired interfaces or wireless interfaces (such as Wi-Fi, mobile communication interfaces, etc.), controlled by the processor 1201 for sending and receiving data. The memory 1202 is the storage device in the computer device, used to store computer programs and data. It is understood that the memory 1202 here can include the computer device's built-in memory, or it can include extended memory supported by the computer device. The memory 1202 provides storage space for the computer device's operating system, which may include, but is not limited to, Windows, Linux, Android, iOS, etc., and this application does not limit this. In an optional implementation, the processor 1201 of this application embodiment can perform the following operations by running a computer program stored in the memory 1202:

[0187] In response to the backend server's command to create a process set by calling the cluster management interface, a daemon process set is created;

[0188] Invoke the daemon set and deploy the agent client and container replica to each worker node according to the preset deployment strategy. The preset deployment strategy includes one or more of the following: resource control strategy, permission control strategy, and process management strategy.

[0189] The inspection task is distributed to the container replica of each worker node, so that the agent client of each worker node obtains the inspection task from the corresponding container replica, performs the inspection task on the target component and workload, and sends the inspection result to the backend server.

[0190] In one alternative implementation, before the processor 1201 invokes the daemon set and deploys the agent client and container replica to each worker node according to a preset deployment strategy, it is further configured to:

[0191] Receive resource configuration instructions for the proxy client. The resource configuration instructions include the resource type and the corresponding resource quantity threshold.

[0192] The resource control policy for the proxy client is generated in response to the resource configuration command. The resource control policy is used to limit the resource consumption of the proxy client on the worker node.

[0193] In an optional implementation, before invoking the daemon set and deploying the agent client and container replica to each worker node according to a preset deployment strategy, the processor 1201 is further configured to:

[0194] Create a permission set for the proxy client, bind the permission set to the corresponding service account, and obtain the authorization file;

[0195] Invoke the role-based access control model and generate access control policies based on the authorization file.

[0196] In one optional implementation, the process management strategy includes having the agent client run as the first process on the worker node, and after the processor 1201 calls the daemon set and deploys the agent client and container replicas to each worker node according to a preset deployment strategy, it is further configured to:

[0197] Obtain the running status of the agent client deployed on each worker node;

[0198] If the agent client deployed on any worker node fails and stops running, the agent client will be redeployed on any worker node based on the process management policy.

[0199] In an alternative implementation, the processor 1201 is further configured to:

[0200] The target file is added to the data queue so that the terminal device generates a list of security check results based on the target file of at least one business cluster in the data queue and displays the list of security check results on the results page. At least one business cluster includes the target business cluster.

[0201] In an alternative implementation, the processor 1201 is further configured to:

[0202] Receive inspection task configuration instructions sent by the terminal device. The inspection task configuration instructions include asset type and object identifier.

[0203] The task manager is invoked to respond to the inspection task configuration command and create an inspection task. The inspection task includes one or more of the following: task identifier, inspection items, and node identifier.

[0204] In one alternative implementation, the processor 1201, when distributing inspection tasks to container replicas of each worker node, specifically performs the following:

[0205] The configuration file for the inspection task is obtained and stored in a distributed storage system. The distributed storage system saves the configuration file and worker nodes in the form of key-value pairs.

[0206] Create a configuration resource object and retrieve the key-value pairs of the configuration file and worker nodes from the distributed storage system through the configuration resource object;

[0207] The configuration file is mounted to the container replica of the corresponding worker node based on key-value pairs.

[0208] In specific implementations, the processor 1201, memory 1202, and communication interface 1203 described in this application embodiment can execute the implementation of the master node described in the cluster security inspection method provided in this application embodiment, or the implementation described in the cluster security inspection device provided in this application embodiment, which will not be repeated here.

[0209] Based on another embodiment provided in this application, the processor 1201 of this application embodiment can also perform the following operations by running a computer program stored in the memory 1202:

[0210] Receive the agent client and container replicas deployed by the master node according to a preset deployment strategy, which includes one or more of resource control strategy, permission control strategy, and process management strategy;

[0211] The proxy client is invoked to obtain the inspection tasks distributed by the master node from the corresponding container replica;

[0212] The proxy client is invoked to perform inspection tasks on the target components and workloads, and the inspection results are obtained.

[0213] The proxy client is invoked to send the inspection results to the backend server, so that the backend server can generate a target file based on the inspection results sent by the proxy clients of each worker node. The target file includes the security inspection results of the target business cluster.

[0214] In an alternative implementation, the processor 1201 is further configured to:

[0215] When a worker node calls the proxy client but does not obtain the inspection task distributed by the master node, it calls the proxy client to check whether there are any changes in the inspection task in the master node through a fixed path;

[0216] When it is determined that the inspection task has changed, the agent client is invoked to obtain the changed inspection task, and the changed inspection task is executed on the target component and the workload.

[0217] In an optional implementation, when the processor 1201 is used for the worker node to call the agent client to perform inspection tasks on the target components and workload, and obtain inspection results, it is specifically used for:

[0218] Call the proxy client to obtain the list of check item identifiers and the list of node identifiers for which checks are performed;

[0219] If the list of node identifiers to be checked includes the node identifiers of worker nodes, then the proxy client is invoked to load the dependency resources associated with the check task, and the target components and workloads are checked item by item based on the list of check item identifiers.

[0220] In specific implementations, the processor 1201, memory 1202, and communication interface 1203 described in this application embodiment can execute the implementation of the working node described in another cluster security inspection method provided in this application embodiment, or the implementation of the cluster security inspection device provided in this application embodiment, which will not be repeated here.

[0221] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer device to execute the cluster security check method described in any of the possible implementations above. Specific implementation details are provided above and will not be repeated here.

[0222] This application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform any of the possible implementations of the cluster security check method described above. Specific implementations can be found in the foregoing description and will not be repeated here.

[0223] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0224] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0225] The above-disclosed embodiments are only some of the embodiments of this application, and should not be construed as limiting the scope of this application. Therefore, any equivalent changes made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A cluster security inspection method, characterized in that, Applied to a target business cluster comprising multiple nodes, including a master node and worker nodes, the method includes: The master control node responds to the backend server's command to create a process set by calling the cluster management interface, and creates a daemon process set; The master node invokes the daemon process set and deploys the agent client and container replica to each worker node according to a preset deployment strategy. The preset deployment strategy includes a process management strategy; or, the preset deployment strategy includes a process management strategy and further includes one or two of a resource control strategy and an access control strategy; wherein, the process management strategy includes the agent client running as the first process in the worker node. The master control node obtains the running status of the proxy clients deployed on each worker node; When the agent client deployed on any worker node fails and stops running, the master node redeploys the agent client on any worker node based on the process management policy; The master node distributes the inspection task to the container replica of each worker node, so that the agent client of each worker node can obtain the inspection task from the corresponding container replica, perform the inspection task on the target component and the workload, and send the inspection result to the backend server.

2. The method according to claim 1, characterized in that, Before the master node invokes the daemon set and deploys the agent client and container replica to each worker node according to the preset deployment strategy, the method further includes: The master control node receives resource configuration instructions for the proxy client, the resource configuration instructions including resource type and resource quantity threshold corresponding to the resource type; The master node responds to the resource configuration command to generate a resource control policy for the proxy client, and the resource control policy is used to limit the resource consumption of the proxy client on the working node.

3. The method according to claim 1, characterized in that, Before the master node invokes the daemon set and deploys the agent client and container replica to each worker node according to the preset deployment strategy, the method further includes: The master node creates a permission set for the proxy client and binds the permission set with the corresponding service account to obtain an authorization file; The master node invokes a role-based access control model to generate an access control policy based on the authorization file.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The master control node receives the inspection task configuration instruction sent by the terminal device, and the inspection task configuration instruction includes the asset type and object identifier; The master node invokes the task manager to respond to the inspection task configuration command and creates an inspection task. The inspection task includes one or more of the following: task identifier, inspection item, and node identifier.

5. The method according to any one of claims 1 to 3, characterized in that, The master node will inspect the container replicas distributed to each worker node, including: The master node obtains the configuration file of the inspection task and stores the configuration file in the distributed storage system. The distributed storage system saves the configuration file and the working node in the form of key-value pairs. The master node creates a configuration resource object and obtains the key-value pairs of the configuration file and worker nodes from the distributed storage system through the configuration resource object; The master node mounts the configuration file to the container replica of the corresponding worker node based on the key-value pair.

6. A cluster security inspection method, characterized in that, Applied to a target business cluster comprising multiple nodes, including a master node and worker nodes, the method includes: The worker node receives the proxy client and container replica deployed by the master node according to a preset deployment strategy. The preset deployment strategy includes a process management strategy; or, the preset deployment strategy includes a process management strategy, and the preset deployment strategy also includes one or two of a resource control strategy and an access control strategy; wherein, the process management strategy includes the proxy client running as the first process in the worker node. The working node runs the agent client as the first process according to the process management strategy; When the proxy client fails and stops running, the worker node sends a redeployment command to the master node, so that the master node redeploys the proxy client. The worker node calls the agent client to obtain the inspection task distributed by the master node from the corresponding container replica; The worker node invokes the proxy client to perform the inspection task on the target component and the workload, and obtains the inspection results; The worker node invokes the proxy client to send the inspection results to the backend server, so that the backend server generates a target file based on the inspection results sent by the proxy clients of each worker node. The target file includes the security inspection results of the target business cluster.

7. The method according to claim 6, characterized in that, The method further includes: When the worker node calls the proxy client but fails to obtain the inspection task distributed by the master node, the worker node calls the proxy client to check whether there are any changes in the inspection task in the master node through a fixed path; When it is determined that the inspection task has changed, the worker node calls the agent client to obtain the changed inspection task and executes the changed inspection task on the target component and the workload.

8. The method according to claim 6 or 7, characterized in that, The worker node invokes the proxy client to perform the inspection task on the target component and workload, and obtains the inspection results, including: The worker node calls the agent client to obtain the list of check item identifiers and the list of node identifiers for performing the checks; If the list of node identifiers for performing the check includes the node identifier of the worker node, then the worker node calls the proxy client to load the dependent resources associated with the check task, and performs item-by-item checks on the target component and the workload based on the list of check item identifiers.

9. A cluster security inspection device, characterized in that, Applied to a target business cluster comprising multiple nodes, including a master node and worker nodes, the device includes: The creation module is used to create a daemon process set in response to the creation process set command sent by the backend server through the cluster management interface; The deployment module is used to invoke the daemon set and deploy the agent client and container replica to each worker node according to a preset deployment strategy. The preset deployment strategy includes a process management strategy; or, the preset deployment strategy includes a process management strategy and further includes one or two of a resource control strategy and an access control strategy; wherein, the process management strategy includes the agent client running as the first process in the worker node. The deployment module is also used to obtain the running status of the agent client deployed on each working node; when the agent client deployed on any working node fails and stops running, the agent client is redeployed on any working node based on the process management strategy. The task processing module is used to distribute inspection tasks to the container replicas of each worker node, so that the agent client of each worker node can obtain the inspection task from the corresponding container replica, execute the inspection task on the target component and the workload, and send the inspection result to the backend server.

10. A cluster security inspection device, characterized in that, Applied to a target business cluster comprising multiple nodes, including a master node and worker nodes, the device includes: A receiving module is configured to receive the proxy client and container replica deployed by the master node according to a preset deployment strategy, wherein the preset deployment strategy includes a process management strategy; or, the preset deployment strategy includes a process management strategy, and the preset deployment strategy further includes one or two of a resource control strategy and an access control strategy; wherein, the process management strategy includes the proxy client running as the first process in the worker node; the proxy client is run as the first process according to the process management strategy. The sending module is used to send a redeployment command to the master control node when the proxy client fails and stops running, so that the master control node redeploys the proxy client. The acquisition module is used to call the agent client to obtain the inspection task distributed by the master node from the corresponding container replica; The inspection module is used to call the proxy client to perform the inspection task on the target component and the workload, and obtain the inspection results; The sending module is further configured to call the proxy client to send the inspection results to the backend server, so that the backend server generates a target file based on the inspection results sent by the proxy clients of each working node, and the target file includes the security inspection results of the target business cluster.

11. A computer device, characterized in that, The computer device includes a memory, a communication interface, and a processor, wherein the memory, the communication interface, and the processor are interconnected; the memory stores a computer program, and the processor calls the computer program stored in the memory to implement the cluster security inspection method according to any one of claims 1 to 5 or to implement the cluster security inspection method according to any one of claims 6 to 8.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the cluster security check method according to any one of claims 1 to 5 or the cluster security check method according to any one of claims 6 to 8.

13. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which, when executed by a processor, implement the cluster security check method according to any one of claims 1 to 5 or the cluster security check method according to any one of claims 6 to 8.

Images