CN119442282B - Cluster detection method, device, equipment, medium and product - Google Patents

Abstract

The application provides a cluster detection method, device, equipment, medium and product, wherein the method comprises the steps of determining a target container group from a plurality of container groups deployed by a first computing cluster, responding to at least one event selected from a target file reading event of a container in the first container group and a key event triggered by a container in a second container group, determining a service account number associated with at least one of the first container group and the second container group as a target service account number, responding to the cluster audit event related to the target service account number, determining a security identification result of the cluster audit event related to the target service account number, and generating a detection result of the first computing cluster according to the security identification result. In the method, the security detection of the cluster dimension can be realized in the running process of the computing cluster.

Description

A cluster detection method, device, equipment, medium and product

Technical Field

The present application relates to the field of computer technology, and in particular to a cluster detection method, device, electronic device, computer-readable storage medium, and computer program product.

Background Art

With the continuous development of computer technology, computing clusters have emerged. Computing clusters are usually composed of multiple computing nodes, which work together to provide high-performance computing capabilities.

Generally, access and operation of computing cluster resources depend on accounts. For example, accounts in a computing cluster can be divided into user accounts representing real users, service accounts (SA) representing non-real users, and system accounts used within the cluster.

In some types of computing clusters, the permissions of accounts in the computing cluster can be managed based on the role-based access control (RBAC) mechanism. Specifically, in the RBAC mechanism, different permissions are assigned to different accounts by defining roles or cluster roles with different permissions and binding the roles or cluster roles to the accounts.

If the relevant information of a service account with higher permissions is obtained by others, they can access and operate the computing cluster resources through the service account. Since the service account has higher permissions, the above access and operation behaviors have a greater impact on the security of the computing cluster and may cause the computing cluster to be compromised. Therefore, it is particularly important to conduct comprehensive security testing from the cluster dimension.

Summary of the invention

The present application provides a cluster detection method. The method can realize cluster-dimensional security detection during the operation of a computing cluster. The present application also provides a device, an electronic device, a computer-readable storage medium, and a computer program product corresponding to the above method.

In a first aspect, the present application provides a cluster detection method, the method comprising:

Determine a target container group from multiple container groups deployed in the first computing cluster; wherein the target container group is determined based on at least one of container group information and role access control information;

In response to detecting at least one of the following events: a target file read event for a container in a first container group and a key event triggered by a container in a second container group, determining a service account associated with at least one of the first container group and the second container group as a target service account; wherein the first container group and the second container group are at least one container group in the target container group;

In response to detecting a cluster audit event associated with the target service account, determining a security identification result of the cluster audit event associated with the target service account;

A detection result of the first computing cluster is generated according to the security identification result.

In a second aspect, the present application provides a cluster detection device, the device comprising:

A first determination module, configured to determine a target container group from a plurality of container groups deployed in the first computing cluster; wherein the target container group is determined based on at least one of container group information and role access control information;

a second determination module, configured to, in response to detecting at least one of the following events: a target file read event for a container in the first container group and a key event triggered by a container in the second container group, determine a service account associated with at least one of the first container group and the second container group as a target service account; wherein the first container group and the second container group are at least one container group in the target container group;

an identification module, configured to, in response to detecting a cluster audit event associated with the target service account, determine a security identification result of the cluster audit event associated with the target service account;

A detection module is used to generate a detection result of the first computing cluster according to the security identification result.

In a third aspect, the present application provides an electronic device, the electronic device comprising a processor and a memory. The processor and the memory communicate with each other. The processor is used to execute instructions stored in the memory, so that the electronic device performs the cluster detection method in the first aspect or any implementation of the first aspect.

In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, wherein the instructions instruct an electronic device to execute the cluster detection method described in the first aspect or any implementation manner of the first aspect.

In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed on an electronic device, enables the electronic device to execute the cluster detection method described in the first aspect or any one of the implementations of the first aspect.

Based on the implementations provided in the above aspects, this application can also be further combined to provide more implementations.

It can be seen from the above technical solutions that this application has the following advantages:

The present application provides a cluster detection method. The method first determines a target container group from multiple container groups of a first computing cluster, wherein the target container group is determined based on at least one of container group information and role access control information. In response to detecting at least one of the following events: a target file read event for a container in the first container group and a key event triggered by a container in the second container group, a service account associated with at least one of the first container group and the second container group is determined as a target service account, wherein the first container group and the second container group are at least one container group in the target container group. In response to detecting a cluster audit event related to the target service account, a security identification result of the cluster audit event related to the target service account is determined. Then, a detection result of the first computing cluster is generated according to the security identification result.

In this method, by identifying the target container group in the computing cluster and combining it with events related to the target container group, the target service account that needs attention is determined. By detecting cluster audit events related to the target service account, it is determined whether the target service account has unsafe access or operation behavior against the computing cluster. In this way, cluster-level security detection is achieved during the operation of the computing cluster.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical method of the embodiments of the present application, the drawings required for use in the embodiments are briefly introduced below.

FIG1 is a schematic diagram of the architecture of a cluster detection system provided in an embodiment of the present application;

FIG2 is a schematic diagram of a flow chart of a cluster detection method provided in an embodiment of the present application;

FIG3 is a schematic diagram of a process for determining a target container group provided in an embodiment of the present application;

