Micro-service dynamic network flow control method based on multi-factor authentication

Abstract

The invention discloses a micro-service dynamic network flow control method based on multi-factor authentication, and belongs to the field of containerized network security management. Comprising the following steps of: prohibiting flow forwarding among all pods except a multi-factor authentication service pod; the multi-factor authentication service pod receives and verifies the access request; the authentication result is converted into a NetworkPolicy rule, and the NetworkPolicy rule is obtained; calling a kube-api-server to update the NetworkPolicy rule, and calling a Kube-api-server to update the NetworkPolicy rule; the method comprises the following steps of: automatically calling a kube-api-server to remove a Network Policy rule after a timer expires; and finally, automatically calling the kube-api-server to remove the Network Policy rule. According to the method, an attacker can be effectively prevented from breaking through container isolation and transversely moving to diffuse threats by using kernel vulnerabilities, and the security of the whole cloud environment is improved.

Description

Technical Field

[0001] This invention belongs to the field of containerized network security management, specifically involving a microservice dynamic network traffic control method based on multi-factor authentication in a Kubernetes cluster, and in particular a security mechanism that triggers real-time updates of network policies through multi-factor authentication. Background Technology

[0002] In the cloud-native era, microservice architecture emerged to address the overly centralized system development and iteration patterns derived from monolithic application models. Microservice architecture breaks down a backend monolithic application into multiple loosely coupled sub-applications, each responsible for a set of sub-functions. These sub-applications are called "microservices," and multiple "microservices" together form a physically independent but logically complete distributed microservice system. These microservices are relatively independent, improving overall iteration efficiency by decoupling development, testing, and deployment processes.

[0003] Microservice architectures primarily rely on containerized deployments, and Kubernetes is currently a mainstream container orchestration and management platform that provides the runtime environment and technical support for microservice architectures. However, in Kubernetes, each microservice is hosted by pod resources. By default, the Kubernetes cluster network has no network restrictions, and pods can communicate with any other pod. This increases east-west traffic, making it easy for attackers to exploit kernel vulnerabilities to breach container isolation, spread threats laterally, and impact the security of the entire cloud environment. Summary of the Invention

[0004] In existing Kubernetes-based microservice architectures, insufficient traffic control between microservices makes it easy for attackers to exploit kernel vulnerabilities to bypass container isolation, move laterally to spread threats, and affect the security of the entire cloud environment. Furthermore, existing network isolation policies cannot be dynamically changed.

[0005] The technical solution adopted in this invention is as follows:

[0006] A microservice dynamic network traffic control method based on multi-factor authentication includes the following steps:

[0007] Step 1: When building various microservices, add different labels to them, and use PodSelector to filter labels through NetworkPolicy rules in Kubernetes, prohibiting traffic forwarding between all pods except for the multi-factor authentication service pod;

[0008] Step 2: The multi-factor authentication service pod receives the access request from the requesting pod and determines whether the requester is allowed to access. If the request is allowed, proceed to step 3.

[0009] Step 3: The multi-factor authentication service pod verifies the validity and legitimacy of the requester's identity. After successful verification, it records the requesting Pod tag and the target Pod tag, and converts the recorded information into NetworkPolicy rules.

[0010] Step 4: The multi-factor authentication service pod calls kube-api-server to update the NetworkPolicy rules. After the update, the requesting pod can access the target pod normally.

[0011] Step 5: After the NetworkPolicy rule is updated, start a timer. When the timer expires, call kube-api-server to remove the NetworkPolicy rule.

[0012] Furthermore, the access request in step 2 includes specific identification information of the request source, which may be PodIP, PodName, PodUID, or a specific tag value of the Pod carrying the request.

[0013] Compared with the prior art, the present invention has the following advantages:

[0014] 1. This invention addresses the critical issue of dynamic secure access between microservices in a Kubernetes-based microservice architecture, preventing attackers from exploiting kernel vulnerabilities to breach container isolation, move laterally, and spread threats, thereby impacting the security of the entire cloud environment.

[0015] 2. Based on the existing NetworkPolicy in Kubernetes, this invention can achieve precise temporary traffic control at the Pod level without modifying CNI or node configuration, or adopting a Service Mesh architecture, and can achieve this based on multi-factor authentication service. Attached Figure Description

[0016] Figure 1 This is a flowchart of the microservice dynamic network traffic control method based on multi-factor authentication of the present invention. Detailed Implementation

