Public network access authority management method and related device
By dynamically allocating and revoking public network access permissions, public network access permissions are configured for Pods in the Kubernetes cluster, solving the problem that Pods cannot directly access the public network, improving security and management efficiency, and preventing resource leaks.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING QIYI CENTURY SCI & TECH CO LTD
- Filing Date
- 2026-02-05
- Publication Date
- 2026-05-01
AI Technical Summary
In existing technologies, Pods in Kubernetes clusters cannot directly access the public network, resulting in insufficient security. Furthermore, the lack of fine-grained control over public network access permissions and consistency in lifecycle management can easily lead to resource leaks.
By obtaining public network access policy information, public network access permissions are dynamically allocated to target Pods. Access permissions are configured when the Pod starts using routing rules and revoked when the Pod is deleted. Public network access is achieved by combining SNAT clusters and Layer 4 proxies, and public network access permissions of Pods are dynamically managed.
This approach binds public network access permissions to the Pod lifecycle, improving the security and efficiency of public network access permission management for Kubernetes clusters, preventing resource leaks, and simplifying public IP address management.
Smart Images
Figure CN121967041A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud computing technology, specifically to a method and related apparatus for managing public network access permissions. Background Technology
[0002] Kubernetes has powerful container orchestration capabilities and has become the mainstream container orchestration platform. However, its default network model is mainly designed for internal communication between services. Pods in the cluster are interconnected through the cluster network by default, but cannot directly access the public network.
[0003] In many practical applications, such as when a Pod needs to obtain data from external services (e.g., third-party REST APIs, databases, etc.) via public APIs; when a Pod needs to access the external network to download dependency packages, images, or system updates; or when a Pod needs to communicate with external systems via TCP / UDP, a Kubernetes cluster needs to provide an efficient, secure, and flexible way to support Pods' public network access.
[0004] In related technologies, configuring a NAT Gateway to perform source network address translation (SNAT) on Pod traffic, assigning a public IP address to each Pod, or using a transparent proxy can solve the address exposure and routing problems when Pods access the external network of the cluster.
[0005] However, the above methods are usually static configurations that can lead to insufficient security. Summary of the Invention
[0006] In view of this, this application provides a public network access permission management method and related apparatus, which dynamically allocates public network access permissions to target Pods in a Kubernetes cluster based on public network access policy information, thereby binding public network access permissions to the lifecycle of Pods, thus improving the fine-grained management capability of public network access and effectively enhancing the security of the public network access permission management method of Kubernetes cluster.
[0007] To solve the above problems, the technical solution provided in this application is as follows: On the one hand, this application provides a method for managing public network access permissions, the method comprising: Obtain public network access policy information, which includes routing rules corresponding to the target Pod in the Kubernetes cluster. The routing rules are used to define the next-hop IP address of the target Pod, and the server corresponding to the next-hop IP address is used to perform source address translation (SNAT) and packet forwarding for the target Pod. When the target Pod starts, the routing rules are configured for the target Pod by initializing the container based on the public network access policy information; When the target Pod sends a public network access request, based on the routing rules, the packet corresponding to the target Pod is sent to the server corresponding to the next-hop IP address; When the target Pod is deleted, its public network access permissions are revoked.
[0008] In one possible implementation, when the target Pod sends a public network access request, sending the packet corresponding to the target Pod to the server corresponding to the next-hop IP address based on the routing rules includes: When the target Pod sends a public network access request, obtain the message corresponding to the public network access request; Based on the IP address corresponding to the target Pod in the message, a search is performed in the public network access address whitelist. If the IP address is in the public network access address whitelist, the message corresponding to the target Pod is sent to the server corresponding to the next-hop IP address based on the routing rules. Otherwise, the public network access request is rejected. The public network access address whitelist is used to dynamically maintain the IP addresses that are allowed to access the public network.
[0009] In one possible implementation, the server is one server in an SNAT cluster, which is a cluster of multiple servers used for SNAT. After sending the packet corresponding to the target Pod to the server corresponding to the next-hop IP address, the method further includes: If the server corresponding to the next-hop IP address fails, the packet corresponding to the target Pod will be sent to the first server in the SNAT cluster. The first server is a server in the SNAT cluster other than the server corresponding to the next-hop IP address.
[0010] In one possible implementation, the server provides public network access services for multiple Pods in the Kubernetes cluster.
[0011] In one possible implementation, configuring the routing rules for the target Pod based on the public network access policy information by initializing the container when the target Pod starts includes: When the target Pod starts, the API Server pushes the first event stream corresponding to the target Pod's startup to the Operator; The Operator receives the first event stream, generates configuration parameters for initializing the container based on the routing rules corresponding to the target Pod, and generates Finalizer parameters. The Finalizer parameters are used to indicate control parameters for deleting the public network access permissions of the target Pod before it is deleted. The configuration parameters are loaded through the initialization container.
[0012] In one possible implementation, when the target Pod is deleted, revoking the target Pod's public network access includes: In response to the deletion operation of the target Pod, the second event stream corresponding to the deletion of the target Pod is pushed to the Operator through the API Server; The Operator receives the second event stream, deletes the iptables rule corresponding to the target Pod, and removes the Finalizer parameter. The iptables rule is generated based on the configuration parameters. If the API Server detects that the Finalizer parameter does not exist, it deletes the resource information corresponding to the target Pod.
[0013] In another aspect, this application provides a public network access permission management device, which includes an acquisition unit, a configuration unit, a sending unit, and a revocation unit: The acquisition unit is used to acquire public network access policy information, which includes routing rules corresponding to the target Pod in the Kubernetes cluster. The routing rules are used to define the next-hop IP address of the target Pod, and the server corresponding to the next-hop IP address is used to perform source address translation (SNAT) and packet forwarding on the target Pod. The configuration unit is used to configure the routing rules for the target Pod by initializing the container based on the public network access policy information when the target Pod starts. The sending unit is used to send the packet corresponding to the target Pod to the server corresponding to the next-hop IP address based on the routing rules when the target Pod sends a public network access request. The recycling unit is used to reclaim the public network access permissions of the target Pod when the target Pod is deleted.
[0014] In one possible implementation, the sending unit is used for: When the target Pod sends a public network access request, obtain the request message corresponding to the public network access request; Based on the IP address corresponding to the target Pod in the request message, a search is performed in the public network access address whitelist. If the IP address is in the public network access address whitelist, the message corresponding to the target Pod is sent to the server corresponding to the next-hop IP address based on the routing rules. Otherwise, the public network access request is rejected. The public network access address whitelist is used to dynamically maintain the IP addresses that are allowed to access the public network.
[0015] In one possible implementation, the server is one server in an SNAT cluster, which is a cluster consisting of multiple servers used for SNAT, and the sending unit is further configured to: If the server corresponding to the next-hop IP address fails, the packet corresponding to the target Pod will be sent to the first server in the SNAT cluster. The first server is a server in the SNAT cluster other than the server corresponding to the next-hop IP address.
[0016] In one possible implementation, the server provides public network access services for multiple Pods in the Kubernetes cluster.
[0017] In one possible implementation, the configuration unit is used for: When the target Pod starts, the API Server pushes the event stream corresponding to the target Pod's startup to the Operator; The Operator generates configuration parameters for initializing the container based on the routing rules corresponding to the target Pod, and generates Finalizer parameters. The Finalizer parameters are used to indicate control parameters for deleting the public network access permissions of the target Pod before it is deleted. The configuration parameters are loaded through the initialization container.
[0018] In one possible implementation, the recycling unit is used for: In response to the deletion operation of the target Pod, the deletion event of the target Pod is pushed to the Operator through the API Server; The Operator deletes the iptables rules corresponding to the target Pod and removes the Finalizer parameter. The iptables rules are generated based on the configuration parameters. If the API Server detects that the Finalizer parameter does not exist, it deletes the resource information corresponding to the target Pod.
[0019] In another aspect, this application provides a computer device, which includes a processor and a memory: The memory is used to store computer programs; The processor is configured to execute the method described in any of the above-described embodiments according to the computer program.
[0020] In another aspect, this application provides a computer-readable storage medium for storing a computer program that, when executed by a computer device, implements the method described in any of the above-mentioned embodiments.
[0021] In another aspect, this application provides a computer program product including a computer program, which, when run on a computer device, causes the computer device to perform any of the methods described above.
[0022] As can be seen from the above technical solution, this solution first obtains public network access policy information, including the routing rules corresponding to the target Pod in the Kubernetes cluster. The routing rules are used to define the next-hop IP address of the target Pod. The server node corresponding to the next-hop IP address is used to perform source address translation (SNAT) and packet forwarding on the target Pod. That is, the routing rules set a corresponding public network exit for the target Pod. Then, when the target Pod starts, based on the public network access policy information, the container is initialized to configure the corresponding routing rules for the target Pod, enabling it to have public network access permissions. After that, when the target Pod sends a public network access request, based on the routing rules, the packet corresponding to the target Pod is sent to the server corresponding to the next-hop address. After SNAT, the packet is forwarded to the public network server. Finally, when the target Pod is deleted, the public network access permissions of the target Pod are revoked to avoid resource leakage caused by residual permissions. Therefore, the routing rules can be configured to route the traffic of the target Pod through a server for SNAT and packet forwarding, specify a public network exit for the target Pod, configure public network access permissions for the target Pod, and bind public network access permissions to the lifecycle of the target Pod, thereby realizing the dynamic allocation and reclamation of public network access permissions. In this way, the security of public network access permission management in Kubernetes clusters is effectively improved through fine-grained management of public network access permissions at the Pod level. Attached Figure Description
[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0024] Figure 1 A flowchart illustrating a public network access permission management method provided in this application embodiment; Figure 2 A flowchart illustrating a method for managing public network access permissions provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating a permission request and configuration provided in an embodiment of this application; Figure 4 This is a schematic diagram of Pod network injection provided in an embodiment of this application; Figure 5 A schematic diagram illustrating message forwarding provided in an embodiment of this application; Figure 6 This is a schematic diagram of a public network access permission management device provided in an embodiment of this application. Detailed Implementation
[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0026] As described in the background section, there are several main technical solutions for enabling Pods to access the public network within a Kubernetes cluster.
[0027] (1) NAT gateway based method: Configure a NAT Gateway (or LoadBalancer) to send the traffic of internal Pods to the public network after SNAT.
[0028] Its disadvantages are that it often requires custom Container Network Interface (CNI) implementation, which is not friendly to heterogeneous cluster environments, and the NAT Gateway is a single point of failure, which will cause public network access to be interrupted if the exit point fails.
[0029] (2) Assign a public IP address to the Pod: Assign an independent public IP address to each Pod that needs to access the public network, so that it can communicate directly over the public network.
[0030] Its disadvantages are that allocating an independent public IP address to each Pod consumes a lot of public IPs, which is costly, and the Pod lifecycle is relatively short. Frequent allocation and recycling of public IPs also increases management complexity.
[0031] (3) Transparent proxy method: Deploy a transparent proxy Pod so that all public network traffic is forwarded through the proxy.
[0032] Its disadvantages are that the introduction of transparent proxies increases complexity and has a certain impact on performance.
[0033] Therefore, the relevant technology has the following drawbacks: (1) Complex management of public network exit: Most existing solutions are one-time static configurations that do not support dynamic configuration and reclamation of permissions. When a Pod is deleted, its residual permissions can easily cause security problems.
[0034] (2) Insufficient security and access control: Unable to manage the public network access permissions and scope of each Pod in a fine-grained manner.
[0035] (3) Lifecycle management issues: Public network access configuration is not consistent with the Pod lifecycle, which can easily lead to resource leaks (such as residual or unavailable permissions).
[0036] To address the aforementioned issues, this application provides a method for managing public network access permissions. First, public network access policy information is obtained, including routing rules corresponding to the target Pod in the Kubernetes cluster. These routing rules define the next-hop IP address of the target Pod, and the server node corresponding to this next-hop IP address performs source address translation (SNAT) and packet forwarding on the target Pod. In other words, the routing rules set up a corresponding public network exit for the target Pod. Then, when the target Pod starts, based on the public network access policy information, the container is initialized to configure the corresponding routing rules for the target Pod, granting it public network access permissions. Subsequently, when the target Pod sends a public network access request, the packet corresponding to the target Pod is sent to the server corresponding to the next-hop address based on the routing rules. After SNAT, the packet is forwarded to the public network server. Finally, when the target Pod is deleted, its public network access permissions are revoked to prevent resource leaks caused by residual permissions. Therefore, the routing rules can be configured to route the traffic of the target Pod through a server for SNAT and packet forwarding, specify a public network exit for the target Pod, configure public network access permissions for the target Pod, and bind public network access permissions to the lifecycle of the target Pod, thereby realizing the dynamic allocation and reclamation of public network access permissions. In this way, the security of public network access permission management in Kubernetes clusters is effectively improved through fine-grained management of public network access permissions at the Pod level.
[0037] The solutions provided in this application relate to the field of cloud computing technology, and are specifically illustrated through the following embodiments.
[0038] See Figure 1 The diagram shown is a flowchart of a public network access permission management method provided in an embodiment of this application. In this embodiment, it can be executed by a computer device.
[0039] S101: Obtain public network access policy information.
[0040] Public network access policy information includes routing rules corresponding to the target Pod in the Kubernetes cluster. These routing rules determine the next-hop IP address for the Pod's traffic. To enable communication between the Pod and a public server, the Pod's traffic needs to be forwarded to a server with a public IP address. In this embodiment, the server corresponding to the next-hop address is used for source address translation and packet forwarding for the target Pod; that is, the server corresponding to the next-hop address serves as the public network exit point for the target Pod.
[0041] For example, public network access policy information can be determined based on the application information submitted by the user when submitting a public network access request. This application information might include business objects in the Kubernetes cluster and public network access requirement information. The business objects could include the target Pod related to the public network access request, and the public network access requirement information could include the bandwidth limits, egress ISP, access protocol, communication duration, target IP address for communication with the target Pod, and port number for the target Pod. By using the business objects in the application information, the corresponding target Pod can be located, and then a server with SANT functionality can be determined as the next-hop address for the target Pod.
[0042] Public network access policy information may also include access permission information for the target Pod, but this application embodiment does not specifically limit this. Access permission information is used to identify external resources or conditions that are allowed to communicate with the Pod, such as the range of IP addresses, bandwidth limits, and protocol types.
[0043] Based on the routing rules and access permission information corresponding to the target Pod, the specific access permissions of the target Pod can also be adjusted in combination with the resource status of the target Pod in the Kubernetes cluster. For example, if the target Pod has a high resource burden, the bandwidth for public network access can be further restricted.
[0044] S102: When the target Pod starts, based on the public network access policy information, the container is initialized to configure the corresponding routing rules for the target Pod.
[0045] After a Pod is created in a Kubernetes cluster, the scheduler determines which node the Pod will run on based on the cluster's resource availability. Once the target Pod's running node is determined, Kubelet creates an initialization container for the target Pod and starts the initialization container according to the target Pod's configuration file to complete the Pod's configuration.
[0046] In this embodiment of the application, when the target Pod starts, the routing rules and access permission information corresponding to the target Pod are obtained based on the public network access policy information, and the corresponding routing rules and access permission information are configured for the target Pod by initializing the container.
[0047] Therefore, without modifying CNI or complex configurations, public network access permissions can be applied for and configured through the Kubernetes cluster.
[0048] S103: When the target Pod sends a public network access request, based on the routing rules, the packet corresponding to the target Pod is sent to the server corresponding to the next hop IP address.
[0049] For example, when the target Pod sends a public network access request, the next-hop IP address, the IP address and port of the public network server to which it communicates are first determined by the routing rules and access permission information. Then, the IP address of the target Pod is source-address translated by the server corresponding to the next-hop IP address. The server then translates the IP address carried in the packet into a public IP address and sends it to the target port of the public network server.
[0050] The server then receives the response from the public server, performs Destination Network Address Translation (DNAT) on it, and then sends the response message to the target Pod. Simultaneously, during this process, the server controls the amount of traffic during communication using the traffic range specified in the access permission information. Thus, the server enables public network access to the target Pod.
[0051] In one possible implementation, the server is one server in an SNAT cluster, which is a cluster of multiple servers used for SNAT. After sending the packet corresponding to the target Pod to the server corresponding to the next-hop IP address, the method further includes: If the server corresponding to the next-hop IP address fails, the packet corresponding to the target Pod will be sent to the first server in the SNAT cluster.
[0052] The first server is one of the servers in the SNAT cluster other than the server corresponding to the next-hop IP address.
[0053] An SNAT cluster is pre-built to provide SNAT services, and redundancy is configured for the SNAT cluster. If one of the servers fails, the SNAT service on that server is switched to another server to continue providing SNAT services.
[0054] For example, when the target Pod's packet is sent to the server corresponding to the next-hop address, if the server corresponding to the next-hop address experiences a failure and returns a failure message to the target Pod, the target Pod will resend the packet to the first server so that the first server can be used as a public network exit and SNAT and packet forwarding can be performed through the first server.
[0055] Therefore, through redundancy mechanisms, dynamic public network egress configuration and fault-to-connection capabilities can be provided, effectively improving the reliability of public network access.
[0056] In one possible implementation, the server provides public network access services to multiple Pods in the Kubernetes cluster.
[0057] This server can be a shared server, performing SNAT and forwarding messages sent by multiple Pods when requesting public network access.
[0058] This eliminates the need to allocate a separate public IP address for each Pod, effectively reducing the complexity of allocating and managing public IP addresses for each Pod.
[0059] In one possible implementation, the server performs SNAT and packet forwarding on the target Pod through a layer 4 proxy.
[0060] A Layer 4 proxy refers to a server that operates at the transport layer in the TCP / IP four-layer model. This means that the server forwards messages according to the transport layer protocols and supports message transmission with Ping, TCP, UDP, and other common application layer protocols (HTTP, DNS, etc.).
[0061] After receiving a message from the target Pod, the server modifies the IP address in the message to its own IP address, that is, converts it to a public IP address, and then forwards the message to the target public server.
[0062] Using a four-layer proxy can handle a large number of requests with low latency, making it suitable for large-scale, high-concurrency network environments and effectively improving the efficiency of Kubernetes clusters accessing the public network.
[0063] S104: When the target Pod is deleted, revoke the target Pod's public network access permissions.
[0064] Add a Finalizer to the initialization container of the target Pod to ensure that when the target Pod is deleted, the relevant configuration information is automatically cleared and the bandwidth or permissions occupied by the Pod are released, thereby reclaiming the public network access permissions of the target Pod.
[0065] In one possible implementation, the method further includes: Monitor the working status of the target Pod using an Operator.
[0066] Operator is an extension software for Kubernetes clusters that allows you to monitor the lifecycle of Pods through custom controllers, including events such as creation, startup, destruction, and deletion.
[0067] This allows for timely implementation of dynamic configuration and management of public network access for target Pods upon detecting changes in their state, effectively improving the efficiency and security of Kubernetes clusters accessing the public network.
[0068] Therefore, by setting routing rules, the traffic of the target Pod can be routed through a server for SNAT and packet forwarding, specifying a public network exit for the target Pod, configuring public network access permissions for the target Pod, and binding public network access permissions to the lifecycle of the target Pod, realizing dynamic allocation and reclamation of public network access permissions. In this way, the security of public network access permission management in Kubernetes clusters is effectively improved through fine-grained management of public network access permissions at the Pod level.
[0069] In a Kubernetes cluster, multiple Pods that are in a working state may initiate different public network access requests. In one possible implementation, S103 includes: A1: When the target Pod sends a public network access request, obtain the request message corresponding to the public network access request.
[0070] A2: Based on the IP address corresponding to the target Pod in the request message, search in the public network access address whitelist. If the IP address is in the public network access address whitelist, send the message corresponding to the target Pod to the server corresponding to the next hop IP address according to the routing rules; otherwise, reject the public network access request.
[0071] The public network access address whitelist is used to dynamically maintain the IP addresses allowed for public network access. This application embodiment does not impose specific restrictions on this; for example, it can be an ipset set. If the IP address corresponding to a Pod is stored in the ipset, it means that the Pod can be accessed publicly; if the IP address corresponding to a Pod is not stored in the ipset set, it means that it is not allowed to access the public network.
[0072] For example, when a target Pod sends a public network access request, the corresponding packet is obtained. By parsing the packet, the IP address of the target Pod can be determined. Then, the system checks if the IP address is stored in the public network access address whitelist. If the IP address is found, the packet is sent to the server corresponding to the next-hop address based on the routing rules and access permission information of the target Pod. The server then provides public network access service to the target Pod. If no matching IP address is found, the public network access request of the target Pod is rejected.
[0073] Therefore, by using a public network access address whitelist, it is possible to quickly determine whether a target Pod is allowed to access the public network. When handling a large number of public network access requests from Pods, updating the public network access address whitelist can track and record the public network access permissions of each Pod, thereby improving the management efficiency of public network access in the Kubernetes cluster.
[0074] In one possible implementation, S102 includes: B1: When the target Pod starts, the API Server pushes the first event stream corresponding to the target Pod's startup to the Operator.
[0075] B2: The Operator receives the first event stream, generates configuration parameters for initializing the container based on the routing rules corresponding to the target Pod, and generates Finalizer parameters.
[0076] B3: Load configuration parameters by initializing the container.
[0077] The Finalizer parameter is a control parameter used to indicate whether to remove the public network access permissions of a target Pod before it is deleted. In other words, the Finalizer parameter allows for the revocation of public network access permissions for a target Pod before deletion, thereby improving the security of the Kubernetes cluster. This Finalizer can be automatically generated based on pre-defined rules, and this embodiment does not impose specific limitations on it.
[0078] For example, when the target Pod starts, the API Server in the Kubernetes cluster generates a corresponding first event stream and pushes it to the Operator. When the Operator receives this first event stream, it determines that the target Pod startup event has occurred. It automatically generates configuration parameters based on the routing rules corresponding to the target Pod and generates Finalizer parameters based on pre-set permission cleanup rules. This instructs that the control parameters corresponding to the target Pod's public network access permissions be cleared before the target Pod is deleted. For example, public network access permissions can be revoked directly by deleting configuration parameters based on the generated parameters. Then, the container is initialized to load the configuration parameters, ensuring that when the target Pod accesses the public network, it first sends packets to the server corresponding to the next-hop address.
[0079] Therefore, the Operator can listen for the startup event of the target Pod, generate configuration parameters based on routing rules, and load the configuration parameters by initializing the container. This enables the configuration of public network access permissions for the target Pod when it starts, effectively improving the timeliness and flexibility of fine-grained configuration of public network access permissions.
[0080] In one possible implementation, S104 includes: C1: In response to the deletion operation of the target Pod, push the second event corresponding to the deletion of the target Pod to the Operator through the API Server.
[0081] C2: The Operator receives the second event stream, deletes the iptables rule corresponding to the target Pod, and removes the Finalizer parameter.
[0082] C3: If the API Server detects that the Finalizer parameter is missing, delete the resource information corresponding to the target Pod.
[0083] The iptables rules are generated based on configuration parameters. These iptables rules are derived from external dependencies such as network forwarding rules based on configuration parameters.
[0084] For example, when a user deletes a target Pod or the Kubernetes cluster automatically deletes a target Pod, the API Server generates a second event stream corresponding to the deletion of the target Pod and pushes this second event stream to the Operator. When the Operator receives the second event stream, it suspends the deletion operation of the target Pod, first deletes the iptables rules corresponding to the target Pod, and then clears the external dependency information corresponding to its public network access permissions. When the iptables rules are deleted, the corresponding Finalizer parameter is removed. When the API Server detects that the Finalizer parameter does not exist, it means that the control parameter for public network access permissions has been deleted, which means that the public network access permissions have been revoked. Then, the resource information corresponding to the target Pod is deleted, and the target Pod is deleted in the Kubernetes cluster.
[0085] Therefore, by using the Operator to listen for the deletion event of the target Pod, and then deleting the target Pod after confirming that the public network access permissions of the target Pod have been successfully revoked through the Finalizer, the target Pod can be deleted. This can avoid the residual configuration of its public network access permissions after the target Pod is deleted, and effectively improve the security of fine-grained configuration of public network access permissions for the Kubernetes cluster.
[0086] To facilitate a further understanding of the public network access permission management method provided in this application, an embodiment of this application provides a system applying the public network access permission management method, including an application module, a configuration module, an access module, a routing module, and a forwarding module. (Reference) Figure 2 The diagram illustrates a flowchart of a public network access permission management method provided in this application embodiment. First, an Operator listener event is set up in the K8s Cluster. When the Pod starts, an InitContainer is created via MutatingWebhook. Then, the routing module transmits the Pod's packets via the GRE / BGP protocol and forwards them to the public network via the forwarding module. The configuration module dynamically generates corresponding access permission policies, and the access module configures public network access permissions for the Pod when it starts.
[0087] The specific tasks of each module are described below.
[0088] (1) Application module: Users submit public network access requests through interfaces (CLI, API), along with business information (such as Pods or Namespaces in a Kubernetes cluster) and public network requirements (bandwidth limits, outbound carriers, etc.).
[0089] (2) Configuration module: Dynamically generate access permission information (such as allowed IP ranges, protocol types, etc.) and provide a policy query function for the forwarding module to call.
[0090] (3) Access module: When a Pod starts, the MutatingAdmissionWebhook injects and initializes the container to obtain the Pod's IP address and corresponding access permission information; sets the Pod's default route; and adds a Finalizer to ensure that permissions are revoked when the Pod is deleted.
[0091] (4) Routing module: Public network access requests are first received by the policy-based routing device, which determines whether access is allowed based on the ipset set. If access is allowed, public network access service is provided. The ipset set includes the IP addresses of the Pods that are allowed access.
[0092] (5) Forwarding module: Use a shared server to perform SNAT on the packets sent by the Pod, and implement packet forwarding through a high-performance Layer 4 proxy (TCP / UDP).
[0093] This server is one of the servers in the SNAT cluster, which supports dynamic multi-exit load balancing and redundant failover.
[0094] To more clearly describe this method of managing public network access permissions, the following explanation is based on the aforementioned system and a specific implementation scenario. The steps include the following: Step 1: The user applies for external network access.
[0095] Users submit public network access requests to the system via kubectl, API, or Web UI, along with namespace information, outbound bandwidth requirements, and supported carriers (such as China Telecom and China Mobile).
[0096] Step 2: Generate access keywords.
[0097] After receiving a user's application, the system dynamically generates an access keyword, for example: annotations: external-access-key: "my-access-key".
[0098] Step 3: Pod deployment and interception injection.
[0099] Users define the external-access-key in the Pod's Deployment / Pod YAML file, for example: apiVersion: v1 kind: Pod metadata: annotations: external-access-key: "my-access-key" The system dynamically injects an initialization container into the Pod via MutatingAdmissionWebhook and completes the following initialization: Configure the default route for the Pod so that external network traffic is forwarded through the SNAT cluster.
[0100] Obtain the corresponding access permission information (such as traffic limits) and bind it to the Pod.
[0101] Add a Finalizer to ensure that traffic rules are reclaimed after a Pod is deleted.
[0102] refer to Figure 3 The diagram shown is a schematic of permission application and configuration provided in an embodiment of this application. First, the user submits a service NS or bandwidth requirement. Then, the application module generates an access keyword, which includes the target Pod, outbound bandwidth requirements, and supported operators, etc. After that, the configuration module stores policy information in the database based on the access keyword so as to complete the configuration of access control list ACL and routing policy information when the target Podcast starts.
[0103] refer to Figure 4 The diagram shown is a schematic of Pod network injection provided in an embodiment of this application. First, the Pod creation request is processed by Kube-APIServer, and the routing configuration script is injected by MutatingWebhook. Then, when the Pod starts, the IP address of the Pod is registered to the ipset set by InitContainer. In the routing module, matching and access control are performed by combining ipset. Finally, a Finalizer is added to InitContainer by Kubelet so that public network access permissions can be revoked when the Pod is deleted.
[0104] Step 4: Public network traffic forwarding.
[0105] When a Pod initiates a public network request, the request is received by the routing module (which supports policy routing and ipset). The request is then forwarded to the SNAT cluster, where it accesses the public network through the egress device.
[0106] refer to Figure 5The diagram shown is a schematic of a packet forwarding method provided in an embodiment of this application. First, the Pod sends the original packet to the routing module. The routing module determines whether the IP address of the Pod is allowed to access the public network based on the ipset set. When the IP address is matched in the ipset set, the original packet is sent to the forwarding module for SNAT and then sent to the public network server. After that, the forwarding module receives the return packet from the public network server, performs DNAT restoration, and then sends it to the Pod.
[0107] Step 5: Pod deletion.
[0108] When the operator detects a Pod deletion event, it automatically clears the policies associated with the Pod and releases the egress bandwidth or permissions bound to that Pod.
[0109] Therefore, the public network access permission management method proposed in this application has the following advantages: (1) Pods do not need independent public IP addresses: Public network requests are forwarded to Pods by sharing SNAT, reducing the need for public IP addresses.
[0110] (2) Access permissions are bound to the Pod lifecycle: Public network access permissions are dynamically applied for and reclaimed to avoid the risk of configuration residue.
[0111] (3) Automatic fault tolerance: The SNAT cluster's services are supported by multiple egress devices, and can automatically switch when the load exceeds the limit or the device fails.
[0112] (4) Full protocol support: It adopts a four-layer proxy method and fully supports TCP, UDP protocols and common application layer protocols above (HTTP, DNS, etc.).
[0113] (5) Fine-grained permission control: Provide separate public network permission configurations for different Pods or Namespaces.
[0114] Therefore, this application embodiment uses SNAT clusters to set public network access permissions for Kubernetes clusters, which not only simplifies the complexity of public network access but also binds public network access permissions to the lifecycle of Pods, effectively improving the security of Kubernetes cluster public network access permission management.
[0115] Based on the above embodiments, this application provides a public network access permission management device, referencing... Figure 6 The diagram shown is a schematic of a public network access permission management device provided in an embodiment of this application. The device 300 includes an acquisition unit 301, a configuration unit 302, a sending unit 303, and a revocation unit 304. The acquisition unit is used to acquire public network access policy information, which includes routing rules corresponding to the target Pod in the Kubernetes cluster. The routing rules are used to define the next-hop IP address of the target Pod, and the server corresponding to the next-hop IP address is used to perform source address translation (SNAT) and packet forwarding on the target Pod. The configuration unit is used to configure the routing rules for the target Pod by initializing the container based on the public network access policy information when the target Pod starts. The sending unit is used to send the packet corresponding to the target Pod to the server corresponding to the next-hop IP address based on the routing rules when the target Pod sends a public network access request. The recycling unit is used to reclaim the public network access permissions of the target Pod when the target Pod is deleted.
[0116] By configuring routing rules, traffic to a target Pod can be routed through a server for SNAT and packet forwarding, specifying a public network exit for the target Pod. This enables the configuration of public network access permissions for the target Pod and binds these permissions to the target Pod's lifecycle, allowing for dynamic allocation and revocation of public network access permissions. Through fine-grained Pod-level management of public network access permissions, the security of public network access permission management in Kubernetes clusters is effectively improved.
[0117] In one possible implementation, the sending unit is used for: When the target Pod sends a public network access request, obtain the request message corresponding to the public network access request; Based on the IP address corresponding to the target Pod in the request message, a search is performed in the public network access address whitelist. If the IP address is in the public network access address whitelist, the message corresponding to the target Pod is sent to the server corresponding to the next-hop IP address based on the routing rules. Otherwise, the public network access request is rejected. The public network access address whitelist is used to dynamically maintain the IP addresses that are allowed to access the public network.
[0118] Therefore, by using a public network access address whitelist, it is possible to quickly determine whether a target Pod is allowed to access the public network. When handling a large number of public network access requests from Pods, updating the public network access address whitelist can track and record the public network access permissions of each Pod, thereby improving the management efficiency of public network access in the Kubernetes cluster.
[0119] In one possible implementation, the server is one server in an SNAT cluster, which is a cluster consisting of multiple servers used for SNAT, and the sending unit is further configured to: If the server corresponding to the next-hop IP address fails, the packet corresponding to the target Pod will be sent to the first server in the SNAT cluster. The first server is a server in the SNAT cluster other than the server corresponding to the next-hop IP address.
[0120] Therefore, through redundancy mechanisms, dynamic public network egress configuration and fault-to-connection capabilities can be provided, effectively improving the reliability of public network access.
[0121] In one possible implementation, the server provides public network access services for multiple Pods in the Kubernetes cluster.
[0122] This eliminates the need to allocate a separate public IP address for each Pod, effectively reducing the complexity of allocating and managing public IP addresses for each Pod.
[0123] In one possible implementation, the configuration unit is used for: When the target Pod starts, the API Server pushes the event stream corresponding to the target Pod's startup to the Operator; The Operator generates configuration parameters for initializing the container based on the routing rules corresponding to the target Pod, and generates Finalizer parameters. The Finalizer parameters are used to indicate control parameters for deleting the public network access permissions of the target Pod before it is deleted. The configuration parameters are loaded through the initialization container.
[0124] Therefore, the Operator can listen for the startup event of the target Pod, generate configuration parameters based on routing rules, and load the configuration parameters by initializing the container. This enables the configuration of public network access permissions for the target Pod when it starts, effectively improving the timeliness and flexibility of fine-grained configuration of public network access permissions.
[0125] In one possible implementation, the recycling unit is used for: In response to the deletion operation of the target Pod, the deletion event of the target Pod is pushed to the Operator through the API Server; The Operator deletes the iptables rules corresponding to the target Pod and removes the Finalizer parameter. The iptables rules are generated based on the configuration parameters. If the API Server detects that the Finalizer parameter does not exist, it deletes the resource information corresponding to the target Pod.
[0126] Therefore, by using the Operator to listen for the deletion event of the target Pod, and then deleting the target Pod after confirming that the public network access permissions of the target Pod have been successfully revoked through the Finalizer, the target Pod can be deleted. This can avoid the residual configuration of its public network access permissions after the target Pod is deleted, and effectively improve the security of fine-grained configuration of public network access permissions for the Kubernetes cluster.
[0127] Based on the above embodiments, this application provides a computer device, which includes a processor and a memory: The memory is used to store computer programs; The processor is used to execute the above-described public network access permission management method according to the computer program.
[0128] Based on the above embodiments, this application provides a computer-readable storage medium for storing a computer program, which, when executed by a computer device, implements the above-described public network access permission management method.
[0129] Based on the above embodiments, this application provides a computer program product including a computer program, which, when run on a computer device, causes the computer device to execute the above-described public network access permission management method.
[0130] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems or apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant parts can be referred to the method section.
[0131] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily 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 this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for managing public network access permissions, characterized in that, The method includes: Obtain public network access policy information, which includes routing rules corresponding to the target Pod in the Kubernetes cluster. The routing rules are used to define the next-hop IP address of the target Pod, and the server corresponding to the next-hop IP address is used to perform source address translation (SNAT) and packet forwarding for the target Pod. When the target Pod starts, the routing rules are configured for the target Pod by initializing the container based on the public network access policy information; When the target Pod sends a public network access request, based on the routing rules, the packet corresponding to the target Pod is sent to the server corresponding to the next-hop IP address; When the target Pod is deleted, its public network access permissions are revoked.
2. The method according to claim 1, characterized in that, When the target Pod sends a public network access request, sending the packet corresponding to the target Pod to the server corresponding to the next-hop IP address based on the routing rules includes: When the target Pod sends a public network access request, obtain the message corresponding to the public network access request; Based on the IP address corresponding to the target Pod in the message, a search is performed in the public network access address whitelist. If the IP address is in the public network access address whitelist, the message corresponding to the target Pod is sent to the server corresponding to the next-hop IP address based on the routing rules. Otherwise, the public network access request is rejected. The public network access address whitelist is used to dynamically maintain the IP addresses that are allowed to access the public network.
3. The method according to claim 1, characterized in that, The server is one of the servers in an SNAT cluster, which is a cluster of multiple servers used for SNAT. After sending the packet corresponding to the target Pod to the server corresponding to the next-hop IP address, the method further includes: If the server corresponding to the next-hop IP address fails, the packet corresponding to the target Pod will be sent to the first server in the SNAT cluster. The first server is a server in the SNAT cluster other than the server corresponding to the next-hop IP address.
4. The method according to claim 1, characterized in that, The server provides public network access services for multiple Pods in the Kubernetes cluster.
5. The method according to claim 1, characterized in that, The step of configuring the routing rules for the target Pod by initializing the container based on the public network access policy information when the target Pod starts includes: When the target Pod starts, the API Server pushes the first event stream corresponding to the target Pod's startup to the Operator; The Operator receives the first event stream, generates configuration parameters based on the routing rules corresponding to the target Pod, and generates Finalizer parameters. The Finalizer parameters are used to indicate control parameters for deleting the public network access permissions of the target Pod before it is deleted. The configuration parameters are loaded through the initialization container.
6. The method according to claim 5, characterized in that, When the target Pod is deleted, revoking the target Pod's public network access includes: In response to the deletion operation of the target Pod, the second event stream corresponding to the deletion of the target Pod is pushed to the Operator through the API Server; The Operator receives the second event stream, deletes the iptables rule corresponding to the target Pod, and removes the Finalizer parameter. The iptables rule is generated based on the configuration parameters. If the API Server detects that the Finalizer parameter does not exist, it deletes the resource information corresponding to the target Pod.
7. A public network access permission management device, characterized in that, The device includes an acquisition unit, a configuration unit, a transmission unit, and a retrieval unit: The acquisition unit is used to acquire public network access policy information, which includes routing rules corresponding to the target Pod in the Kubernetes cluster. The routing rules are used to define the next-hop IP address of the target Pod, and the server corresponding to the next-hop IP address is used to perform source address translation (SNAT) and packet forwarding on the target Pod. The configuration unit is used to configure the routing rules for the target Pod by initializing the container based on the public network access policy information when the target Pod starts. The sending unit is used to send the packet corresponding to the target Pod to the server corresponding to the next-hop IP address based on the routing rules when the target Pod sends a public network access request. The recycling unit is used to reclaim the public network access permissions of the target Pod when the target Pod is deleted.
8. A computer device, characterized in that, The computer device includes a processor and memory: The memory is used to store computer programs; The processor is configured to perform the method according to any one of claims 1-6 according to the computer program.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when executed by a computer device, performs the method described in any one of claims 1-6.
10. A computer program product comprising a computer program, characterized in that, When it is run on a computer device, it causes the computer device to perform the method described in any one of claims 1-6.