Implementation method for multi-tenant isolation of container desktop cloud

Abstract

The invention discloses an implementation method for multi-tenant isolation of container desktop cloud. The implementation method comprises the following steps: creating an independent Docker network; providing an external communication port using the proxy container; forwarding and isolating network traffic; external network communication of the internal container is not influenced; the invention relates to expandability and dynamic adjustment of proxy containers. An independent Docker network is created for each tenant, and the proxy container is responsible for external network communication, so that network isolation between the tenants is realized, and external communication of the containers inside the tenants is ensured. And the proxy container is also used for realizing further network limitation and flow control.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing resources, and in particular to a method for implementing multi-tenant isolation of a container desktop cloud. Background Art

[0002] With the rapid development of cloud computing technology, container technology and container orchestration tools (such as Docker Swarm and Kubernetes) have been widely used in enterprise IT infrastructure. Container technology makes the use of cloud computing resources more flexible and efficient through its advantages of lightweight and rapid deployment. In such an environment, multiple tenants (such as different companies or departments) can share the same container cluster resources to reduce costs and improve resource utilization.

[0003] Defects and shortcomings of the existing technology:

[0004] Complexity based on traditional network isolation: In traditional network architecture, network isolation is usually achieved through VLAN (virtual local area network), VPN or firewall rules. However, in a containerized multi-tenant environment, especially in a Swarm cluster, this approach becomes complicated and inefficient:

[0005] Complex configuration: Each tenant needs to configure network isolation policies separately, such as manually setting different VLANs, IP segments or firewall rules. As the number of tenants increases, the configuration management of network isolation will become very complex, prone to configuration errors, and increase the difficulty of network management.

[0006] High maintenance cost: Traditional isolation methods require network administrators to frequently adjust network configurations, especially when dynamically adding or deleting tenants. The high maintenance cost and slow response speed make it difficult to meet the rapidly changing needs in a cloud computing environment.

[0007] Inflexible: VLAN and physical network isolation usually rely on the support of underlying network devices, lack flexibility, and are not suitable for rapidly expanding or adjusting cloud environments.

[0008] Existing container network plug-ins have insufficient isolation capabilities: Container network isolation in Swarm clusters mostly relies on network plug-ins (such as Overlay network, Macvlan, etc.). These plug-ins can provide a certain degree of isolation, but there are still limitations in multi-tenant scenarios:

[0009] Limitations of Overlay Network: The Overlay network provided by Swarm by default allows containers to communicate across nodes, but all tenants' containers run in the same logical network and cannot provide strict isolation. Although a certain degree of isolation can be achieved through customized network configuration, the operation is complex and lacks flexibility.

[0010] Lack of fine-grained network isolation control: Existing network plug-ins such as Flannel and Calico support cross-node container communication and certain isolation strategies, but lack tenant-based fine-grained control and are unable to meet multi-tenant isolation requirements.

[0011] Lack of isolation mechanism and weak security: Due to the lightweight design of containers, they share the same kernel resources. If there is no strict isolation mechanism, some malicious users or tenants may steal other tenants' data or traffic through container escape, network sniffing, etc., causing security risks.

[0012] Lack of automated isolation solutions: In existing Swarm clusters, network isolation configuration mostly relies on manual operations or static rule configuration, and lacks automated network isolation management solutions. For example:

[0013] When a new tenant joins, the administrator needs to manually configure an isolated network for the tenant. This operation is time-consuming, labor-intensive, and error-prone, especially in large-scale clusters.

[0014] There is a lack of a dynamic adjustment mechanism for tenant isolation policies. When tenants' needs change, such as adjusting the tenant's network bandwidth, IP allocation, etc., existing technologies are difficult to automate and respond quickly.

[0015] Poor performance and scalability: Some current network isolation technologies can cause performance bottlenecks, especially in multi-tenant environments:

[0016] Performance loss: Some software-based isolation methods (such as IPSec-based encrypted tunnels, Overlay networks, etc.) introduce additional performance overhead while providing isolation, affecting the overall network throughput of the cluster and the latency of communication between containers.

[0017] Insufficient scalability: As the number of tenants and cluster size increase, existing isolation technologies may find it difficult to support efficient expansion. For example, the scalability of existing solutions is poor when dynamic network isolation is required for a large number of tenants.

[0018] Increased risk of cross-tenant attacks: In a multi-tenant Swarm cluster, different tenants share the same physical cluster environment. If network isolation is not strict, cross-tenant attacks may occur. For example, after a tenant's container is attacked or controlled, the attacker may try to access other tenants' containers through network detection and vulnerability exploitation, causing data leakage and security issues. Summary of the invention