[0017] The present invention will now be further described with reference to the accompanying drawings.

[0018] A microservice dynamic network traffic control method based on multi-factor authentication includes the following steps:

[0019] Step 1: When building various microservices, add different labels to them, and use PodSelector to filter labels through NetworkPolicy rules in Kubernetes, prohibiting traffic forwarding between all pods except for the multi-factor authentication service pod;

[0020] Step 2: The multi-factor authentication service pod receives the access request from the requesting pod. The access request includes specific identification information of the request source, such as PodIP, PodName, Pod UID, or a specific tag value of the pod carrying the request. The multi-factor authentication service determines whether the requester is allowed to request access according to the predefined policy. If the request is allowed, step 3 is executed.

[0021] Step 3: The multi-factor authentication service pod verifies the validity and legitimacy of the requester's identity. After successful verification, it records the requesting Pod tag and the target Pod tag, and converts the recorded information into NetworkPolicy rules.

[0022] Step 4: Configure a high-privilege Kubernetes Service Account for the multi-factor authentication service pod. The multi-factor authentication service pod calls kube-api-server to update the NetworkPolicy rules. After the update, the requesting pod can access the target pod normally.

[0023] Step 5: After the NetworkPolicy rule is updated, start a timer. When the timer expires, call kube-api-server to remove the NetworkPolicy rule.

[0024] Here is a more specific example:

[0025] The process of a microservice dynamic network traffic control method based on multi-factor authentication is as follows: Figure 1 As shown, on-demand traffic control is achieved through authentication and authorization and NetworkPolicy.

[0026] 1. In the initial state, a strict NetworkPolicy is applied to the Kubernetes cluster, prohibiting traffic forwarding between all Pods (except for the multi-factor authentication service Pod). At this time, the NetworkPolicy blocks the requesting Pod from sending an access request to the target Pod.

[0027] 2. The requesting Pod initiates an authentication request to the multi-factor authentication service pod, carrying information such as its own PodIP, PodName, PodUID, or specific tag values ​​of the Pod carrying the request.

[0028] 3. When the multi-factor authentication service pod receives an authentication request, the authentication engine calls the SQLite database to verify the validity and legitimacy of the requester's identity.

[0029] 4. After successful verification, the requester's identification information is recorded securely and completely. The policy engine then generates precise NetworkPolicy rules, and in the ingress rule of the target pod, podSelector is set to app=src.

[0030] 5. The multi-factor authentication service pod calls the Kube-api-server via API to pass the NetworkPolicy rules that need to be updated.

[0031] 6. Execute the UPDATE operation to modify the NetworkPolicy and update the ingress rules that allow the target pod to request other pods.

[0032] 7. With the combined action of components such as Kube-api-server, etcd, kube-proxy on each node, and CNI, NetworkPolicy rules take effect.

[0033] 8. The requesting pod sends another access request to the target pod and successfully receives a response.

[0034] 9. When a multi-factor authentication service pod updates a NetworkPolicy rule, a TTL timer is triggered. After the timer expires, the API is automatically called to remove the NetworkPolicy rule.

Claims

1. A microservice dynamic network traffic control method based on multi-factor authentication, characterized in that, Includes the following steps: Step 1: When building various microservices, add different labels to them, and use PodSelector to filter labels through NetworkPolicy rules in Kubernetes, prohibiting traffic forwarding between all pods except for the multi-factor authentication service pod; Step 2: The multi-factor authentication service pod receives the access request from the requesting pod and determines whether the requester is allowed to access. If the request is allowed, proceed to step 3. Step 3: The multi-factor authentication service pod verifies the validity and legitimacy of the requester's identity. After successful verification, it records the requesting Pod tag and the target Pod tag, and converts the recorded information into NetworkPolicy rules. Step 4: The multi-factor authentication service pod calls kube-api-server to update the NetworkPolicy rules. After the update, the requesting pod can access the target pod normally. Step 5: After the NetworkPolicy rule is updated, start a timer. When the timer expires, call kube-api-server to remove the NetworkPolicy rule.

2. The microservice dynamic network traffic control method based on multi-factor authentication according to claim 1, characterized in that, The access request in step 2 includes specific identification information of the request source, which may be PodIP, PodName, PodUID, or a specific tag value of the Pod carrying the request.

Images