Dynamic proxy response to application container

Abstract

This disclosure describes the use of dynamic proxies to secure communications between sources and application containers within a cloud environment. The technology includes intercepting traffic directed to an application container, analyzing the traffic and traffic patterns, and allowing or blocking the traffic from being passed to the application container based on the analysis. A traffic analysis engine can determine whether the traffic is deemed safe and allowed to be passed to the application container, or whether the traffic is deemed unsafe and blocked from being passed to the application container. According to some configurations, the address(es) of a network interface (e.g., WIFI or Eth0) are abstracted to help ensure the security of the application container.

Description

[0001] Cross-reference of related applications

[0002] This application claims priority to U.S. Patent Application No. 17 / 304,891, filed June 28, 2021, which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure generally relates to techniques for protecting communications with containers in a cloud environment. Background Technology

[0004] Enterprises are moving towards different cloud models, such as hybrid cloud, multi-cloud, and connected cloud networks. In multi-cloud environments, there are often different microservices and application containers hosted on Internet of Things (IoT) gateways or edge computing hardware to perform various processing functions and integrate with different instances of cloud services. In many examples, the communication patterns of application containers (running at the edge of the cloud) use publish-subscribe communication methods or some type of client-proxy communication method, such as Message Queuing Telemetry Transport (MQTT). However, securing communication with application containers that may be located on different public / private networks can be challenging. For example, simply using access control lists (ACLs) or IP network address translation (NAT) cannot provide 100% protection for application containers in a multi-cloud environment. Attached Figure Description

[0005] A detailed description is given below with reference to the accompanying drawings. In the drawings, the leftmost number(s) of the reference numerals identify the drawing in which that reference numeral first appears. The same reference numerals are used in different figures to indicate similar or identical items. The systems depicted in the drawings are not drawn to scale, and the components in the drawings may not be drawn to scale with each other.

[0006] Figure 1 This demonstrates a system that uses dynamic delegated agents to help secure communication with application containers in a multi-cloud environment.

[0007] Figure 2 This demonstrates a system for configuring and using dynamic delegated agents to help secure communications originating from different cloud services.

[0008] Figure 3 An IoT edge gateway node is shown that uses a dynamic delegated agent to secure communications.

[0009] Figure 4 This is a flowchart illustrating the process for protecting communication with application containers in a multi-cloud environment.

[0010] Figure 5 This is a flowchart illustrating the process of performing traffic analysis on traffic directed to an application container.

[0011] Figure 6 An example computer architecture is shown that is capable of executing program components to implement the functions described herein. Detailed Implementation

[0012] Overview

[0013] Various aspects of the invention are set forth in the independent claims, and preferred features are set forth in the dependent claims. A feature of one aspect may be applied alone to any aspect or in combination with other aspects.

[0014] This disclosure describes techniques for using dynamic proxies to secure communication between a source and an application container within a cloud environment. These techniques include intercepting traffic directed to the application container, analyzing traffic and traffic patterns, and allowing or blocking traffic from being delivered to the application container based on that analysis. According to some examples, one or more addresses of a network interface (e.g., Wi-Fi or Eth0) are abstracted to help ensure the security of the application container. The techniques described herein can be executed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the described methods.

[0015] Example Implementation

[0016] Cloud-native applications (including multiple "microservices" supported by service meshes) are gaining increasing popularity. Instances of microservice applications can be hosted in different locations and can communicate with each other over one or more networks (e.g., software-defined wide area networks, SD-WAN). Cloud-native applications are collections of small, independent, and loosely coupled services. Many cloud-native applications adopt a microservices architecture compared to monolithic architectures. In a monolithic architecture, applications are typically built as a single deployable unit. In contrast, in a microservices architecture, a complex system may be divided into multiple independent, narrowly focused services, each with its own independent business logic and data storage. In some examples, cloud-native application services can be distributed across different cloud environments, including one or more public cloud environments and one or more private networks. In a microservices architecture, any service can typically be scaled and deployed independently.

[0017] Service meshes can be used to control how microservices and other parts of an application share data with each other. A service mesh is a dedicated, configurable infrastructure layer built into an application, typically designed to handle large volumes of network-based inter-process communication using application programming interfaces (APIs). Service meshes can provide capabilities such as service discovery, load balancing, and encryption. A service mesh can be implemented by providing a proxy instance, called a sidecar, for each microservice application instance. The sidecar can manage inter-service communication over SD-WAN, monitor operations, handle security-related issues, and / or other functionalities abstracted from the individual microservice application instances.