FIG4 is a schematic diagram of the structure of a cluster detection device provided in an embodiment of the present application;

FIG5 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

DETAILED DESCRIPTION

The terms "first" and "second" in the embodiments of the present application are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features.

First, some technical terms and application scenarios involved in the embodiments of this application are introduced.

A computing cluster is usually composed of multiple computing nodes, which work together to provide high-performance computing capabilities. Among them, computing nodes can be physical machines or virtual machines. Usually, computing clusters are used to perform complex computing tasks that require a large amount of computing resources and storage resources, such as data analysis, machine learning, and graphics rendering.

In a computing cluster, a container group (POD) is the smallest unit that can be created and managed. In other words, a container group can be understood as the basic deployment unit in a computing cluster. A container group usually encapsulates one or more containers, and containers running in the same container group share network resources and storage resources.

With the continuous development of cloud computing technology, more and more users (such as organizations, enterprises, etc.) are adopting micro services architecture to deploy business applications. In the micro services architecture, business applications are decomposed into multiple small, independent services, each of which implements a specific business function.

Business applications with microservice architecture can be deployed in computing clusters. Specifically, each service of a business application can be packaged into different containers in the computing cluster. The containers include the dependencies and configurations required to run each service. Containerization provides isolation, ensures environmental consistency between different services, and thus improves the maintainability, scalability, and reliability of business applications.

The above process of deploying a microservice architecture business application in a computing cluster can be implemented by a container orchestration system. Among them, the container orchestration system, which can also be called a container orchestration platform or a container orchestration engine, is a software system for automatically deploying, expanding, and managing business applications in a computing cluster. For example, the container orchestration system can be a Kubernetes (K8s) system.

Generally, access and operation of computing cluster resources depend on accounts. For example, accounts in a computing cluster can be divided into user accounts representing real users, service accounts (SA) representing non-real users, and system accounts used within the cluster.

In some types of computing clusters (such as K8s clusters), the permissions of accounts in the computing cluster can be managed based on the role-based access control (RBAC) mechanism. Specifically, in the RBAC mechanism, different permissions are assigned to different accounts by defining roles or cluster roles with different permissions and binding the roles or cluster roles to accounts. For example, in the RBAC mechanism, role A is created, allowing role A to access and operate cluster resource B in the computing cluster. By binding role A to service account C, service account C can access and operate cluster resource B in the computing cluster.

If the relevant information of a service account with higher permissions is obtained by others, they can access and operate the computing cluster resources through the service account. Since the service account has higher permissions, the above access and operation behaviors have a greater impact on the security of the computing cluster and may lead to the collapse of the computing cluster. In other words, if the relevant information of a service account with higher permissions is obtained by others, it may lead to the escape and lateral penetration attacks of the cluster dimension through the service account, which has a greater impact.

Specifically, taking the container orchestration system as the K8s system as an example, when the container is started, the K8s system will mount information related to the service account, such as tokens and certificates, to the container. At the same time, the K8s system will create a service named kubernetes.default for the container, which is used for the container to communicate with the K8s system. In this way, if the relevant information of the service account is obtained by others, they can use the token and certificate related to the service account in the container to communicate with the K8s system through the kubernetes.default service, and access and operate computing cluster resources.

In related technologies, image vulnerability analysis, cluster configuration detection, and other methods are usually used to detect computing clusters. However, the above methods are usually based on static files or configurations, and can only detect computing clusters in advance, but cannot be detected during the operation of computing clusters. During the operation of computing clusters, the detection dimension is limited to independent containers and cannot be associated with the security detection of the entire computing cluster.

In view of this, the present application provides a cluster detection method, which first determines a target container group from multiple container groups of a first computing cluster, wherein the target container group is determined based on at least one of container group information and role access control information, in response to detecting at least one of the following events: a target file read event for a container in the first container group and a key event triggered by a container in the second container group, determining a service account associated with at least one of the first container group and the second container group as a target service account, wherein the first container group and the second container group are at least one container group in the target container group, in response to detecting a cluster audit event related to the target service account, determining a security identification result of the cluster audit event related to the target service account, and then generating a detection result of the first computing cluster based on the security identification result.

In this method, by identifying the target container group in the computing cluster and combining it with events related to the target container group, the target service account that needs attention is determined. By detecting cluster audit events related to the target service account, it is determined whether the target service account has unsafe access or operation behavior against the computing cluster. In this way, cluster-level security detection is achieved during the operation of the computing cluster.

To facilitate understanding of the technical solution provided by the embodiments of the present application, it will be described below with reference to the accompanying drawings.

Referring to the schematic diagram of the architecture of a cluster detection system shown in FIG. 1 , the cluster detection system 10 includes an asset identifier 101 , a behavior detector 102 , and a cluster detector 103 .

The asset identifier 101 is used to determine a target container group from multiple container groups deployed in the first computing cluster. Specifically, the asset identifier 101 can determine the target container group from multiple container groups deployed in the first computing cluster based on at least one of container group information and role access control information.

The behavior detector 102 is used to detect behaviors related to the target container group and determine the target service account. Specifically, the behavior detector 102 can determine the service account associated with at least one of the first container group and the second container group as the target service account in response to detecting at least one of the following events: a target file read event for a container in the first container group and a key event triggered by a container in the second container group, wherein the first container group and the second container group are at least one container group in the target container group.

