Kubernetes-based Pod terminal behavior auditing method and system

Abstract

The invention relates to the technical field of software development, in particular to a kubernetes-based Pod terminal behavior auditing method and system. Comprising the following steps: S1, establishing a terminal login request to connect a target Pod at a local client; s2, acquiring a node for operating the target Pod and an address and a port of the Kubelet through a Kube-Apiserver service; the method comprises the following steps: S1, a Kube-Apiserver service is established, S2, a Kube-Apiserver service is established, S3, when a request of the Kube-Apiserver service is forwarded to a container for operation through Kubeet, S4, a websocket connection is established between a target Pod and a client, and an audit-content service is established, S5, an audit-content-sync service is established, the audit-content-sync service consumes a message in a kafka message queue and a message pushed by the audit-content service, the messages are synchronously written into a database, and through cooperative work of the audit-content service and the audit-content-sync service, the information in the Kube-Apiserver service is forwarded to the container for operation. According to the invention, the interaction information between the client and the target Pod can be completely recorded, and the operation executed by the user logging in the Pod terminal in the container cloud cluster can be audited.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, and in particular to a method and system for implementing Pod terminal behavior audit based on Kubernetes. Background Art

[0002] Kubernetes is an open source container orchestration engine for automating the deployment, expansion, and management of containerized applications. Pod is the smallest deployable and manageable unit in Kubernetes. A Pod can contain one or more closely related containers that share resources. These containers usually run on the same host and share network namespaces, storage volumes, and other resources. Pod terminal behavior auditing refers to the process of monitoring, recording, and analyzing the operational behavior of Pod terminals running in Kubernetes. By auditing Pod terminal behavior, you can understand the user's operations in the Pod, including the commands executed, the resources accessed, etc., so as to perform security monitoring, troubleshooting, and compliance checks.

[0003] In today's era of rapid digital development, cloud platform cluster environments have become the mainstream choice for many enterprises and organizations to deploy business services. With the continuous maturity and popularization of cloud computing technology, more and more key business services are running on cloud platforms in the form of containers. This containerized deployment method brings many advantages, such as efficient resource utilization, rapid deployment and expansion capabilities. However, with the rapid development of information technology and the increasing complexity of network attack methods, information security issues have become increasingly severe. Against this backdrop, the security requirements for business services in cloud platforms have also reached an unprecedented level. Especially in the cloud platform cluster environment, Pod, as the carrier of the container, the security and traceability of its operation are crucial.

[0004] In the daily operations of enterprises and organizations, users' operations on Pod terminals involve all aspects of business services, including data processing, configuration changes, service startup and shutdown, etc. If these operations lack effective supervision and auditing, they may lead to a series of serious security issues. For example, unauthorized users may misoperate or maliciously tamper with key configurations, thus affecting the normal operation of the business; sensitive data may be leaked due to improper operations, causing huge economic losses and reputation damage to the enterprise; in addition, untraceable operations also make it difficult to troubleshoot and determine responsibility when problems occur.

[0005] Therefore, in order to meet increasingly stringent security requirements, the need for auditing Pod operations has become increasingly strong. Comprehensive and accurate recording and auditing of operations performed by users logging into Pod terminals can not only timely identify potential security risks, but also provide administrators with the necessary information for effective security management and decision-making, ensuring the stable and secure operation of business services on the cloud platform. Summary of the invention

[0006] In a Kubernetes cluster, auditing the operations performed by users in a Pod lacks native support. Kubernetes itself does not natively provide the function of auditing Pod terminal user operations. On the other hand, there are some third-party tools, but third-party tools mainly analyze K8S audit logs and focus on cluster-level audits. The audit support for Pod terminal behaviors is insufficient. In order to solve the problem of recording user operations and providing them to administrators, the present invention provides a Pod terminal behavior audit method based on kubernetes.

[0007] In the first aspect, the present invention provides a Pod terminal behavior audit method based on kubernetes, which adopts the following technical solution: A Pod terminal behavior audit method based on kubernetes, including: S1. Establish a login terminal request on the local client to connect to the target Pod, and the login terminal request is sent to the Kube-Apiserver service via the HTTP protocol; S2. Get the node running the target Pod and the address and port of Kubelet through the Kube-Apiserver service; S3. The Kube-Apiserver service request is forwarded to the container runtime through Kubelet, and a process is created and executed in the container namespace and cgroup in the target Pod; S4. The target Pod establishes a websocket connection with the client and creates an audit-controller service. The audit-controller service pushes the client input content to Kafka. S5. Create an audit-record-sync service. The audit-record-sync service consumes messages in the kafka message queue and messages pushed by the audit-controller service, and synchronously writes the messages into the database to achieve persistent storage of client operation records.