[0018] In cloud environments (e.g., multi-cloud environments), there are often different microservices and application containers hosted on Internet of Things (IoT) gateways or edge computing hardware to perform various processing functions and integrate with different instances of cloud services. Communication patterns between application containers (e.g., running at the edge of the cloud) and other endpoints (e.g., in the cloud) can use publish-subscribe communication methods or some type of client-broker communication method (e.g., MQTT). However, prior to the techniques described in this paper, in both of these communication methods, application containers were mapped and bound to physical or virtual network interfaces (e.g., Fast Ethernet (FE), Gigabit Ethernet (GE), Wi-Fi, cellular radio, Virtual Ethernet (vEth)). Failing to abstract the network interface of application containers is likely to expose the network interface details in the data packets transmitted between the cloud network and the application containers.

[0019] Using the techniques described herein, dynamic delegation agents help secure communication with containers, such as one or more application containers hosted on an IoT gateway, edge computing hardware, or some other location. A dynamic delegation agent can receive incoming traffic from different services located in one or more cloud services and determine whether to allow or block that traffic from being delivered to the application container.

[0020] In some examples, a traffic analysis engine (e.g., a webhook server or other device or component) can perform analysis on traffic and / or traffic patterns directed to the application container. The traffic analysis engine can perform deep packet inspection of the traffic and can identify information such as: the source of the incoming traffic (e.g., a microservice, a Virtual Private Cloud (VPC), etc.), end-to-end traffic analysis identifying different points from the source to a dynamic delegated broker, and identified patterns associated with the source (e.g., the frequency with which the source sends traffic to the application container). In some examples, (e.g., in a webhook server) a virtual probe can be used to analyze the traffic.

[0021] The traffic analysis engine can determine whether traffic is considered secure and allowed to be delivered to the application container, or whether traffic is considered insecure and blocked from delivery. Many different techniques can be used to determine the security of incoming traffic to the container, such as, but not limited to: whether the traffic source originates from a trusted network; whether the traffic has passed through any insecure points; whether the application container has previously received traffic from that source; and so on. If the traffic analysis engine does not identify a security threat or find any other anomalies, it can authorize and allow the traffic source to send data to the application container via a dynamic delegation agent.

[0022] Depending on the configuration, the dynamic delegation agent maintains information indicating whether traffic is authorized and / or unauthorized. For example, the dynamic delegation agent may maintain a traffic table / list that includes entries identifying the source of authorized traffic and / or the source of unauthorized traffic. For instance, the traffic table may include entries indicating that traffic from a specific source IP address (or some other identifier) ​​is allowed and directed to one or more specific application containers within a pod. In some configurations, traffic received from a source may be restricted to specific time ranges (e.g., 12 PM to 3 PM, 6 AM to 5 PM, etc.). According to some examples, once a source (e.g., a microservice source for a cloud-native application) is allowed, any further traffic received by the dynamic traffic agent from that source may be allowed without further checks. In other examples, traffic analysis may be performed each time traffic is received, and / or at some other interval or in response to an event / condition.

[0023] In other examples, when the traffic analytics engine determines that incoming traffic is insecure, it blocks incoming traffic originating from a specific source (e.g., a microservice and / or a Virtual Private Network (VPN)) from being delivered to the application container. In some configurations, incoming traffic identified as insecure can be redirected to a different location, such as isolating working containers. In other examples, micro-segmentation-based security policies can be used to isolate application containers running on the same node from each other.

[0024] Dynamic delegation agents can also abstract network interface details to access application containers. In this way, the network interface details of the application container are not exposed when communicating with services in different clouds and / or other network locations. In some configurations, hash values ​​can be used to abstract the network interface details of containers protected by dynamic delegation agents. In addition to the exposed network interface, dynamic delegation agents can also abstract the identifier of the application container. Compared to existing technologies, the dynamic delegation agent described herein can abstract the IoT gateway from the perspective of security attack vectors by masking the MAC address of the Wi-Fi or Ethernet NIC present in the physical interface of the IoT gateway. The techniques described herein can be executed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the methods described herein.

[0025] Certain embodiments and implementations of this disclosure will now be described more fully with reference to the accompanying drawings, in which various aspects are illustrated. However, these aspects may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein. As stated herein, this disclosure includes variations of the embodiments. The same reference numerals always refer to the same elements.