[0019] In view of the above problems, the present invention is proposed to provide a method for implementing multi-tenant isolation of container desktop clouds that overcomes the above problems or at least partially solves the above problems.

[0020] According to one aspect of the present invention, a method for implementing multi-tenant isolation of a container desktop cloud is provided, and the method comprises:

[0021] Create a separate Docker network;

[0022] Use a proxy container to provide external communication ports;

[0023] Forwarding and isolation of network traffic;

[0024] Does not affect the external network communication of internal containers;

[0025] Scalability and dynamic adjustment of proxy containers.

[0026] Optionally, the step of creating an independent Docker network specifically includes:

[0027] To achieve network isolation in a multi-tenant environment, create a separate Docker network for each tenant;

[0028] The Docker network only contains all desktop containers belonging to the tenant and does not share network resources with tenants;

[0029] Each tenant's network has an independent IP segment;

[0030] Desktop containers can communicate internally within the same tenant's network, but cannot communicate with other tenants' containers over the network, thus achieving strict isolation between tenants.

[0031] Optionally, the using a proxy container to provide an external communication port specifically includes:

[0032] Each tenant has an independent proxy container, which is located in the tenant's Docker network and is also connected to the Overlay network in the Swarm cluster.

[0033] Optionally, the Overlay network specifically includes:

[0034] The proxy container forwards traffic in the tenant network to the external network and receives requests from the external network to the tenant's internal container;

[0035] The proxy container provides external services through port mapping on the Overlay network. External clients access the desktop container within the tenant through the port mapped by the proxy container.

[0036] The desktop container itself will not be directly exposed to the Overlay network, and no external ports will be mapped to it, thus preventing direct external access to the desktop container.

[0037] Optionally, the forwarding and isolation of the network traffic specifically includes: the proxy container is responsible for the communication of the external network, and also manages and limits the traffic of the tenant's internal network.

[0038] Optionally, the proxy container is responsible for external network communication and also manages and limits the traffic on the tenant's internal network, specifically including:

[0039] Port mapping and forwarding: The proxy container provides port mapping through the Overlay network to direct external requests to the target desktop container in the tenant network. The proxy container maintains a port mapping table and forwards external network traffic to different desktop containers within the tenant according to the destination port, so that the outside world can access the resources of a specific tenant.

[0040] Isolation between tenants: Since each tenant has its own independent Docker network, the proxy container can only access the network of its corresponding tenant and cannot access other tenants' containers across networks, thus achieving strict tenant isolation.

[0041] Traffic restriction and control: The proxy container configures network policies to restrict and monitor tenants’ external communications.

[0042] Optionally, the external network communication that does not affect the internal container specifically includes:

[0043] Through the proxy container, the container inside the tenant communicates with the external network;

[0044] When the desktop container needs to access external services, the traffic is forwarded to the external network through the proxy container to ensure that the desktop container's external communication capabilities are not affected.

[0045] Optionally, the container inside the tenant communicates with the external network through the proxy container specifically including:

[0046] The desktop container communicates with the outside world through the proxy container;

[0047] External communication of the desktop container does not affect its isolation in the tenant's internal network, ensuring security in a multi-tenant environment.

[0048] Optionally, the scalability and dynamic adjustment of the proxy container specifically include:

[0049] When a new tenant joins, an independent Docker network is automatically created and a proxy container is deployed to achieve automated network isolation and communication proxy.

[0050] The proxy container dynamically adjusts the network policy according to the needs of tenants, supports flexible bandwidth management and traffic control functions, and adapts to changes in tenant scale and needs;

[0051] Centrally manage the network configuration of all proxy containers through a centralized management platform, simplifying network isolation and control in a multi-tenant environment.

[0052] The present invention provides a method for implementing multi-tenant isolation of a container desktop cloud, the method comprising: creating an independent Docker network; using a proxy container to provide an external communication port; forwarding and isolating network traffic; not affecting external network communication of internal containers; and scalability and dynamic adjustment of proxy containers. By creating an independent Docker network for each tenant and using a proxy container to be responsible for external network communication, network isolation between tenants is achieved while ensuring external communication of containers within the tenant. The proxy container is also used to implement further network restrictions and traffic control.