The cluster detector 103 is used to generate a detection result of the computing cluster. Specifically, the cluster detector 102 can determine the security identification result of the cluster audit event related to the target service account in response to detecting the cluster audit event related to the target service account, and generate a detection result of the first computing cluster according to the security identification result.

In this way, the target container group that needs attention is identified through information related to the computing cluster assets, and the target service account that needs attention is identified by detecting behaviors related to the target container group. During the operation of the computing cluster, the real-time behavior of the computing cluster is detected from the perspective of cluster audit events, focusing on the characteristics related to the computing cluster, and combining the characteristics when the target service account is used to determine the security of the real-time behavior of the computing cluster, thereby achieving security detection for the computing cluster.

Based on the schematic diagram of the cluster detection system architecture provided above, the present application embodiment further provides a cluster detection method. Referring to FIG. 2 , a schematic diagram of a cluster detection method provided in the present application embodiment, the method specifically includes:

S201: Determine a target container group from multiple container groups deployed in a first computing cluster.

Among them, the first computing cluster can be understood as a computing cluster with cluster detection requirements. For example, the first computing cluster can be a computing cluster after the business application is deployed by the container orchestration system. When the container orchestration system is a K8s system, the first computing cluster can be a K8s computing cluster.

In the first computing cluster, multiple container groups are deployed. Each container group encapsulates at least one container, and each service of the business application can run in the container of each container group.

The target container group can be understood as at least one container group that needs to be paid attention to during the cluster detection process. In an embodiment of the present application, the target container group is determined based on at least one of the container group information and the role access control information. In other words, considering that there are a large number of container groups in the first computing cluster, the container groups are identified based on the cluster asset information, and the target container groups that need to be paid attention to are identified therefrom. On the one hand, the security level of the container group is judged based on the cluster asset information, and the target container group with a lower security level is identified. On the other hand, the number of container groups that need to be paid attention to in the future is reduced, and the cluster detection efficiency is improved.

Among them, container group information can be understood as asset information related to the container group. For example, the container group information can include the container group name, the namespace of the container group, the service account associated with the container group, the running status information of the container group, the information of the containers in the container group, etc.

Role access control information can be understood as asset information related to role access control. For example, role access control information can include role information, cluster role information, role permission information, cluster role permission information, account information, association information between roles and accounts, association information between cluster roles and accounts, etc.

Referring to a flow chart of determining a target container group shown in FIG3 , in a specific implementation, at least one of the following information of multiple container groups deployed by the first computing cluster can be first obtained: container group information and role access control information, and then at least one of the following is determined as the target container group: a container group whose container group information meets a first set condition and a container group associated with a service account whose role access control information meets a second set condition.

That is, in an embodiment of the present application, by obtaining container group information and/or role access control information, based on set conditions corresponding to the container group information and/or role access control information, a target container group with a lower security level and requiring attention is determined from multiple container groups of the first computing cluster.

Embodiments of the present application support obtaining container group information and/or role access control information of multiple container groups of the first computing cluster in different ways. Continuing with FIG3 , in some embodiments, in response to detecting a cluster audit event of the first computing cluster, at least one of the following information is extracted from the cluster audit event of the first computing cluster: container group information and role access control information.

The cluster audit event can be understood as an event generated after accessing or operating a computing cluster resource. In other words, when accessing or operating a computing cluster resource is triggered, a cluster audit event can be detected.

In some possible implementations, cluster audit events in the first computing cluster may be detected based on an extended Berkeley packet filter technique.

The cluster audit event carries container group information and role access control information. By analyzing the cluster audit event, at least one of the container group information and the role access control information can be extracted from the cluster audit event.

Combined with the example explanation, cluster audit events can have the following format:

By extracting the content in user, role access control information is obtained, and by extracting the content in objectRef, container group information is obtained. In this way, by detecting cluster audit events, at least one of container group information and role access control information is passively obtained, and cluster asset information is updated in real time.

In some other embodiments, an information acquisition interface of a container orchestration system is called to acquire at least one of the following information of multiple container groups of the first computing cluster: container group information and role access control information. The container orchestration system is used to manage multiple container groups of the first computing cluster.

A container orchestration system, such as a K8s system, typically provides an application programming interface (API) for obtaining cluster asset information. By calling the information acquisition interface provided by the container orchestration system, at least one of the container group information and role access control information is actively obtained to update the cluster asset information.

After obtaining container group information and/or role access control information of multiple container groups of the first computing cluster, the container group information is judged based on the first setting condition, or the role access control information is judged based on the second setting condition, and then the target container group is determined according to the judgment result. The first setting condition may be a condition for describing the container group information of the target container group, that is, the first setting condition may describe a condition for judging a container group with a low security level, a security risk, or a container group that needs attention.

The following describes some possible first setting conditions:

1. Host namespace: Sharing the namespace on the host is prohibited. The spec.hostNetwork field, spec.hostPID field, and spec.hostIPC field in the container group information are judged. If the field values of the above fields are not Undefined, nil, or false, the first setting condition is met.