[0026] Figure 1 System 100 is shown, which uses a dynamic delegated agent 104 to help secure communication with containers 106 in a multi-cloud environment. Figure 1 As shown, cloud services 102A and 102B communicate with application containers 106A-106H via dynamic delegation agents 104A-104B (as shown by the solid lines between services 114A and 114B and dynamic delegation agents 104A and 104B), instead of communicating directly with the application containers as in the prior art (as shown by the dashed lines).

[0027] In a cloud environment, for example Figure 1 The multi-cloud environment illustrated often features various microservices and application containers 106 hosted on the Internet via the IoT gateway / node 108 to perform various processing functions and integrate with different services 114 in the cloud service 102. For an example IoT gateway node, see [link to example IoT gateway node]. Figure 3 And related discussions.

[0028] As shown in system 100, dynamic delegated proxies 104, such as dynamic delegated proxies 104A and 104B, can be used to help secure communication with containers (e.g., application containers 106A-106D hosted by IoT gateway 108A and application containers 106E-106H hosted by IoT gateway 108B). Instead of cloud service 102A's service 114A and cloud service 102B's service 114B communicating directly with container 106, services 114A and 114B of cloud service 102A use dynamic delegated proxies 104 to securely communicate with application container 106.

[0029] When traffic enters the container pod running container 106 from outside IoT gateway 108 (e.g., different hybrid cloud services), dynamic delegation agent 104 receives the incoming traffic and causes traffic analysis to be performed. In some examples, dynamic delegation agent 104 sends the incoming traffic to traffic analysis engine 110 to perform traffic analysis. Depending on some configurations, traffic analysis engine 110 may be a webhook server using a virtual probe for traffic monitoring. Although traffic analysis engine 110A is shown as separate from dynamic delegation agent 104A, traffic analysis engine 110A can be part of dynamic delegation agent 104A. In some examples, the operation of dynamic delegation agent 104A can be performed within the master node agent, such as within a kubelet in Kubernetes as a traffic engineering probe. Furthermore, although traffic analysis engine 110A is shown as separate from dynamic delegation agent 104, some / all of the functionality of the traffic analysis engine can be performed by the dynamic delegation agent.

[0030] Traffic analysis engines 110, such as traffic analysis engine 110A and traffic analysis engine 110B, can perform traffic analysis to determine whether traffic received from service 114 is considered secure and allowed to be passed to application container 106, or whether the traffic is considered insecure and blocked from being passed to application container. As briefly discussed above, many different techniques can be used to determine whether incoming traffic to the container is secure, such as, but not limited to: whether the source of the traffic is a trusted network; whether the traffic has passed through any insecure points; whether the application container has previously received traffic from that source; and so on.

[0031] Depending on the configuration, traffic analysis engine 110 can perform deep packet inspection (DPI) on traffic received from service 114, which is hosted in cloud service 102 and / or in some other location outside application container 106. Traffic analysis engine 110 can identify information such as the source of incoming traffic (e.g., the IP address of service 114, a VPC, or some other traffic source). In some examples, traffic analysis engine 110 performs end-to-end traffic analysis, which identifies information about the different points from which incoming traffic has been passed from the source to dynamic delegation agent 104A. Traffic analysis engine 110 can also identify traffic patterns associated with the source, such as the frequency with which the service sends traffic to the application container.

[0032] Over time, the traffic analytics engine 110 can learn communication patterns from application container 106 to external networks, such as communication patterns between IoT gateways 108A and / or 108B and cloud services 102A and / or 102B. Traffic communication patterns can be to a specific service 114, to a VPC hosted by a cloud service, and / or to some other external traffic source. Depending on some configurations, the dynamic delegation agent 104 creates traffic tables 116, such as traffic tables 116A and 116B, which map to sources learned over time, such as cloud services 102A and / or 102B. In some configurations, the dynamic delegation agent 104A stores entries in the tables to indicate whether traffic is allowed into the container and / or whether traffic is unauthorized to be delivered to the container.