[0053] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0055] Figure 1 A flowchart of a method for implementing multi-tenant isolation of a container desktop cloud provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0056] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0057] The terms "comprises" and "having" and any variations thereof in the description embodiments, claims and drawings of the present invention are intended to cover non-exclusive inclusions, for example, including a series of steps or units.

[0058] The technical solution of the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0059] Example 1

[0060] A method for implementing network isolation in a container desktop cloud multi-tenant environment mainly solves the problems of lax multi-tenant container network isolation, complex management, and insufficient dynamic adjustment capabilities in the prior art.

[0061] This method creates an independent Docker network for each tenant and uses a proxy container to be responsible for external network communication, thereby achieving network isolation between tenants while ensuring that containers within the tenant can communicate with the outside world. The proxy container can also be used to implement further network restrictions and traffic control.

[0062] like Figure 1 As shown, the specific implementation method steps include:

[0063] Create an independent Docker network: To achieve network isolation in a multi-tenant environment, this solution creates an independent Docker network for each tenant.

[0064] The network contains only all desktop pods that belong to that tenant and does not share network resources with other tenants.

[0065] Each tenant's network has an independent IP segment and does not conflict with other tenants' networks.

[0066] Desktop containers can communicate internally within the same tenant's network, but cannot communicate with other tenants' containers over the network, thus achieving strict isolation between tenants.

[0067] Use proxy containers to provide external communication ports: Each tenant has an independent proxy container, which is located in the tenant's Docker network and is also connected to the Overlay network in the Swarm cluster. The proxy container is responsible for the communication between the tenant's internal containers and the external network.

[0068] The proxy container forwards traffic in the tenant network to the external network and receives requests from the external network to the tenant's internal container.

[0069] To ensure security, the proxy container provides external services through port mapping on the Overlay network. For example, external clients need to use the port mapped by the proxy container to access the desktop container within the tenant.

[0070] The desktop container itself will not be directly exposed to the Overlay network, and no external ports will be mapped to it, thus avoiding direct external access to the desktop container and improving security.

[0071] Forwarding and isolation of network traffic: The proxy container is not only responsible for external network communication, but also manages and limits the traffic of the tenant's internal network. The main functions of the proxy container are as follows:

[0072] Port mapping and forwarding: The proxy container provides port mapping through the Overlay network to direct external requests to the target desktop container in the tenant network. The proxy container maintains a port mapping table and forwards network traffic from the outside to different desktop containers within the tenant according to the destination port, so that the outside can access the resources of a specific tenant.

[0073] Isolation between tenants: Since each tenant has its own independent Docker network, the proxy container can only access the network of its corresponding tenant and cannot access other tenants' containers across networks, thus achieving strict tenant isolation.

[0074] Traffic restriction and control: The proxy container can configure network policies to restrict and monitor tenants' external communications. For example, bandwidth control and access control (ACL) can be performed on external traffic, or access rights to certain specific IP addresses or ports can be restricted, thereby enhancing tenants' network security and management capabilities.

[0075] Does not affect the external network communication of internal containers: Although each tenant's desktop container is not directly exposed to the Overlay network, the containers inside the tenant still communicate with the external network through the proxy container.

[0076] For example, when a desktop container needs to access external services, the traffic is forwarded to the external network through the proxy container to ensure that the desktop container's external communication capabilities are not affected.

[0077] The desktop container can communicate with the outside world through the proxy container without additional network configuration.

[0078] External communication of the desktop container does not affect its isolation in the tenant's internal network, ensuring security in a multi-tenant environment.

[0079] Scalability and dynamic adjustment of proxy container: The proxy container of this solution has good scalability and dynamic management capabilities:

[0080] When a new tenant joins, the system automatically creates an independent Docker network for it and deploys a proxy container to achieve automated network isolation and communication proxy.

[0081] The proxy container dynamically adjusts network policies according to tenant needs, supports flexible bandwidth management, traffic control and other functions, and adapts to changes in tenant scale and needs.

[0082] The system centrally manages the network configuration of all proxy containers through a centralized management platform, simplifying network isolation and control in a multi-tenant environment.

[0083] Example 2

[0084] A method for implementing multi-tenant isolation of a container desktop cloud includes:

[0085] 1. Create a separate Docker network for each tenant

[0086] When new tenants (for example, Company A and Company B) need to deploy their desktop cloud services in the Swarm cluster, the system creates an independent Docker network for each tenant. This network is dedicated to communication between all containers within the tenant. The network configuration specifically includes:

[0087] Create a Docker network for company A, for example named tenantA_network.

[0088] Create another separate Docker network for company B and name it tenantB_network.