2. AppArmor: It is forbidden to overwrite or disable the default policy (RuntimeDefault AppArmor configuration) and to overwrite permissions for some configuration sets. Determine the spec.securityContext.appArmorProfile.type field, spec.containers[*].securityContext.appArmorProfile.type field, spec.initContainers[*].securityContext.appArmorProfile.type field, spec.ephemeralContainers[*].securityContext.app ArmorProfile.type field, and metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"] field in the container group information. If the field values of the above fields are not Undefined, nil, Runtime, Default, or Localhost, the first setting condition is met.

3.SELinux: It is forbidden to set SELinux type operations, and it is forbidden to set custom SELinux users or roles. Determine the spec.securityContext.seLinuxOptions.type field, spec.containers[*].securityContext.seLinuxOptions.type field, spec.initContainers[*].securityContext.seLinuxOptions.type field, and spec.ephemeralContainers[*].securityContext.seLinuxOptions.type field in the container group information. If the field values of the above fields are not Undefined, container_t, container_kvm_t, or container_engine_t, the first setting condition is met. The spec.securityContext.seLinuxOptions.user field, spec.containers[*].securityContext.seLinuxOptions.user field, spec.initContainers[*].securityContext.seL inuxOptions.user field, spec.ephemeralContainers[*].securityContext.seLinuxOptions.user field, spec.securityContext.seLinuxOptions.role field, spec.containers[*].securityContext.seLinuxOptions.role field, spec.initContainers[*].securityContext.seLinuxOptions.role field, and spec.ephemeralContainers[*].securityContext.seLinuxOptions.role field in the container group information are judged. If the field values of the above fields are not Undefined, the first setting condition is met.

4. /proc mount type: requires the use of the default /proc mask. Determine the spec.containers[*].securityContext.procMount field, spec.initContainers[*].securityContext.procMount field, and spec.ephemeralContainers[*].securityContext.procMount field in the container group information. If the field values of the above fields are not Undefined, nil, or Default, the first setting condition is met.

5.Seccomp: Do not set the Seccomp configuration to Unconfined. Determine the spec.securityContext.seccompProfile.type field, spec.containers[*].securityContext.seccompProfile.type field, spec.initContainers[*].securityContext.seccompProfile.type field, and spec.ephemeralContainers[*].securityContext.seccompProfile.type field in the container group information. If the field values of the above fields are not Undefined, nil, Runtime, Default, or Localhost, the first setting condition is met.

6. Sysctls: Prohibit configuration except for the allowed subset. Determine the spec.securityContext.sys ctls[*].name field in the container group information. If the field value of the above field is not Undefined, nil, kernel.shm_rmid_forced, net.ipv4.ip_local_port_range, net.ipv4.ip_unprivileged_port_start, net.ipv4.tcp_syncookies, net.ipv4.ping_group_range, net.ipv4.ip_local_reserved_ports, net.ipv4.tcp_keepalive_time, net.ip v4.tcp_fin_timeout, net.ipv4.tcp_keepalive_intvl or net.ipv4.tcp_keepalive_probes, then the first setting condition is met.

7. Volume type: Configurations other than permitted volume types are prohibited. Determine the spec.volumes[*] field in the container group information. If spec.volumes[*].configMap, spec.volumes[*].csi, spec.volumes[*].downwar dAPI, spec.volumes[*].emptyDir, spec.volumes[*].ephemeral, spec.volumes[*].persistentVol umeClaim, spec.volumes[*].projected, and spec.volumes[*].secret in the above fields are all empty values, the first setting condition is met.

8. Privilege escalation: Privilege escalation is prohibited. The spec.containers[*].securityContext.allowPrivilegeEscalation field, the spec.initContainers[*].securityContext.allowPrivilegeEscalation field, and the spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation field in the container group information are judged. If the field values of the above fields are not false, the first setting condition is met.

9. Run as a non-root account: Requires the container to run as a non-root account. Determine the spec.securityContext.runAsNonRoot field, spec.containers[*].securityContext.runAsNonRoot field, spec.initContainers[*].securityContext.runAsNonRoot field, and spec.ephemeralContainers[*].securityContext.runAsNonRoot field in the container group information. If the field values of the above fields are not true, Undefined, or nil, the first setting condition is met.

10. Non-root users: Do not set the runAsUser of a container to 0. Determine the spec.securityContext.runAsUser field, spec.containers[*].securityContext.runAsUser field, spec.initCont ainers[*].securityContext.runAsUser field, and spec.ephemeralContainers[*].securityContext.runAs User field in the container group information. If the field values of the above fields are not non-zero values, Undefined, or null, the first setting condition is met.

11. Capabilities: Require the container to abandon ALL capabilities and only allow the addition of NET_BIND_SERVICE capabilities. Determine the spec.containers[*].securityContext.capabilities.add field, spec.initContainers[*].securityContext.capabilities.add field, and spec.ephemeralContainers[*].securityContext.capabilities.add field in the container group information. If the field values of the above fields are not Undefined, nil, or NET_BIND_SERVICE, the first setting condition is met.

In this way, by setting a first setting condition for describing a container group with security risks (for example, a privileged container group), a target container group whose container group information meets the first setting condition and needs attention is identified from the container group information of multiple container groups of the first computing cluster.

The second setting condition may be a condition for describing a service account associated with the target container group. One container group is associated with one service account, that is, one container group has a corresponding relationship with one service account. In other words, the second setting condition may describe a condition for determining a container group associated with a service account with a low security level and a risk of privilege escalation.