[0033] If the traffic analysis engine 110 does not identify one or more security threats or detects any other anomalies, service 114 may be authorized to send data to application container 106 to which traffic is directed via dynamic delegation agent 104. Depending on the configuration, dynamic delegation agent 104 maintains data indicating whether traffic is authorized and / or unauthorized. For example, dynamic delegation agent 104 may maintain a traffic table / list 116 that includes entries identifying the source of authorized traffic and / or the source of unauthorized traffic. For example, traffic table 116 may include entries indicating that traffic from a specific source IP address (or some other identifier) ​​is allowed to be directed to one or more specific containers within a container pod. In some configurations, traffic from a source may be authorized to pass through at certain times and blocked at other times (e.g., allowed from 8:00 AM to 5:00 PM, and restricted from 5:00 PM to 8:00 AM). In some configurations, traffic table 116 may be updated based on traffic patterns detected over time and / or traffic analysis performed at different times.

[0034] As discussed more briefly below, the dynamic delegation agent 104 can abstract the identification information of the application container 106. In some examples, the dynamic delegation agent 104 abstracts the exposed network interface(s) of the application container 106. In some examples, a hash can be generated by the dynamic delegation agent 104, the traffic analysis engine 110, and / or other devices or components used to abstract the identification information of the application container 106. The hash can be generated using different attributes associated with the application container 106 and / or service 102 as traffic sources. Attributes used to generate the hash can include, but are not limited to, MAC address, permitted time of communication with service 114, the identity of cloud service 102, the identifier of container 106, etc. Because the dynamic delegation agent 104 can be a component accessible on different containers 106, the CPU and memory resources used to run the dynamic delegation agent 104 are minimal.

[0035] Figure 2 A system 200 is illustrated that configures and uses a dynamic delegated agent 104 to help secure communications originating from different cloud services 102. (Reference) Figure 2 The dynamic delegate agent 104 is configured to send data to and receive data from different networks, such as sending data to one or more services 114A of cloud service 102A and one or more services 114B of cloud service 102B.

[0036] Depending on the configuration, one or more sidecars 204 are associated with one or more application containers 106 within a container pod, such as a container pod 202. A sidecar 204 is an application design abstraction that abstracts features such as inter-service communication, monitoring, and security from the application's main architecture. Sidecars are typically used within the service mesh control plane to manage and configure each sidecar for its associated services. Network traffic from associated services is filtered through the sidecars. The abstraction of sidecars simplifies changes to certain features handled by the sidecars without altering the rest of the application. Furthermore, if an organization is using Kubernetes (an open-source container orchestration system) or a similar system to monitor application containers 106, the application containers 106 can be grouped together within a container pod 202 sharing a common namespace.