[0008] Furthermore, the URL format of the Kube-Apiserver service is: http[s]: / / ${api_server} / ns / ${pod_namespace} / pods / ${pod_name} / exec?stdin=true&stdout=true&stderr=true&tty=true&container=${container_name}&command=sh.

[0009] Furthermore, the URL format between the Kube-Apiserver service and Kubelet is: http[s]: / / ${node_ip}:${kubelet_port} / exec / ${pod_namespace} / ${pod_name} / ${container_name``.

[0010] Further, obtaining the node running the target Pod and the address and port of the Kubelet includes establishing a streaming proxy connection between the node running the target Pod and the address and port of the Kubelet; Furthermore, after the streaming proxy connection is established, Kubelet receives the request of the Kube-Apiserver service and forwards it to the container runtime. Kubelet will continue to proxy the I / O stream between the API service and the container runtime for data transmission and interaction.

[0011] Furthermore, the specific steps of the audit-controller service pushing the client input content to Kafka are: the controller of the audit-controller service intercepts the response of the Pod to establish a websocket connection with the client, the target Pod directly connects to the audit-controller service, the audit-controller service creates a new websocket connection with the client, the audit-controller service obtains the client input content, and pushes the client input content to Kafka through the audit-controller service.

[0012] Furthermore, the kafka is set with a threshold time, if the threshold time is exceeded, the push fails, and the input content is stored in the controller. At the same time, kafka starts a separate process to listen to the information of the push failure, and restarts the push until the push succeeds.

[0013] Second, a Pod terminal behavior audit system based on kubernetes includes: The request connection module is configured to establish a login terminal request to connect to the target Pod on the local client, and the login terminal request is sent to the Kube-Apiserver service via the HTTP protocol; The port acquisition module is configured to obtain the node running the target Pod and the address and port of Kubelet through the Kube-Apiserver service; The resource management module is configured to forward the request of the Kube-Apiserver service to the container runtime through Kubelet, and create and execute the process in the container namespace and cgroup in the target Pod; The data processing module is configured to establish a websocket connection between the target Pod and the client, create an audit-controller service, and the audit-controller service pushes the client input content to Kafka; The data synchronization module is configured to create an audit-record-sync service, which consumes messages in the kafka message queue and messages pushed by the audit-controller service, and synchronously writes the messages into the database to achieve persistent storage of client operation records.

[0014] In a third aspect, the present invention provides a computer-readable storage medium storing a plurality of instructions, wherein the instructions are suitable for being loaded and executed by a processor of a terminal device, a Kubernetes-based Pod terminal behavior auditing method.

[0015] In a fourth aspect, the present invention provides a terminal device, including a processor and a computer-readable storage medium, the processor being used to implement various instructions; the computer-readable storage medium being used to store multiple instructions, the instructions being suitable for being loaded by the processor and executing the a Kubernetes-based Pod terminal behavior auditing method.

[0016] In summary, the present invention has the following beneficial technical effects: 1. A Pod terminal behavior audit method based on kubernetes, creating audit-controller and audit-record-sync services. Through the collaborative work of audit-controller and audit-record-sync services, the interaction information between the client and the target Pod can be fully recorded, including the client's input content and the target Pod's response, which helps enterprises to trace and analyze user operations, timely discover potential security risks and problems, and realize the audit of operations performed by users logging into Pod terminals in container cloud clusters; 2. In the present invention, the audit-controller is responsible for establishing a websocket link between the target Pod and the client, obtaining the client input content, sending the information to the kafka message middleware, and the audit-record-sync service consumes and writes the information to the database, which can avoid the blocking and performance problems caused by directly writing a large amount of data to the database. At the same time, the default timeout time and a separate process are set to monitor the messages that are not pushed successfully and try to restart the push, ensuring the reliability and integrity of the data, and will not cause data loss due to push failure. Through the intermediate proxy, the client and the server are unaware of the existence of the audit-controller, which does not affect the communication between the client and the server. Users can enjoy a smooth operating experience when using the Pod terminal, and will not feel obvious delays or freezes due to the introduction of the audit mechanism.

[0017] 3. audit-record-sync is responsible for consuming Kafka messages. By pushing the client input content to Kafka and synchronously writing it to the database, the client operation records are persistently stored for easy traceability. The overall solution is reasonably designed, which realizes comprehensive auditing and recording of Pod terminal user operation behaviors, improves the security and reliability of the system, and enterprises can deploy business applications on the container cloud platform to enjoy the advantages and convenience brought by container cloud technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 This is a schematic diagram of accessing through a virtual IP and port provided by a Service resource in the prior art of Embodiment 1 of the present invention; Figure 2 is a schematic diagram of interaction between a user terminal and a Pod in the prior art of Embodiment 1 of the present invention; Figure 3 This is the difference between the virtual machine mode and the Pod mode in Embodiment 1 of the present invention; Figure 4 is a schematic flow chart of the method of the present invention according to Embodiment 1 of the present invention; Figure 5 It is a working diagram of the audit-controller service and the audit-record-sync service of Example 1 of the present invention. DETAILED DESCRIPTION

[0019] The present invention is further described in detail below in conjunction with the accompanying drawings.

[0020] 1. Kubernetes: an open source container orchestration engine for automating the deployment, scaling, and management of containerized applications; 2.Service: used to define a set of logical Pods and policies for accessing them; 3. Pod: In Kubernetes, Pod is the smallest deployable unit. It is a collection of closely related containers that share network and storage resources and are scheduled and managed together. 4. WebSocket.: is a protocol for full-duplex communication over a single TCP connection, which allows real-time, two-way data transfer between browsers and servers without the need for frequent HTTP requests and responses; 5.HTTP: Hypertext Transfer Protocol, the most widely used network protocol on the Internet; 6. Kube-Apiserver: It is one of the core components of the Kubernetes control plane. It is responsible for providing the Kubernetes API and is the hub for communication between various components in the cluster. 7. URL: Uniform Resource Locator, is an address used to identify resources on the Internet. It provides a standard way to locate and access various resources on the network, such as web pages, images, files, databases, etc. 8. Kubelet: It is the worker node agent in the Kubernetes cluster. It runs on each node and is responsible for managing the Pods and containers on the node. 9. API: Application Programming Interface, a set of rules and interfaces that define the interactions between software components; 10. audit-controller: a customized service of the present invention; 11. Kafka: Kafka is a distributed stream processing platform, mainly used to process real-time data and streaming data; 12. audit-record-sync: a custom service of the present invention; 13.Client:client; 14. CRI: Container Runtime Interface, a standard interface defined by Kubernetes for interacting with different container runtimes; 15. MySQL: A widely used relational database management system.

[0021] Example 1 In the prior art, reference Figure 1 In the cloud platform cluster environment, in a container cloud cluster based on Kubernetes, if you need to access a service, you need to access it through the virtual IP and port provided by the Service resource. Then, in the cluster, it is forwarded to the corresponding Pod according to the specified forwarding rules, and the association between the Service and the Pod depends on the label specified in the Service for maintenance. Therefore, the Pod is the one who is really responsible for providing work in the Kubernetes cluster.

[0022] However, in daily work, it is often necessary to log in to the service environment to check logs or debug programs. When checking logs or debugging programs, users will inevitably perform dangerous operations due to misoperation, causing service crashes or even damage to company assets. Therefore, an operation audit mechanism is needed to ensure that all user operations are recorded for easy traceability afterwards.

[0023] Reference Figure 2 Currently, the user operation audit capability under the virtual machine mode is very mature with the help of the operating system's own operation audit capability. However, in the container cloud cluster scenario, since the Pod cannot be seen directly on the node, in this case, logging into the Pod terminal mainly establishes a WebSocket-like connection with the Pod through the container runtime, and then various interactions between the user and the Pod are transmitted in this link.

[0024] Reference Figure 3 ,The difference between the virtual machine mode and the Pod mode is that the user input cannot be detected at the outer layer.

[0025] For the problems in the prior art, refer to Figure 4 , a Pod terminal behavior audit method based on kubernetes in this embodiment adopts the following technical solutions, including: S1. Establish a login terminal request on the local client to connect to the target Pod, and the login terminal request is sent to the Kube-Apiserver service via the HTTP protocol; The URL format of the Kube-Apiserver service is: http[s]: / / ${api_server} / ns / ${pod_namespace} / pods / ${pod_name} / exec?stdin=true&stdout=true&stderr=true&tty=true&container=${container_name}&command=sh.

[0026] The URL format between the Kube-Apiserver service and Kubelet is: http[s]: / / ${node_ip}:${kubelet_port} / exec / ${pod_namespace} / ${pod_name} / ${container_name``.

[0027] S2. Get the node running the target Pod and the address and port of Kubelet through the Kube-Apiserver service; The obtaining of the node running the target Pod and the address and port of the Kubelet includes establishing a streaming proxy connection between the node running the target Pod and the address and port of the Kubelet; After the streaming proxy connection is established, Kubelet receives the request of the Kube-Apiserver service and forwards it to the container runtime. Kubelet will continue to proxy the I / O stream between the API service and the container runtime for data transmission and interaction.

[0028] S3. The Kube-Apiserver service request is forwarded to the container runtime through Kubelet, and a process is created and executed in the container namespace and cgroup in the target Pod; S4. The target Pod establishes a websocket connection with the client and creates an audit-controller service. The audit-controller service pushes the client input content to Kafka. The specific steps are as follows: the controller of the audit-controller service intercepts the response of the Pod to establish a websocket connection with the client, the target Pod directly connects to the audit-controller service, the audit-controller service creates a new websocket connection with the client, the audit-controller service obtains the client input content, and pushes the client input content to kafka through the audit-controller service, which can avoid the blocking and performance problems caused by directly writing a large amount of data to the database.

[0029] The kafka is set with a threshold time. If the threshold time is exceeded, the push fails and the input content is stored in the controller. At the same time, kafka starts a separate process to listen to the information of push failure and restarts the push until the push succeeds.

[0030] Setting the default timeout time and a separate process to monitor unsuccessful push messages and try to restart the push ensures data reliability and integrity and prevents data loss due to push failure. Through the intermediate proxy, the client and server are unaware of the existence of the audit-controller and do not affect the communication between the client and the server. Users can enjoy a smooth operating experience when using the Pod terminal and will not experience obvious delays or freezes due to the introduction of the audit mechanism.

[0031] S5. Create an audit-record-sync service. The audit-record-sync service consumes messages in the kafka message queue and messages pushed by the audit-controller service, and synchronously writes the messages into the database to achieve persistent storage of client operation records.

[0032] audit-record-sync is responsible for consuming Kafka messages. By pushing the client input content to Kafka and synchronously writing it to the database, the client operation records are persistently stored for easy traceability. The overall solution is reasonably designed, which realizes comprehensive auditing and recording of Pod terminal user operation behaviors, and improves the security and reliability of the system.

[0033] Reference Figure 5In the kubernetes cluster, the audit-controller service and the audit-record-sync service are implemented. The audit-controller service is responsible for establishing a websocket link between the target Pod and the client. The audit-controller service is first used, and then the service creates a websocket link with the client. Although there is an extra layer in the middle, the client and the server are not aware of the intermediate proxy, which does not affect the communication between the client and the server. The intermediate proxy can be understood as a transparent transmission module. In this way, audit-controller can obtain the client input content. After obtaining the input content, it can send the information to the kafka message middleware. This is to prevent a large number of linked Pods. Direct writing to the database will cause blockage, which will affect the client experience. After audit-controller is responsible for writing to kafka, another service audit-record-sync is responsible for consuming kafka messages and finally writing them to the database synchronously. Through the collaborative work of audit-controller and audit-record-sync services, the interaction information between the client and the target Pod can be fully recorded, including the client's input content and the target Pod's response, which helps enterprises trace and analyze user operations, discover potential security risks and problems in a timely manner, and implement auditing of operations performed by users logging into the Pod terminal in the container cloud cluster.

[0034] Example 2 This embodiment provides a Pod terminal behavior audit system based on kubernetes, including: The request connection module is configured to establish a login terminal request to connect to the target Pod on the local client, and the login terminal request is sent to the Kube-Apiserver service via the HTTP protocol; The port acquisition module is configured to obtain the node running the target Pod and the address and port of Kubelet through the Kube-Apiserver service; The resource management module is configured to forward the request of the Kube-Apiserver service to the container runtime through Kubelet, and create and execute the process in the container namespace and cgroup in the target Pod; The data processing module is configured to establish a websocket connection between the target Pod and the client, create an audit-controller service, and the audit-controller service pushes the client input content to Kafka; The data synchronization module is configured to create an audit-record-sync service, which consumes messages in the kafka message queue and messages pushed by the audit-controller service, and synchronously writes the messages into the database to achieve persistent storage of client operation records.

[0035] A computer-readable storage medium stores a plurality of instructions, wherein the instructions are suitable for being loaded and executed by a processor of a terminal device for a Kubernetes-based Pod terminal behavior audit method.

[0036] A terminal device includes a processor and a computer-readable storage medium, wherein the processor is used to implement various instructions; the computer-readable storage medium is used to store multiple instructions, wherein the instructions are suitable for being loaded and executed by the processor to implement a Pod terminal behavior audit method based on kubernetes.

[0037] The above are all preferred embodiments of the present invention, and are not intended to limit the protection scope of the present invention. Therefore, any equivalent changes made based on the structure, shape, and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A Pod terminal behavior audit method based on kubernetes, characterized in that: The following steps are involved: S1. Establish a login terminal request on the local client to connect to the target Pod, and the login terminal request is sent to the Kube-Apiserver service via the HTTP protocol; S2. Get the node running the target Pod and the address and port of Kubelet through the Kube-Apiserver service; S3. The Kube-Apiserver service request is forwarded to the container runtime through Kubelet, and a process is created and executed in the container namespace and cgroup in the target Pod; S4. The target Pod establishes a websocket connection with the client and creates an audit-controller service. The audit-controller service pushes the client input content to Kafka. S5. Create an audit-record-sync service. The audit-record-sync service consumes messages in the kafka message queue and messages pushed by the audit-controller service, and synchronously writes the messages into the database to achieve persistent storage of client operation records.

2. According to a Kubernetes-based Pod terminal behavior audit method according to claim 1, it is characterized in that: The URL format of the Kube-Apiserver service is: http[s]: / / ${api_server} / ns / ${pod_namespace} / pods / ${pod_name} / exec?stdin=true&stdout=true&stderr=true&tty=true&container=${container_name}&command=sh.

3. According to a Kubernetes-based Pod terminal behavior audit method according to claim 1, it is characterized in that: The URL format between the Kube-Apiserver service and Kubelet is: http[s]: / / ${node_ip}:${kubelet_port} / exec / ${pod_namespace} / ${pod_name} / ${container_name``.

4. According to a Kubernetes-based Pod terminal behavior audit method according to claim 1, it is characterized in that: The obtaining of the node running the target Pod and the address and port of the Kubelet includes establishing a streaming proxy connection between the node running the target Pod and the address and port of the Kubelet.

5. According to a Kubernetes-based Pod terminal behavior audit method according to claim 4, it is characterized in that: After the streaming proxy connection is established, Kubelet receives the request of the Kube-Apiserver service and forwards it to the container runtime. Kubelet will continue to proxy the I / O stream between the API service and the container runtime for data transmission and interaction.

6. According to a Kubernetes-based Pod terminal behavior audit method according to claim 1, it is characterized in that: The specific steps of the audit-controller service pushing the client input content to Kafka are as follows: the controller of the audit-controller service intercepts the response of the Pod to establish a websocket connection with the client, the target Pod directly connects to the audit-controller service, the audit-controller service creates a new websocket connection with the client, the audit-controller service obtains the client input content, and pushes the client input content to Kafka through the audit-controller service.

7. According to a Kubernetes-based Pod terminal behavior audit method according to claim 1, it is characterized in that: The kafka is set with a threshold time. If the threshold time is exceeded, the push fails and the input content is stored in the controller. At the same time, kafka starts a separate process to listen to the information of push failure and restarts the push until the push succeeds.

8. A Pod terminal behavior audit system based on kubernetes, characterized in that: include: The request connection module is configured to establish a login terminal request to connect to the target Pod on the local client, and the login terminal request is sent to the Kube-Apiserver service via the HTTP protocol; The port acquisition module is configured to obtain the node running the target Pod and the address and port of Kubelet through the Kube-Apiserver service; The resource management module is configured to forward the request of the Kube-Apiserver service to the container runtime through Kubelet, and create and execute the process in the container namespace and cgroup in the target Pod; The data processing module is configured to establish a websocket connection between the target Pod and the client, create an audit-controller service, and the audit-controller service pushes the client input content to Kafka; The data synchronization module is configured to create an audit-record-sync service, which consumes messages in the kafka message queue and messages pushed by the audit-controller service, and synchronously writes the messages into the database to achieve persistent storage of client operation records.

9. A computer-readable storage medium storing a plurality of instructions, characterized in that: The instructions are suitable for being loaded by a processor of a terminal device and executing a Pod terminal behavior audit method based on Kubernetes as described in claim 1.

10. A terminal device, comprising a processor and a computer-readable storage medium, wherein the processor is used to implement each instruction; and the computer-readable storage medium is used to store multiple instructions, characterized in that: The instructions are suitable for being loaded by a processor and executing a Pod terminal behavior audit method based on kubernetes as described in claim 1.

Images