Some possible second setting conditions are described below:

1. List Secrets: Determine whether the service account is allowed to perform get, list, or watch access to Secrets. If so, the second setting condition is met.

2. Workload creation: Determine whether the namespace is used to isolate resources required by different trust levels or different tenants. If not, the second setting condition is met.

3. Creation of persistent volume: Determine whether the service account is allowed to create PersistentVolume. If so, the second setting condition is met.

4. Access the proxy sub-resource of Node: Determine whether the service account that has access to the proxy sub-resource of the Node object has access to the kubelet API. If so, the second setting condition is met.

5. Esclate action: Determine whether the service account is involved in the esclate action. If so, the second setting condition is met.

6. Bind action: Determine whether the service account involves a bind action. If so, the second setting condition is met.

7. Impersonate action: Determine whether the service account involves an impersonate action. If so, the second setting condition is met.

8. CSR and certificate issuance: Determine whether the service account has access to the CSR API. If so, the second setting condition is met.

9. Token request: Determine whether the service account has the create permission for serviceaccounts/token. If so, the second setting condition is met.

10. Control access to Webhook: Determine whether the service account has the authority to control validatingwebhookconfigurations or mutatingwebhookconfigurations. If so, the second setting condition is met.

11. Namespace modification: Determine whether the service account has the authority to perform patch operations on the namespace object. If so, the second setting condition is met.

In this way, by setting a second setting condition for describing service accounts with low security levels and risks of privilege escalation, service accounts whose role access control information meets the second setting condition are identified from the role access control information of multiple container groups in the first computing cluster, and then the container groups associated with the service accounts that meet the second setting condition are determined as target container groups that need attention.

S202: In response to detecting at least one of the following events: a target file read event for a container in the first container group and a key event triggered by a container in the second container group, determining a service account associated with at least one of the first container group and the second container group as a target service account.

In the embodiment of the present application, the first container group and the second container group are at least one container group in the target container group. That is, if there is a target file read event for a container in one or some container groups in the target container group in the detected cluster audit event, or there is a key event triggered by a container in one or some container groups in the target container group, the service account related to the target file read event is determined as the target service account, and the service account related to the key event is determined as the target service account.

The target service account may be understood as a service account that needs attention. In the cluster detection scenario of the embodiment of the present application, the target service account may be understood as a service account that has a risk of leakage of relevant information of the service account and whose relevant information may be obtained by others.

The target file read event can be used to open or read a file of a container in the first container group. In some possible implementations, the target file read event for a container in the first container group includes: an event in which a process other than the main process of the first computing cluster reads a file related to a service account of a container in the first container group.

That is to say, by detecting cluster audit events, file read events are filtered out from the cluster audit events, and then file read events for reading files related to the service account are filtered out from the file read events. For example, the file path of the file read event for reading files related to the service account may be /var/run/secrets/kubernetes.io/serviceaccount, and then file read events for file reading by processes other than the main process of the first computing cluster are filtered out to obtain the target file read event.

Considering that the files related to the service account (such as tokens and certificates) mounted in the container are for better use of computing cluster resources, other processes usually do not involve opening or reading files related to the service account during normal operation. Therefore, by detecting the target file read event, the unsafe file read behavior in the target container group is identified, and then the service account associated with the first container group with the unsafe file read behavior is determined as the target service account that needs attention.

A critical event can be understood as an event involving an unsafe container behavior. That is, by detecting cluster audit events, it is determined whether the cluster audit event is a critical event. If so, the service account associated with the second container group that performs the unsafe container behavior is determined as a target service account that needs attention.

The embodiments of the present application do not limit the method for determining whether a cluster audit event is a critical event. For example, cluster audit events involving critical software execution, rebound shell, memory Trojans, backdoor residency, credential theft, container escape, port scanning, remote control, data transfer, etc. can be determined as critical events.

S203: In response to detecting a cluster audit event related to the target service account, determine a security identification result of the cluster audit event related to the target service account.

After determining the target service account that needs attention, the cluster audit events related to the target service account are detected to determine whether the cluster audit events related to the target service account are safe.

In a specific implementation, in response to detecting a cluster audit event of the first computing cluster, role access control information is extracted from the cluster audit event of the first computing cluster, and in response to a service account corresponding to the role access control information being a target service account, a security identification result of the cluster audit event is determined.

That is to say, the cluster audit events of the first computing cluster are detected, and based on the role access control information carried by the cluster audit events of the first computing cluster, it is determined whether the cluster audit events are related to the target service account, and then the cluster audit events related to the target service account are screened out from a large number of cluster audit events, and targeted security identification is performed on the cluster audit events related to the target service account.

In some possible implementations, in response to detecting a cluster audit event related to a target service account, when the cluster audit event related to the target service account satisfies a third set condition, a security identification result indicating that the cluster audit event is insecure is determined.

The third setting condition can be used to describe an unsafe cluster audit event. Furthermore, in the security identification result that characterizes the unsafe cluster audit event, the unsafe level can be further divided, for example, the security identification result that characterizes the unsafe cluster audit event can be divided into different unsafe levels such as low risk and high risk.

Some possible third setting conditions are described below:

1. Credential abuse: Determine whether there is any abuse of the ServiceAccount token using curl, abuse of the ServiceAccount token using kubectl, abuse of the ServiceAccount using penetration testing tools, or acquisition of secrets lists and secrets contents in the cluster audit events related to the target service account. If so, the third set condition is met.

2. Anonymous access: Determine whether there is any anonymous access behavior in the cluster audit events related to the target service account. If so, the third setting condition is met.

3. Configuration modification: Determine whether there is any behavior of modifying the DNS configuration in the cluster audit events related to the target service account. If so, the third setting condition is met.

4. Admission Webhook creation: Determine whether there is any behavior of creating an admission controller in the cluster audit events related to the target service account. If so, the third setting condition is met.

5. Authorization failure: Determine whether the cluster audit events related to the target service account include the following: failure to create cronjob authorization, failure to obtain configmaps authorization, failure to obtain configmaps authentication, failure to obtain replicasets authorization, failure to obtain secrets authorization, failure to obtain secrets authentication, failure to obtain pods authorization, failure to obtain pods authentication, failure to enumerate workloads authorization, multiple authorization failures when the same user name accesses different resources, and multiple authorization failures when different user names access the same resource. If so, the third set condition is met.

6. Abnormal command execution: Determine whether the cluster audit events related to the target service account include executing attach commands on pods, executing commands in pods, executing curl commands in pods, obtaining Pods list, executing commands in containers, interacting with API Server, executing commands in pods to read SAtoken, executing wget commands in pods, executing whoami commands in pods, and executing portforward commands on pods. If so, the third set condition is met.

7. Information collection: Determine whether there is any behavior of using penetration testing tools to obtain cluster configmaps, using penetration testing tools to obtain cluster PSP security configuration, and using penetration testing tools to obtain ETCD information in the cluster audit events related to the target service account. If so, the third setting condition is met.

8. Permission detection: Determine whether there is any behavior of multiple permissions detection by the same identity in a short period of time in the cluster audit events related to the target service account. If so, the third setting condition is met.

9. Key role creation: Determine whether there are any abnormal accounts creating cronjobs, creating NodePort type Services, creating ClusterRoleBindings bound to key ClusterRole, creating RoleBindings bound to Roles in the system namespace, creating RoleBindings bound to key ClusterRole, creating RoleBindings bound to key Roles, creating containers that mount host key directories, creating privileged containers, creating containers with key capabilities, and creating containers that share host networks in cluster audit events related to the target service account. If so, the third setting condition is met.

10. Password theft: Determine whether there is any use of penetration testing tools to obtain cluster secrets, abuse of kubelet accounts to enumerate secrets in all namespaces, abuse of ServiceAccount to enumerate secrets in all namespaces, or use of BOtB tools to enumerate secrets in the default namespace in cluster audit events related to the target service account. If so, the third setting condition is met.

In this way, by comparing the cluster audit event related to the target service account with the third set condition, it is determined whether the cluster audit event related to the target service account is an unsafe cluster audit event, and a security identification result is obtained.

In some other possible implementations, in response to detecting a cluster audit event related to a target service account, and the cluster audit event related to the target service account is an event for creating or modifying a container group, operation information of containers in the created or modified container group is obtained, and a security identification result of the cluster audit event related to the target service account is determined based on the operation information of the containers in the created or modified container group.

That is, when a service account that needs attention creates or modifies a container group, others may use the service account that needs attention to perform unsafe container behaviors in the containers in the created or modified container group. Therefore, the running information of the containers in the created or modified container group is detected to determine whether the cluster audit event of the service account that needs attention creating or modifying the container group is safe.

The embodiments of the present application do not limit the method of determining the security identification result of the cluster audit event related to the target service account based on the running information of the container in the created or modified container group. For example, if the running information of the container in the created or modified container group involves key software execution, rebound shell, memory Trojan, backdoor residence, credential theft, container escape, port scanning, remote control, data transfer and other behaviors, a security identification result representing that the cluster audit event is unsafe is determined.

In this way, by detecting the cluster operation behavior of the target service account with information leakage risk, and detecting the container behavior of the container assets created by the target service account with information leakage risk, the cluster audit events related to the target service account can be securely identified.

S204: Generate a detection result of the first computing cluster according to the security identification result.

By performing security identification on cluster audit events of target service accounts with information leakage risks, the first computing cluster can be detected.

In some possible implementations, at least one security identification result within a set time period is obtained, and a detection result of the first computing cluster is generated based on at least one of the security identification results within the set time period. In other words, the security status of cluster audit events related to the target service account within the set time period is counted to comprehensively determine the detection result of the first computing cluster.

The set time period can be set based on actual business needs. For example, the set time period can be 2 hours.

In some embodiments, when the number of security identification results indicating that cluster audit events are unsafe reaches a set threshold (eg, 3) within a set time period, the detection result of the first computing cluster is determined to be unsafe, and there is a possibility that the computing cluster may be compromised.

In other embodiments, in the security identification results that characterize the insecurity of cluster audit events, the insecurity levels are further divided. At this time, when the number of different insecurity levels in the security identification results that characterize the insecurity of cluster audit events within a set time period meets the corresponding set threshold (for example, the number of insecurity levels of high risk reaches 2, and the number of insecurity levels of low risk reaches 1), the detection result of the first computing cluster is determined to be insecure, and there is a possibility of computing cluster loss.