[0037] According to some examples, compared to abstracting the interface of a single entry point, the dynamic delegation agent 104 abstracts the IoT gateway from the perspective of security attack vectors by masking the MAC address of the Wi-Fi or Ethernet NIC present in the gateway's physical interface (e.g., physical NIC card 312). In this way, the edge network interface is abstracted, and a mapping is created between different sources of incoming traffic and the application container 106. This source can be a specific source of traffic, a VPC (Virtual Private Cloud), details of the VPC's public subnet, etc. As described above, the dynamic delegation agent 104 can add entries to table 116, which includes data associated with the ingress (the app's network interface) and egress, detailing the traffic source. When an application on the IoT gateway wants to send data to the cloud service 102 it is mapped to (as shown in traffic table 116), the application container accesses the egress decision path via the dynamic delegation agent 104. The dynamic delegation agent 104 internally abstracts which cloud service it is attempting to communicate with, and the source MAC address is masked by the dynamic delegation agent 104. Similarly, if service 114 running in cloud service 102 wants to communicate with application containers running on the gateway, dynamic delegation agent 104 masks the source of the traffic by resolving it via table 116.

[0038] Based on some examples, the dynamic delegation agent 104 uses hash algorithms (e.g., Message Digest 5 (MD5), Secure Hash Algorithm (SHA), etc.) to generate hashes to abstract the physical address of the container. As an example, Hash = Function_(Src_ip, Src_VPC, Dest_URI, Timestamp, Dest_Port, Random Seed / NONCE or Unique_Container_worker_ID_based).

[0039] A separate sidecar 204 can be used to perform functions related to authorizing traffic flow to one or more containers, to visualize how each container in the same container pod operates and / or performs other functions. In system 200, dynamic delegation agent 104 can be a sidecar that communicates with other sidecar(s) 204 and containers(s) 106 and / or isolated containers(s) 206. For example, when authorized, dynamic delegation agent 104 can send traffic received from services(s) 114A and / or services(s) 114B to containers 106 and / or isolated containers 206.

[0040] In some configurations, the sidecar 204 includes the ability to route traffic to one or more containers 106 and / or one or more isolation containers 206. In some examples, when traffic analysis performed by the sidecar 204 or some other device or component determines that incoming traffic is insecure / unauthorized, incoming traffic from cloud service 102 originating from that specific source (e.g., one or more of services 114A and / or one or more of services 114B) is blocked from reaching the application container 106 to which the traffic was directed. In other configurations, incoming traffic identified as insecure or unguaranteed can be redirected to a different location, such as to one or more isolation containers 206. Isolation containers 206 can be used to store incoming traffic for a period of time and / or for further processing.

[0041] Based on some examples, more than one isolation container 206 can be used to handle traffic identified as unauthorized by the dynamic delegation agent 104. For example, the dynamic delegation agent 104 or some other device or component can identify available resources (e.g., available RAM, CPU, etc.) to determine how many isolation containers 206 to create. Rejection rules instructing traffic from a specific source to be rejected can also be stored in Table 116. See below for reference. Figure 4 In more detail, and as briefly discussed above, a micro-segmentation-based security strategy can be used to isolate all application containers 106 running on the same node from each other.

[0042] A security manager 212 can be provided to interact with the dynamic delegation agent 104. The security manager 212 can be used to configure and manage the security of communication to the container 106 via the dynamic delegation agent 104. For example, the security manager 212 can configure data indicating information such as, but not limited to, security policies, authorized services, denial-of-service, micro-segmentation policies, and isolation policies. The security manager 212 can implement a dynamic API for dynamic delegation agent configuration.

[0043] Figure 3 An IoT edge gateway node 300 is shown. As illustrated, node 300 shows a first container pod 302A, which includes containers 106A-106C, dynamic delegated agents 104A-104B, one or more isolation containers 206A, and an interface eth0 306A. Node 300 also includes a container pod 302B, which includes one or more containers 106D, one or more isolation containers 206B, and an interface eth0 306B. Although two container pods are shown, the IoT gateway node 300 may include fewer or more application container pods 302.

[0044] Depending on some configurations, interfaces 306A and 306B are coupled to virtual interfaces (Veth1 308A and Veth1 308B), which are coupled to communication components via a Container Network Interface (CNI) plugin 310. The CNI plugin 310 is a network interface that enters the container network namespace and can be used to control traffic between container pods 302 within node 300.

[0045] According to some examples, compared to abstracting the interface of a single entry point, the dynamic delegation agent 104 abstracts the IoT gateway from the perspective of security attack vectors by masking the MAC address of the Wi-Fi or Ethernet NIC present in the physical interface of the gateway (e.g., physical NIC card 312). In this way, the edge network interface is abstracted and a mapping is created between different sources of incoming traffic and application container 106.

[0046] In some configurations, a blocking micro-segmentation strategy can be used to separate different container pods from each other. Isolation containers 206 can also be used, such as (one or more) isolation containers 206A and (one or more) isolation containers 206B. Depending on some configurations, a dynamic delegation agent 104 executes a script that adds iptables rules to the network namespace of container pod 302 to create network micro-segments on (one or more) different containers 106 running on the same container pod 302. These rules can be applied to containers 106 within that specific container pod to help ensure network isolation based on analysis of traffic sources, traffic types, and / or traffic patterns.

[0047] As described above, the dynamic delegation agent 104 abstracts application containers (e.g., application container instance identifiers and exposed network interfaces) so that they can be mapped to each container application 106. Since the dynamic delegation agent 104 is a generic component accessible on the container application 106 of the container pod 302, the CPU and memory resources used to run the dynamic delegation agent 104 are minimal.

[0048] Figure 4 This is a flowchart illustrating process 400 for protecting communication with containers in a multi-cloud environment. At 402, traffic is intercepted before it is delivered to the containers within the node. As described above, traffic can originate from an external network from the application container 106 (e.g., from a cloud service, such as...). Figure 1 and Figure 2 The cloud service 102 shown receives traffic.

[0049] At 404, perform traffic analysis. In some examples, traffic analysis can be performed via traffic analysis engine 110 or via other devices or components. For example, traffic analysis can be performed by dynamic virtual delegate agent 104. In some configurations, traffic can be sent to traffic analysis engine 110 for traffic analysis.

[0050] At 406, data from traffic analysis is received. As described above, the traffic analysis performed by traffic analysis engine 110 may include the DPI of traffic received from service 114, which is hosted in cloud service 102 and / or at some other location outside application container 106. Traffic analysis engine 110 may also identify information such as the source of incoming traffic (e.g., the IP address of service 114, VPC, or some other traffic source). In some examples, traffic analysis engine 110 performs end-to-end traffic analysis, which identifies information about the different points where incoming traffic has been passed from the source to dynamic delegation agent 104. Traffic analysis engine 110 may also identify traffic patterns associated with the source, such as the frequency with which the service sends traffic to the application container, etc.

[0051] At 408, traffic table 116 is updated after confirmation. As described above, traffic table 116 may be updated in response to initial traffic analysis and / or in response to updated analysis of traffic patterns in containers. Traffic table 116 may include sources authorized to send traffic to one or more application containers 106 and / or sources not authorized to send traffic to one or more application containers 106.

[0052] At 410, it is determined whether the traffic is authorized. If the traffic is authorized to be passed to application container 106, process 400 proceeds to 412. If the traffic is not authorized to be passed to application container 106, process 400 proceeds to 414, where the traffic is passed to application container 106.

[0053] At 412, traffic is prevented from being delivered to application container 106. As mentioned above, different techniques can be used to prevent delivery. For example, the traffic can be dropped, the traffic can be redirected to an isolated container, and / or some other techniques can be used.

[0054] Figure 5 This is a flowchart illustrating a process 500 for performing traffic analysis on traffic directed to application container 1096. At 502, traffic is received for traffic analysis. As described above, traffic can be received from a dynamic delegate agent 104 that is initially capable of receiving traffic.

[0055] In the 504 error, traffic analysis engine 110 identifies information about the incoming traffic, such as the source of the incoming traffic, the traffic pattern, and other information. For example, in some examples, traffic analysis engine 110 can perform end-to-end analysis of the traffic.

[0056] At 506, dynamic proxy mappings can be generated for traffic. As described above, the network interface associated with application container 106 is abstracted, and mappings are created between different sources of incoming traffic and application container 106. This source can be a specific source of traffic, a VPC (Virtual Private Cloud), details of the VPC's public subnet, etc. In some examples, dynamic proxy 104 can add entries to table 116, which includes data associated with the ingress (the app's network interface) and egress, detailing the traffic source. When an application on the IoT gateway wants to send data to the cloud service 102 it is mapped to (as shown in traffic table 116), the application container accesses the egress decision path via dynamic proxy 104. Dynamic proxy 104 internally abstracts which cloud service it is attempting to communicate with, and the source MAC address is masked by dynamic proxy 104. Similarly, if a service 114 running in cloud service 102 wants to communicate with an application container running on the gateway, dynamic proxy 104 masks the source of the traffic source by resolving through table 116.