[0089] Each tenant's network uses an independent IP segment, for example, tenantA_network uses 172.20.0.0 / 16, while tenantB_network uses 172.21.0.0 / 16, to ensure that they cannot communicate directly over the network.

[0090] Example command to create a separate network:

[0091] dockernetwork create--driver overlay tenantA_network

[0092] dockernetwork create--driver overlay tenantB_network

[0093] 2.Deploy desktop containers on-premises

[0094] Tenants' desktop containers are deployed in their own independent Docker networks. For example, company A's desktop containers are deployed in tenantA_network, while company B's desktop containers are deployed in tenantB_network.

[0095] Desktop container deployment example for Company A:

[0096] docker service create--name tenantA_desktop1--network tenantA_networkdesktop_image

[0097] docker service create--name tenantA_desktop2--network tenantA_networkdesktop_image

[0098] Similarly, company B's desktop containers are deployed in tenantB_network. The containers can communicate freely in the same tenant's network, but company A and company B's containers are isolated from each other and cannot communicate across networks.

[0099] 3. Create and configure the proxy container

[0100] In order to achieve external access to the tenant's internal container, the system creates a proxy container for each tenant, which is connected to both the tenant's independent network and the cluster's Overlay network. The main function of the proxy container is to provide external ports, forward external access requests to the tenant's internal desktop container, and forward the external traffic of the internal container.

[0101] For example, create a proxy container for company A, which is connected to tenantA_network and the overlay_network of the Swarm cluster. Through the port mapping function of the proxy container, external traffic is forwarded to the internal network.

[0102] Creating a proxy container example

[0103] docker service create--name tenantA_proxy--network tenantA_network--network overlay_network\

[0104] -p 8080:8080proxy_image

[0105] In the above example, the proxy container tenantA_proxy maps the external port 8080 and forwards external traffic to the desktop container in tenantA_network through this port. At the same time, the proxy container can also configure network policies, such as firewall rules and access control lists (ACLs), to restrict external access.

[0106] 4. Implement external communication of internal containers

[0107] The proxy container allows the tenant's desktop container to communicate with the external network in the following ways:

[0108] External access to tenant internal containers: When an external client needs to access the desktop container of company A, the external request passes through the port mapping of the proxy container, and the proxy container forwards the request to a specific desktop container in the tenant network according to the mapping rules. For example, when external access is made to http: / / {Swarm_IP}:8080, the proxy container forwards the traffic to the desktop container tenantA_desktop1 in tenantA_network.

[0109] External traffic forwarding of internal containers: When the desktop container within the tenant needs to access the external network, the traffic will also be forwarded through the proxy container. For example, if tenantA_desktop1 wants to access Internet resources, its traffic will pass through the tenantA_proxy proxy container and then forwarded to the external network to ensure the normal operation of external communication.

[0110] 5. Network control of proxy containers

[0111] The proxy container is not only responsible for network forwarding, but also has traffic restriction and control functions. System administrators can implement the following controls on the proxy container:

[0112] Bandwidth control: Configure different bandwidth limits for each tenant to ensure that network resources of different tenants do not conflict and maintain the overall performance of the cluster.

[0113] Security policy: Configure firewall rules on the proxy container to restrict access to certain IP addresses, ports, or protocols. For example, the administrator configures rules to prohibit external access to specific ports or source IPs.

[0114] Traffic monitoring: The proxy container can collect tenants' network traffic data in order to monitor and analyze tenants' network usage and further optimize the allocation of network resources.

[0115] 6. Dynamic adjustment and expansion

[0116] The solution supports dynamic expansion and automated management of tenants:

[0117] When a new tenant joins, the system creates an independent Docker network and proxy container for it through an automated script to ensure that the new tenant is isolated from the network of existing tenants.

[0118] When the number of tenants' desktop containers increases or decreases, the configuration of the proxy container is dynamically adjusted to add or delete port mapping rules to ensure the normal operation of external access.

[0119] The proxy container automatically adjusts network policies based on tenant needs, such as increasing or decreasing bandwidth limits or temporarily enabling certain network access permissions.

[0120] Beneficial effects: Strict tenant network isolation: Each tenant uses an independent Docker network to ensure that network traffic between tenants is completely isolated, and containers of different tenants cannot communicate directly, thereby improving the security and privacy protection of tenant data.

[0121] Flexible external communication mechanism: By providing services to the outside world through the proxy container, the tenant's desktop container will not be directly exposed to the external network, reducing the risk of external attacks. At the same time, the port mapping mechanism of the proxy container ensures that the desktop container can still flexibly communicate with the outside world without affecting the user experience.