Among them, the threshold value can be set based on actual business needs, and the embodiments of the present application do not limit this.

Furthermore, when the detection result of the first computing cluster is unsafe, an alarm message may be generated to inform the user (eg, a security operator) that there is a possibility of the computing cluster being compromised, so as to facilitate rapid disposal.

In this method, by identifying the target container group in the computing cluster and combining it with events related to the target container group, the target service account that needs attention is determined. By detecting cluster audit events related to the target service account, it is determined whether the target service account has unsafe access or operation behavior against the computing cluster. In this way, cluster-level security detection is achieved during the operation of the computing cluster.

The above text has described in detail the cluster detection method provided in the embodiment of the present application in conjunction with Figures 1 to 3. The following text will describe the apparatus and device provided in the embodiment of the present application in conjunction with the accompanying drawings.

Referring to the schematic structural diagram of a cluster detection device shown in FIG4 , the device 40 includes:

A first determination module 401 is used to determine a target container group from multiple container groups deployed in the first computing cluster; wherein the target container group is determined based on at least one of container group information and role access control information;

The second determining module 402 is configured to determine, in response to detecting at least one of the following events: a target file read event for a container in the first container group and a key event triggered by a container in the second container group, a service account associated with at least one of the first container group and the second container group as a target service account; wherein the first container group and the second container group are at least one container group in the target container group;

an identification module 403, configured to determine a security identification result of the cluster audit event related to the target service account in response to detecting the cluster audit event related to the target service account;

The detection module 404 is configured to generate a detection result of the first computing cluster according to the security identification result.

In some possible implementations, the first determining module 401 is specifically configured to:

Obtain at least one of the following information of multiple container groups deployed by the first computing cluster: container group information and role access control information;

At least one of the following is determined as the target container group: a container group whose container group information satisfies a first set condition and a container group associated with a service account whose role access control information satisfies a second set condition.

In some possible implementations, the first determining module 401 is specifically configured to:

In response to detecting a cluster audit event of the first computing cluster, extracting at least one of the following information from the cluster audit event of the first computing cluster: container group information and role access control information.

In some possible implementations, the first determining module 401 is specifically configured to:

Calling an information acquisition interface of a container orchestration system to obtain at least one of the following information of multiple container groups deployed by the first computing cluster: container group information and role access control information; wherein the container orchestration system is used to manage the multiple container groups deployed by the first computing cluster.

In some possible implementations, the target file reading event for the container in the first container group includes: an event in which a process other than the main process of the first computing cluster reads a file related to a service account in a container in the first container group.

In some possible implementations, the identification module 403 is specifically configured to:

In response to detecting a cluster audit event of a first computing cluster, extracting role access control information from the cluster audit event of the first computing cluster;

In response to the service account corresponding to the role access control information being the target service account, a security identification result of the cluster audit event is determined.

In some possible implementations, the identification module 403 is specifically configured to:

In response to detecting a cluster audit event related to the target service account, when the cluster audit event related to the target service account satisfies a third set condition, a security identification result indicating that the cluster audit event is unsafe is determined.

In some possible implementations, the identification module 403 is specifically configured to:

In response to detecting a cluster audit event related to the target service account, and the cluster audit event related to the target service account is an event for creating or modifying a container group, obtaining operation information of a container in the created or modified container group;

Determine a security identification result of a cluster audit event related to the target service account according to the running information of the container in the created or modified container group.

In some possible implementations, the detection module 404 is specifically configured to:

Obtaining at least one of the security identification results within a set time period;

A detection result of the first computing cluster is generated according to at least one of the security identification results within the set time period.

The cluster detection device 40 according to the embodiment of the present application may correspond to executing the method described in the embodiment of the present application, and the above and other operations and/or functions of each module/unit of the cluster detection device 40 are respectively for implementing the corresponding processes of each method in the embodiment shown in Figure 2, which will not be repeated here for the sake of brevity.

The embodiment of the present application also provides an electronic device, which is specifically used to implement the function of the cluster detection device 40 in the embodiment shown in FIG. 4 .

FIG5 provides a schematic diagram of the structure of an electronic device 500. As shown in FIG5, the electronic device 500 includes a bus 501, a processor 502, a communication interface 503 and a memory 504. The processor 502, the memory 504 and the communication interface 503 communicate with each other via the bus 501.

The bus 501 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, FIG5 is represented by only one thick line, but it does not mean that there is only one bus or one type of bus.

The processor 502 may be any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

The communication interface 503 is used for communicating with the outside. For example, the communication interface 503 can be used for communicating with a terminal.

The memory 504 may include a volatile memory, such as a random access memory (RAM). The memory 504 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

The memory 504 stores executable codes, and the processor 502 executes the executable codes to perform the aforementioned cluster detection method.

Specifically, in the case of implementing the embodiment shown in FIG4 , and in the case where each module or unit of the cluster detection device 40 described in the embodiment of FIG4 is implemented by software, the software or program code required to execute the functions of each module/unit in FIG4 may be partially or completely stored in the memory 504. The processor 502 executes the program code corresponding to each unit stored in the memory 504 to execute the aforementioned cluster detection method.