[0057] At 508, dynamic proxy mappings, traffic, and other traffic information can be sent to dynamic delegate 104 for further processing. For example, dynamic delegate 104 can pass traffic, prevent traffic from being passed to application container 106, send traffic to isolation container 206, and / or perform some other actions / operations.

[0058] Figure 6 An example computer architecture is shown for a computer 600 capable of executing program components for achieving the above-described functions. Figure 6 The computer architectures shown illustrate the architecture of server computers, workstations, desktop computers, laptops, tablets, network devices, e-readers, smartphones, network switches, or other computing devices, and can be used to execute any of the software components described herein. In some examples, computer 600 may correspond to the network infrastructure devices discussed herein.

[0059] Computer 600 includes a baseboard 602 or “motherboard,” which may be a printed circuit board to which multiple components or devices may be connected via a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (“CPU”) 604 operate in conjunction with a chipset 606. CPU 604 may be a standard programmable processor, for example, one necessary for performing arithmetic and logic operations required for the operation of computer 600.

[0060] The CPU 604 performs operations by manipulating switching elements to transition from one discrete physical state to the next, these switching elements distinguishing and changing these states. Switching elements typically include electronic circuitry, such as flip-flops, that holds one of two binary states, and electronic circuitry, such as logic gates, that provides the output state based on a logical combination of the states of one or more other switching elements. These basic switching elements can be combined to create more complex logic circuits, including registers, adder-subtractor units, arithmetic logic units, floating-point units, and so on.