[0122] Controllable network management: The proxy container supports refined management of external traffic. Administrators can monitor and restrict tenants' external communications through the proxy container to further improve network security. The proxy container design also supports flexible network policy adjustments to meet the diverse needs of tenants.

[0123] Simplified deployment and management: This solution simplifies network management in a multi-tenant environment by creating independent networks and proxy containers for each tenant. The automated deployment and centralized management capabilities of the proxy container reduce the administrator's configuration workload while supporting dynamic expansion of tenants and rapid adjustment of network isolation policies.

[0124] The above specific implementation methods further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific implementation methods of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for implementing multi-tenant isolation of container desktop cloud, characterized in that: The implementation method includes: Create a separate Docker network; Use a proxy container to provide external communication ports; Forwarding and isolation of network traffic; Does not affect the external network communication of internal containers; Scalability and dynamic adjustment of proxy containers.

2. According to claim 1, a method for implementing multi-tenant isolation of container desktop cloud is characterized in that: The creation of an independent Docker network specifically includes: To achieve network isolation in a multi-tenant environment, create a separate Docker network for each tenant; The Docker network only contains all desktop containers belonging to the tenant and does not share network resources with tenants; Each tenant's network has an independent IP segment; Desktop containers can communicate internally within the same tenant's network, but cannot communicate with other tenants' containers over the network, thus achieving strict isolation between tenants.

3. According to claim 1, a method for implementing multi-tenant isolation of container desktop cloud is characterized in that: The use of the proxy container to provide an external communication port specifically includes: Each tenant has an independent proxy container, which is located in the tenant's Docker network and is also connected to the Overlay network in the Swarm cluster.

4. According to claim 3, a method for implementing multi-tenant isolation of container desktop cloud is characterized in that: The Overlay network specifically includes: The proxy container forwards traffic in the tenant network to the external network and receives requests from the external network to the tenant's internal container; The proxy container provides external services through port mapping on the Overlay network. External clients access the desktop container within the tenant through the port mapped by the proxy container. The desktop container itself will not be directly exposed to the Overlay network, and no external ports will be mapped to it, thus preventing direct external access to the desktop container.

5. According to claim 1, a method for implementing multi-tenant isolation of container desktop cloud is characterized in that: The forwarding and isolation of the network traffic specifically includes: the proxy container is responsible for the communication of the external network, and also manages and limits the traffic of the tenant's internal network.

6. A method for implementing multi-tenant isolation of container desktop cloud according to claim 5, characterized in that: The proxy container is responsible for external network communication and also manages and limits the traffic on the tenant's internal network. Specifically: Port mapping and forwarding: The proxy container provides port mapping through the Overlay network to direct external requests to the target desktop container in the tenant network. The proxy container maintains a port mapping table and forwards external network traffic to different desktop containers within the tenant according to the destination port, so that the external can access the resources of a specific tenant. Isolation between tenants: Since each tenant has its own independent Docker network, the proxy container can only access the network of its corresponding tenant and cannot access other tenants' containers across networks, thus achieving strict tenant isolation. Traffic restriction and control: The proxy container configures network policies to restrict and monitor tenants’ external communications.

7. A method for implementing multi-tenant isolation of container desktop cloud according to claim 1, characterized in that: The external network communication that does not affect the internal container specifically includes: Through the proxy container, the container inside the tenant communicates with the external network; When the desktop container needs to access external services, the traffic is forwarded to the external network through the proxy container to ensure that the desktop container's external communication capabilities are not affected.

8. A method for implementing multi-tenant isolation of container desktop cloud according to claim 7, characterized in that: The communication between the container inside the tenant and the external network through the proxy container specifically includes: The desktop container communicates with the outside world through the proxy container; External communication of the desktop container does not affect its isolation in the tenant's internal network, ensuring security in a multi-tenant environment.

9. A method for implementing multi-tenant isolation of container desktop cloud according to claim 1, characterized in that: The scalability and dynamic adjustment of the proxy container specifically include: When a new tenant joins, an independent Docker network is automatically created and a proxy container is deployed to achieve automated network isolation and communication proxy. The proxy container dynamically adjusts the network policy according to the needs of tenants, supports flexible bandwidth management and traffic control functions, and adapts to changes in tenant scale and needs; Centrally manage the network configuration of all proxy containers through a centralized management platform, simplifying network isolation and control in a multi-tenant environment.

Images