The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (such as a floppy disk, a hard disk, a tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the above-mentioned cluster detection method applied to the cluster detection device 40.

The embodiment of the present application further provides a computer program product, which includes one or more computer instructions. When the computer instructions are loaded and executed on a computing device, the process or function described in the embodiment of the present application is generated in whole or in part.

The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer or data center to another website, computer or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

When the computer program product is executed by a computer, the computer executes any of the aforementioned cluster detection methods. The computer program product may be a software installation package, and when any of the aforementioned cluster detection methods is needed, the computer program product may be downloaded and executed on a computer.

The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to each embodiment of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and/or flow chart, and the combination of the square boxes in the block diagram and/or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

The units involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the unit/module does not, in some cases, constitute a limitation on the unit itself.

The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

In the context of the present application embodiment, machine-readable medium can be a tangible medium that can contain or store a program for use by an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable medium can include but is not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the above. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above.

It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the system or device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And/or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and/or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character "/" generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

It should also be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims (13)

1. A cluster detection method, characterized in that the method comprises: Determine a target container group from multiple container groups deployed in the first computing cluster; wherein the target container group is determined based on at least one of container group information and role access control information; In response to detecting at least one of the following events: a target file read event for a container in a first container group and a key event triggered by a container in a second container group, determining a service account associated with at least one of the first container group and the second container group as a target service account; wherein the first container group and the second container group are at least one container group in the target container group; In response to detecting a cluster audit event associated with the target service account, determining a security identification result of the cluster audit event associated with the target service account; A detection result of the first computing cluster is generated according to the security identification result. 2. The method according to claim 1, wherein determining the target container group from the multiple container groups deployed in the first computing cluster comprises: Obtain at least one of the following information of multiple container groups deployed by the first computing cluster: container group information and role access control information; At least one of the following is determined as the target container group: a container group whose container group information satisfies a first set condition and a container group associated with a service account whose role access control information satisfies a second set condition. 3. The method according to claim 2, characterized in that the obtaining of at least one of the following information of the multiple container groups deployed by the first computing cluster: container group information and role access control information, comprises: In response to detecting a cluster audit event of the first computing cluster, extracting at least one of the following information from the cluster audit event of the first computing cluster: container group information and role access control information. 4. The method according to claim 2, wherein the obtaining at least one of the following information of the multiple container groups deployed by the first computing cluster: container group information and role access control information, comprises: Calling an information acquisition interface of a container orchestration system to obtain at least one of the following information of multiple container groups deployed by the first computing cluster: container group information and role access control information; wherein the container orchestration system is used to manage the multiple container groups deployed by the first computing cluster. 5. The method according to claim 1 is characterized in that the target file reading event for the container in the first container group includes: an event in which other processes other than the main process of the first computing cluster read files related to the service account of the container in the first container group. 6. The method according to claim 1, wherein in response to detecting a cluster audit event related to the target service account, determining a security identification result of the cluster audit event related to the target service account comprises: In response to detecting a cluster audit event of a first computing cluster, extracting role access control information from the cluster audit event of the first computing cluster; In response to the service account corresponding to the role access control information being the target service account, a security identification result of the cluster audit event is determined. 7. The method according to claim 1, wherein in response to detecting a cluster audit event related to the target service account, determining a security identification result of the cluster audit event related to the target service account comprises: In response to detecting a cluster audit event related to the target service account, when the cluster audit event related to the target service account satisfies a third set condition, a security identification result indicating that the cluster audit event is unsafe is determined. 8. The method according to claim 1, wherein in response to detecting a cluster audit event related to the target service account, determining a security identification result of the cluster audit event related to the target service account comprises: In response to detecting a cluster audit event related to the target service account, and the cluster audit event related to the target service account is an event for creating or modifying a container group, obtaining operation information of a container in the created or modified container group; Determine a security identification result of a cluster audit event related to the target service account according to the running information of the container in the created or modified container group. 9. The method according to any one of claims 1 to 8, characterized in that generating the detection result of the first computing cluster according to the security identification result comprises: Obtaining at least one of the security identification results within a set time period; A detection result of the first computing cluster is generated according to at least one of the security identification results within the set time period. 10. A cluster detection device, characterized in that the device comprises: A first determination module, configured to determine a target container group from a plurality of container groups deployed in the first computing cluster; wherein the target container group is determined based on at least one of container group information and role access control information; a second determination module, configured to, in response to detecting at least one of the following events: a target file read event for a container in the first container group and a key event triggered by a container in the second container group, determine a service account associated with at least one of the first container group and the second container group as a target service account; wherein the first container group and the second container group are at least one container group in the target container group; an identification module, configured to, in response to detecting a cluster audit event associated with the target service account, determine a security identification result of the cluster audit event associated with the target service account; A detection module is used to generate a detection result of the first computing cluster according to the security identification result. 11. An electronic device, characterized in that the electronic device comprises a processor and a memory; The processor is configured to execute instructions stored in the memory, so that the electronic device performs the method according to any one of claims 1 to 9. 12 . A computer-readable storage medium, comprising instructions, wherein the instructions instruct an electronic device to execute the method according to claim 1 . 13. A computer program product, characterized in that the computer program product comprises computer-readable instructions, and the computer-readable instructions are used to implement the method according to any one of claims 1 to 9.