[0061] Chipset 606 provides an interface between CPU 604 and the remaining components and devices on substrate 602. Chipset 606 can provide an interface to RAM 608, which serves as the main memory in computer 600. Chipset 606 can also provide an interface to a computer-readable storage medium, such as read-only memory (“ROM”) 610 or non-volatile RAM (“NVRAM”), which stores basic routines that help boot computer 600 and transfer information between various components and devices. ROM 610 or NVRAM can also store other software components required for the operation of computer 600, as configured herein. Figure 6 As shown, ROM 610 or NVRAM may also store data that computer 600 can use to generate and / or process authentication information in messages exchanged between computer 600 and other devices. In other examples, this data may be stored elsewhere, such as in RAM 608.

[0062] Computer 600 can operate in a networked environment using logical connections to remote computing devices and computer systems via a network. For example, chipset 606 may include the ability to provide network connectivity via a network interface controller (NIC) 612 (e.g., a Gigabit Ethernet adapter). NIC 612 can connect computer 600 to other computing devices via a network. It should be understood that multiple NICs 612 may exist in computer 600, connecting the computer to other types of networks and remote computer systems. In some cases, NIC 612 may include at least one input port and / or at least one output port. Input / output controllers 616 may be provided for other types of input / output.

[0063] Computer 600 can be connected to storage device 618, which provides non-volatile storage for the computer. For example, storage device 618 can store operating system 620, programs 622, and data 624. Storage device 618 can be connected to computer 600 via storage controller 614 connected to chipset 606. Storage device 618 may include one or more physical storage units. Storage controller 614 can interface with physical storage units via a Serial Attached SCSI (“SAS”) interface, a Serial Advanced Technology Attachment (“SATA”) interface, a Fibre Channel (“FC”) interface, or other types of interfaces used for physical connection and data transfer between the computer and physical storage units. Data 624 may include, for example, dynamically mapped proxy data.

[0064] Computer 600 can store data on storage device 618 by transforming the physical state of physical storage units to reflect the stored information. In different embodiments of this specification, the specific transformation of the physical state can depend on various factors. Examples of these factors may include, but are not limited to, the technology used to implement the physical storage units, whether storage device 618 is characterized as primary or secondary storage, etc. For example, computer 600 can issue instructions via storage controller 614 to store information in storage device 618 by changing the magnetic properties of a specific location within a disk drive unit, the reflection or refraction properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of this description; the foregoing examples are provided merely for ease of description. Computer 600 can also read information from storage device 618 by detecting the physical state or characteristics of one or more specific locations within the physical storage units.

[0065] In addition to the aforementioned storage device 618, computer 600 may access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data, including data used to generate and / or process authentication information. Those skilled in the art will understand that a computer-readable storage medium is any available medium that provides non-transitory storage of data and can be accessed by computer 600.

[0066] Although this disclosure describes specific examples, it should be understood that the scope of this disclosure is not limited to these specific examples. Since other modifications and variations made to suit specific operational requirements and environments will be apparent to those skilled in the art, this disclosure is not limited to the examples chosen for the purposes of this disclosure, but covers all changes and modifications that do not depart from the true spirit and scope of this disclosure.

[0067] Although this application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Rather, the specific features and actions are merely illustrative of some embodiments falling within the scope of the claims of this application.

Claims

1. A method for protecting communication of an application container, comprising: Traffic directed to the application container is received from a source within the cloud service at the dynamic delegation agent. The application container is hosted outside the cloud service, and the network interface associated with the application container is abstracted from the source. Perform traffic analysis on the traffic; Based at least in part on the traffic analysis, determine the actions associated with delivering the traffic to the application container; Generate a dynamic proxy mapping between the source and the application container, wherein generating the dynamic proxy mapping abstracts the network interface associated with the application container; and The traffic is processed, wherein processing the traffic causes at least one of the following: the traffic is delivered to the application container, or the traffic is prevented from being delivered to the application container.

2. The method according to claim 1, wherein, Performing the traffic analysis includes sending the traffic to a traffic analysis engine, and wherein the generation of the dynamic proxy mapping is performed by the traffic analysis engine.

3. The method according to claim 1 or 2, wherein, The network interface is at least one of a WIFI interface or an Ethernet interface, and the application container is one of a plurality of application containers associated with an application container pod.

4. The method according to claim 1 or 2, further comprising: Create a sidecar container associated with the application container; as well as One or more rules are added to the network namespace of the application container pod that includes the application container, wherein the one or more rules create network micro-segments on multiple application containers running on the application container pod.

5. The method according to claim 1 or 2, wherein, The application container is hosted by an Internet of Things (IoT) gateway node.

6. The method according to claim 1 or 2, wherein, Preventing the traffic from being delivered to the application container includes sending the traffic to an isolation container.

7. The method of claim 1 or 2, further comprising updating data indicating whether the traffic is authorized before being transmitted to the application container, and wherein, Processing the traffic includes at least partially delivering the traffic to the application container based on the data.

8. A system for protecting the communication of an application container, comprising: One or more processors; as well as One or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform the following operations: Traffic is received from a source at a first network location and directed to the application container, which is hosted at a second network location, wherein the network interface associated with the application container is abstracted from the source. Perform traffic analysis on the traffic; Based at least in part on the traffic analysis, determine the actions associated with delivering the traffic to the application container; Generate a dynamic proxy mapping between the source and the application container, wherein generating the dynamic proxy mapping abstracts the network interface associated with the application container; and The traffic is processed, wherein processing the traffic causes at least one of the following: the traffic is delivered to the application container, or the traffic is prevented from being delivered to the application container.

9. The system according to claim 8, wherein, Performing the traffic analysis includes sending the traffic to a traffic analysis engine, and wherein the generation of the dynamic proxy mapping is performed by the traffic analysis engine.

10. The system according to claim 8 or 9, wherein, The network interface is at least one of a WIFI interface or an Ethernet interface, and the application container is one of a plurality of application containers associated with an application container pod.

11. The system according to claim 8 or 9, wherein the operation further comprises: Create a sidecar container associated with the application container; as well as One or more rules are added to the network namespace of the application container pod that includes the application container, wherein the one or more rules create network micro-segments on multiple application containers running on the application container pod.

12. The system according to claim 8 or 9, wherein, The application container is hosted by an Internet of Things (IoT) gateway node.

13. The system according to claim 8 or 9, wherein, Preventing the traffic from being delivered to the application container includes sending the traffic to an isolation container.

14. The system of claim 8 or 9, further comprising updating data indicating whether the traffic is authorized and transmitting it to the application container, wherein, Processing the traffic includes at least partially delivering the traffic to the application container based on the data.

15. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by one or more processors, cause the one or more processors to perform the following operations: Traffic is received from a source at a first network location and directed to an application container, which is hosted at a second network location, wherein... The network interface associated with the application container is abstracted from the source; Perform traffic analysis on the traffic; Based at least in part on the traffic analysis, determine the actions associated with delivering the traffic to the application container; Generate a dynamic proxy mapping between the source and the application container, wherein generating the dynamic proxy mapping abstracts the network interface associated with the application container; and The traffic is processed, wherein processing the traffic causes at least one of the following: the traffic is delivered to the application container, or the traffic is prevented from being delivered to the application container.

16. The non-transitory computer-readable medium according to claim 15, wherein, Performing the traffic analysis includes sending the traffic to a traffic analysis engine, and wherein the generation of the dynamic proxy mapping is performed by the traffic analysis engine.

17. The non-transitory computer-readable medium according to claim 15 or 16, further comprising: Create a sidecar container associated with the application container; as well as One or more rules are added to the network namespace of the application container pod that includes the application container, wherein the one or more rules create network micro-segments on multiple application containers running on the application container pod.

18. The non-transitory computer-readable medium according to claim 15 or 16, wherein, Preventing the traffic from being delivered to the application container includes sending the traffic to an isolation container.

19. The non-transitory computer-readable medium of claim 15 or 16, further comprising updating data indicating whether the traffic is authorized before being transmitted to the application container, and wherein, Processing the traffic includes at least partially delivering the traffic to the application container based on the data.

20. An apparatus for protecting the communications of an application container, comprising: A module for receiving traffic directed to the application container from a source within the cloud service at a dynamic delegation agent, the application container being hosted outside the cloud service, wherein the network interface associated with the application container is abstracted from the source. A module for performing traffic analysis on the traffic; A module for determining, at least in part, the actions associated with delivering the traffic to the application container based on the traffic analysis; A module for generating a dynamic proxy mapping between the source and the application container, wherein generating the dynamic proxy mapping abstracts the network interface associated with the application container; and A module for processing the traffic, wherein processing the traffic causes at least one of the following: delivering the traffic to the application container, or preventing the traffic from being delivered to the application container.

21. The apparatus of claim 20, further comprising a module for implementing the method of any one of claims 2 to 7.

22. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 7.

Images