EP4364388A1 - Dynamic proxy response to application container - Google Patents
Dynamic proxy response to application containerInfo
- Publication number
- EP4364388A1 EP4364388A1 EP22744040.1A EP22744040A EP4364388A1 EP 4364388 A1 EP4364388 A1 EP 4364388A1 EP 22744040 A EP22744040 A EP 22744040A EP 4364388 A1 EP4364388 A1 EP 4364388A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- traffic
- application container
- application
- container
- dynamic proxy
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000004044 response Effects 0.000 title description 5
- 238000004458 analytical method Methods 0.000 claims abstract description 73
- 238000000034 method Methods 0.000 claims abstract description 41
- 238000012545 processing Methods 0.000 claims description 17
- 238000013507 mapping Methods 0.000 claims description 14
- 230000009471 action Effects 0.000 claims description 5
- 238000004590 computer program Methods 0.000 claims 2
- 238000004891 communication Methods 0.000 abstract description 30
- 239000003795 chemical substances by application Substances 0.000 description 72
- 230000008569 process Effects 0.000 description 9
- 206010047289 Ventricular extrasystoles Diseases 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000007689 inspection Methods 0.000 description 3
- 230000000873 masking effect Effects 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000011218 segmentation Effects 0.000 description 3
- 238000001152 differential interference contrast microscopy Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 238000005129 volume perturbation calorimetry Methods 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 1
- 239000003990 capacitor Substances 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 239000000523 sample Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0263—Rule management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
- G16Y10/00—Economic sectors
- G16Y10/75—Information technology; Communication
Definitions
- the present disclosure relates generally to techniques for securing communication to containers in a cloud environment.
- Enterprises are moving to different cloud models, such as hybrid clouds, multi-clouds, and connected cloud networks.
- cloud models such as hybrid clouds, multi-clouds, and connected cloud networks.
- IoT internet of things
- Edge Computing Hardware for performing various processing functions and integrating with different instances of cloud services.
- the mode of communication for the application containers uses a publish-subscribe communication method, or some type of client-broker communication method, such as Message Queue Telemetry Transport (MQTT).
- MQTT Message Queue Telemetry Transport
- Securing communications to application containers that may be in different public/private networks can be challenging. For example, application containers in a multi-cloud environment cannot be secured 100% just by using an Access Control List (ACL) or an IP Network Address Translation (NAT).
- ACL Access Control List
- NAT IP Network Address Translation
- FIG. 1 illustrates a system that uses a dynamic proxy agent to help secure communications to application containers in a multi-cloud environment.
- FIG. 2 illustrates a system to configure and use a dynamic proxy agent to help secure communications originating from different cloud services.
- FIG. 3 illustrates an IoT edge gateway node that uses a dynamic proxy agent to secure communications.
- FIG. 4 is a flowchart illustrating a process for securing communications to application containers in a multi-cloud environment.
- FIG. 5 is a flowchart illustrating a process for performing traffic analysis of traffic directed to an application container.
- FIG. 6 illustrates an example computer architecture for a computer capable of executing program components for implementing the functionality described herein.
- This disclosure describes techniques for using a dynamic proxy for securing communications between a source within a cloud environment and an application container.
- the techniques include intercepting traffic directed to an application container, analyzing the traffic and traffic patterns, and allowing or preventing the traffic from being delivered to the application container based on the analysis.
- the address(es) to the network interfaces e.g., WIFI or EthO
- WIFI or EthO are abstracted to help ensure security of the application containers.
- Cloud-native applications comprising multiple “microservice” applications supported by a service mesh, are becoming more widely used. Instances of the microservice applications may be hosted at different locations, and the microservice applications instances may communicate with each other over one or more networks, such as software-defined wide-area networks SD-WANs.
- a cloud-native application is a collection of small, independent, and loosely coupled services.
- many cloud-native applications employ a microservice architecture.
- an application is typically built as a single deployable unit.
- a microservice architecture a complex system may be split into multiple independent, narrowly focused services, each with its own isolated business logic and data store.
- services of the cloud-native application may be distributed across different cloud environments including one or more public cloud environments, and one or more private networks.
- any service can be scaled and deployed separately.
- a service mesh may be utilized to control how the microservices and other parts of an application share data with one another.
- a service mesh is a dedicated configurable infrastructure layer built right into an application, typically designed to handle a high volume of network-based inter-process communication using application programming interfaces (APIs).
- APIs application programming interfaces
- the service mesh may provide capabilities such as service discovery, load balancing and encryption.
- the service mesh may be implemented by providing a proxy instance, called a sidecar, for each microservice application instance. Sidecars may manage interservice communication over the SD-WAN, monitoring, and security related concerns and/or other functions that may be abstracted away from the individual microservice application instances.
- a cloud environment such as a multi-cloud environment
- microservices and application containers hosted on the Internet of Things (IoT) Gateways or on the Edge Computing Hardware for performing various processing functions and integrating with different instances of cloud services.
- IoT Internet of Things
- MQTT client-broker communication method
- the application container is mapped and tied to physical network or virtual network interfaces (e.g.
- a dynamic proxy agent helps to secure communications to containers, such as one or more application containers that are hosted on an IoT gateway, on edge computing hardware, or at some other location.
- the dynamic proxy agent may receive incoming traffic from different services located in one or more cloud services and determine whether to allow the traffic to be delivered to an application container or prevent the traffic from being delivered.
- a traffic analysis engine may perform an analysis of the traffic and/or traffic patterns directed to the application container is performed.
- the traffic analysis engine may perform a deep packet inspection of the traffic and may identify information such as a source of the incoming traffic (e.g., a microservice, a Virtual Private Cloud (VPC), ...), an end-to-end traffic analysis that identifies information the different points the incoming traffic has passed from the source to the dynamic proxy agent, patterns identified that are associated with the source (e.g., how often does the source send traffic to an application container), and the like.
- a virtual probe e.g., in a webhook server
- the traffic analysis engine may determine whether the traffic is considered safe and is to be allowed to be delivered to the application container, or whether the traffic is considered unsafe and is to be prevented from being delivered to the application container. Many different techniques may be used to determine whether or not the incoming traffic to the container is safe, such as but not limited to: Is the source of the traffic from a trusted network?; Has the traffic passed through any points that are unsecure?; Has the application container received traffic from this source before?; and the like. If the traffic analysis engine does not identify security threat(s) or any other anomalies are discovered, then the source of the traffic may be authorized and allowed to send data, via the dynamic proxy agent, to the application container.
- data indicating whether traffic is authorized and/or unauthorized is maintained by the dynamic proxy agent.
- the dynamic proxy agent may maintain a traffic table/list that includes entries identifying the sources for authorized traffic and/or identifying the sources for unauthorized traffic.
- the traffic table may include an entry that indicates to allow traffic from a particular source IP address (or some other identifier), that is directed to a particular application container(s) within a pod.
- traffic received from the source may be restricted to particular time frames (e.g., 12PM - 3PM, 6AM - 5PM, .
- any further traffic that is received by the dynamic traffic agent from that source may be allowed without further inspection.
- a traffic analysis may be performed each time traffic is received, and/or at some other interval or in response to some event/condition.
- the traffic analysis engine determines that the incoming traffic is unsecure, the incoming traffic from that specific source (e.g., microservice and/or virtual private network (VPN)) originating from a cloud service is blocked from being delivered to the application container.
- incoming traffic that is identified as unsecure may be redirected to a different location, such as a quarantine worker container.
- a micro segmentation based security policy may be used to isolate application containers from each other which are running on the same node.
- the dynamic proxy agent may also abstract the network interface details to access application containers. In this way, the network interface details for the application containers are not exposed when communicating with services in different clouds and or at other network locations. In some configurations, a hash value may be used to abstract the network interface details for the containers secured by the dynamic proxy agent.
- the dynamic proxy agent may also abstract an identifier of the application containers in addition to the exposed network interfaces. In contrast to existing techniques, the dynamic proxy agent as described herein can abstract the IoT gateways from a security attack vector perspective by masking the MAC Address of the WIFI or ethernet NIC that is present in the IoT gateway's physical interface.
- FIG. 1 illustrates a system 100 that uses a dynamic proxy agent 104 to help secure communications to containers 106 in a multi-cloud environment.
- cloud service 102A and cloud service 102B communicate with application containers 106A-106H via dynamic proxy agents 104A-104B (as illustrated by the solid lines between the service(s) 114A and 114B and the dynamic proxy agents 104A and 104B) instead of direct communication to the application containers (as illustrated by the dashed lines) as in prior techniques.
- a cloud environment such as a multi -cloud environment as illustrated in FIG.
- IoT Gateways/nodes 108 there are often different microservices and application containers 106 hosted on Internet of IoT Gateways/nodes 108 for performing various processing functions and integrating with different services 114 in cloud services 102. See FIG. 3 and related discussion for an example IoT gateway node.
- a dynamic proxy agent 104 such as dynamic proxy agent 104A and dynamic proxy agent 104B can be used to help secure communications to a container, such as application containers 106A-106D hosted by IoT gateway 108A and application containers 106E-106H that are hosted by IoT gateway 108B.
- a dynamic proxy agent 104 is used by the service(s) 114 to securely communicate with the application containers 106.
- a dynamic proxy agent 104 receives the incoming traffic and causes traffic analysis to be performed.
- the dynamic proxy agent 104 sends the incoming traffic to a traffic analysis engine 110 to perform traffic analysis.
- the traffic analysis engine 110 may be a webhook server which uses a virtual probe for traffic monitoring. While traffic analysis engine 110A is shown separately from dynamic proxy agent 104 A, the traffic analysis engine 110A may be part of the dynamic proxy agent 104 A.
- operations of the dynamic proxy agent 104 A may be performed within a primary node agent, such as within a kubelet in the Kubemetes as a traffic engineering probe.
- traffic analysis engine 110 is shown separate from the dynamic proxy agent 104, some/all of the functionality of the traffic analysis engine may be performed by the dynamic proxy agent.
- a traffic analysis engine 110 may perform a traffic analysis to determine whether traffic received from a service 114 is considered safe and is to be allowed to be delivered to the application container 106, or whether the traffic is considered unsafe and is to be prevented from being delivered to the application container.
- traffic analysis engine 110A and traffic analysis engine 110B may perform a traffic analysis to determine whether traffic received from a service 114 is considered safe and is to be allowed to be delivered to the application container 106, or whether the traffic is considered unsafe and is to be prevented from being delivered to the application container.
- many different techniques may be used to determine whether or not the incoming traffic to the container is safe, such as but not limited to: Is the source of the traffic from a trusted network?; Has the traffic passed through any points that are unsecure?; Has the application container received traffic from this source before?; and the like.
- the traffic analysis engine 110 may perform a deep packet inspection (DPI) of the traffic received from a service 114 that is hosted in a cloud service 102 and/or at some other location that is external from the application containers 106.
- the traffic analysis engine 110 may identify information such as a source of the incoming traffic (e.g., the IP address of the service 114, VPC, or some other source of the traffic).
- the traffic analysis engine 110 performs an end-to-end traffic analysis that identifies information the different points the incoming traffic has passed from the source to the dynamic proxy agent 104 A.
- the traffic analysis engine 110 may also identify traffic patterns that are associated with the source such as how often does the service send traffic to an application container, and the like.
- the traffic analysis engine 110 may learn the communication patterns from the application containers 106 to external networks, such as between IoT gateway 108A and/or 108B and cloud service 102 A and/or cloud service 102B.
- the traffic communication patterns may be to specific services 114, to VPCs hosted by a cloud service, and/or to some other external source of traffic.
- the dynamic proxy agent 104 creates a traffic table 116, such as traffic table 116A and traffic table 116B that maps sources, such as in cloud service 102A and/or 102B, learned over time.
- the dynamic proxy agent 104A stores entries into the table to indicate whether traffic is allowed to the container and/or whether traffic is unauthorized to be delivered to the container.
- the service 114 may be authorized to send data, via the dynamic proxy agent 104, to the application container 106 to which the traffic is directed.
- data indicating whether traffic is authorized and/or unauthorized is maintained by the dynamic proxy agent 104.
- the dynamic proxy agent 104 may maintain a traffic table/list 116 that includes entries identifying the sources for authorized traffic and/or identifying the sources for unauthorized traffic.
- the traffic table 116 may include an entry that indicates to allow traffic from a particular source IP address (or some other identifier), that is directed to a particular container(s) within a pod.
- traffic from the source may be authorized for delivery at certain times and prevented at other times (e.g., allow from 8AM - 5PM and restrict between 5PM-8AM).
- the traffic table 116 may be updated based on traffic patterns detected over time and/or traffic analysis performed at different times.
- the dynamic proxy agent 104 may abstract identifying information for the application containers 106.
- the dynamic proxy agent 104 abstracts the exposed network interface(s) of the application containers 106.
- a hash may be generated by the dynamic proxy agent 104, the traffic analysis engine 110, and/or some other device or component used to abstract the identifying information for the application container 106.
- the hash may be generated using different attributes associated with the application container 106 and/or the service 102 which is the source of the traffic.
- the attributes for generating the hash may include but are not limited to a MAC address, a time which communication with the service 114 are allowed, an identity of the cloud service 102, an identifier of the container 106, and the like. Since the dynamic proxy agent 104 may be component accessible across different containers 106, the CPU & Memory resources used to run the dynamic proxy agent 104 are minimal.
- FIG. 2 illustrates a system 200 to configure and use a dynamic proxy agent 104 to help secure communications originating from different cloud services 102.
- dynamic proxy agent 104 is configured to send and receive data to/ from different networks, such as to service(s) 114A of cloud service 102A and service(s) 114B of cloud service 102B.
- one or more sidecars 204 are associated with application container(s) 106 that are within a pod, such as pod 202.
- a sidecar 204 is an application design abstraction, which may abstract features such as inter-service communications, monitoring and security, away from a main architecture of an application.
- Sidecars are typically used within a service mesh control plane, to manage and configure each sidecar in relation to its associated service. Network traffic from the associated service is filtered through the sidecar.
- the abstraction of the sidecar may ease changing certain features, handled by the sidecar, without changing the rest of the application.
- Kubernetes an open-source container-orchestration system
- the application containers 106 can be grouped together in a pod 202 that shares a common namespace.
- the dynamic proxy agent 104 abstracts the IoT gateways from a security attack vector perspective by masking the MAC Address of the WIFI or ethernet NIC that is present in the gateway's physical interface, such as the physical NIC card 312.
- the edge network interface is abstracted and a mapping is created between the different sources of incoming traffic and the application containers 106.
- the source may be a particular source of the traffic, a VPC (Virtual Private Cloud), VPC's public subnet details, and the like.
- the dynamic proxy agent 104 may add entries to the table 116 that includes data associated with the ingress (App's Network Interface) and the egress being the details of the source of the traffic.
- an application on an IoT gateway wants to send data to a cloud service 102 to which it is mapped (as indicated in the traffic table 116)
- the application container accesses the egress decision path via the dynamic proxy agent 104.
- the dynamic proxy agent 104 internally abstracts as to which cloud service is trying to communicate to and the source MAC address is masked by the dynamic proxy agent 104.
- a service 114 running in the cloud service 102 wants to communicate with an application container running on a gateway, then the dynamic proxy agent 104 masks the source of origination of that traffic by parsing through the table 116.
- the dynamic proxy agent 104 generates a hash using a hashing algorithm (e.g., message digest 5 (MD5), secure hash algorithm (SHA), (7) to abstract the physical address of the container.
- a hashing algorithm e.g., message digest 5 (MD5), secure hash algorithm (SHA), (7) to abstract the physical address of the container.
- Hash Function_ (Src_ip,Src_VPC, Dest URI, Timestamp, Dest Port, Random Seed/NONCE or Unique_Container_worker_ID_based)
- a separate sidecar 204 can be used to perform functionality relating to authorizing traffic to flow to one or more containers and the like visualize how each container in the same pod is operating and/or perform other functionality.
- the dynamic proxy agent 104 may be a sidecar that communicates with other sidecar(s) 204 and the container(s) 106 and/or the quarantine container(s) 206.
- the dynamic proxy agent 104 may send traffic received from service(s) 114A and/or service(s) 114B to container(s) 106 and/or the quarantine container(s) 206 when authorized.
- a sidecar 204 includes functionality to route the traffic to the container(s) 106 and/or the quarantine container(s) 206.
- the traffic analysis performed by a sidecar 204, or some other device or component determines that the incoming traffic is unsafe/unauthorized, the incoming traffic from that specific source (e.g., one or more of service(s) 114A and/or service(s) 114B) from a cloud service 102 is blocked from being delivered to the application container 106 to which the traffic is directed.
- incoming traffic that is identified as unsafe or unsecure may be redirected to a different location, such as to a quarantine container(s) 206.
- a quarantine container 206 may be used to store incoming traffic for a period of time and/or for further processing.
- more than one quarantine container 206 may be used to process traffic that is identified by the dynamic proxy agent 104 as being unauthorized.
- the dynamic proxy agent 104 or some other device or component can identify available resources (e.g., available RAM, CPU, ...) to determine how many quarantine container(s) 206 to create.
- a deny rule indicating to deny traffic from the particular source may also be stored within the table 116.
- a micro-segmentation based security policy may be used to isolate the application containers 106 from each other which are all running on the same node.
- a security manager 212 can be provided for interacting with a dynamic proxy agent 104.
- the security manager 212 may be used for configuring and managing the security of communications to containers 106 via the dynamic proxy agent 104.
- the security manager 212 may configure data indicating information such as but not limited to, security policies, authorized services, denied services, micro- segmentation policies, quarantine policies, and the like.
- the security manager 112 may implement dynamic APIs for dynamic proxy agent configuration.
- FIG. 3 illustrates an IoT edge gateway node 300.
- node 300 shows a first pod 302A that includes containers 106A - 106C, dynamic proxy agents 104A - 104B, quarantine container(s) 206 A, and interface ethO 306A.
- Node 300 also includes pod 302B that includes container(s) 106D, quarantine container(s) 206B, and interface ethO 306B. While two pods are illustrated, the IoT gateway node 300 may include fewer or more application pods 302.
- the interface 306A and interface 306B are coupled to a virtual interface (Vethl 308A and Vethl 308B) that are coupled to communications via the container network interface (CNI) plugin 310.
- the CNI plugin 310 is a network interface into the container network namespace that can be used to control traffic between the pods 302 in the node 300.
- the dynamic proxy agent 104 abstracts the IoT gateways from a security attack vector perspective by masking the MAC Address of the WIFI or ethernet NIC that is present in the gateway's physical interface, such as the physical NIC card 312. As such, the edge network interface is abstracted and a mapping is created between the different sources of incoming traffic and the application containers 106.
- a blocking micro segmentation policy may be used to segment the different pods from each other. Quarantine containers 206, such as quarantine container(s) 206A and quarantine container(s) 206B may also be used.
- the dynamic proxy agent 104 executes a script that adds the iptables rules to the network namespace of the pod 302 to create network microsegmentation across the different container(s) 106 running on the same pod 302. These rules may be applied to the containers 106 in that specific pod to help ensure network isolation based on the analysis of the source of traffic, type of traffic and/or the pattern of traffic.
- the dynamic proxy agent 104 abstracts the application container (e.g., the application containers instance identifier along with the exposed network interfaces so that they can be mapped to each container application 106. Since the dynamic proxy agent 104 is a common component that is accessible across the container applications 106 of a pod 302, the CPU and memory resources used to run the dynamic proxy agent 104 are minimal.
- the application container e.g., the application containers instance identifier along with the exposed network interfaces so that they can be mapped to each container application 106. Since the dynamic proxy agent 104 is a common component that is accessible across the container applications 106 of a pod 302, the CPU and memory resources used to run the dynamic proxy agent 104 are minimal.
- FIG. 4 is a flowchart illustrating a process 400 for securing communications to containers in a multicloud environment.
- the traffic is intercepted before delivery to a container within a node.
- the traffic may be received from an external network from the application container 106, such as from a cloud service, such as cloud service 102 as illustrated in FIG. 1 and FIG. 2.
- traffic analysis is performed.
- the traffic analysis may be performed by a traffic analysis engine 110, or by some other device or component.
- the traffic analysis may be performed by the dynamic virtual proxy agent 104.
- the traffic is sent to the traffic analysis engine 110 for traffic analysis.
- the traffic analysis may include a DPI of the traffic received from a service 114 that is hosted in a cloud service 102 and/or at some other location that is external from the application containers 106.
- the traffic analysis engine 110 may also identify information such as a source of the incoming traffic (e.g., the IP address of the service 114, VPC, or some other source of the traffic).
- the traffic analysis engine 110 performs an end-to-end traffic analysis that identifies information the different points the incoming traffic has passed from the source to the dynamic proxy agent 104.
- the traffic analysis engine 110 may also identify traffic patterns that are associated with the source such as how often does the service send traffic to an application container, and the like
- the traffic table 116 is updated when determined. As discussed above, the traffic table 116 may be updated in response to an initial traffic analysis and/or updated in response to an updated analysis of traffic patterns to the container.
- the traffic table 116 may include sources that are authorized to send traffic to one or more application containers 106 and/or sources that are unauthorized from sending traffic to one or more application containers 106.
- the traffic is prevented from being delivered to the application container 106.
- different techniques may be used to prevent delivery. For example, the traffic may be discarded, the traffic may be redirected to a quarantine container, and/or some other technique may be used.
- FIG. 5 is a flowchart illustrating a process 500 for performing traffic analysis of traffic directed to an application container 1096.
- the traffic is received for traffic analysis.
- the traffic may be received from a dynamic proxy agent 104 to which can initially receive the traffic.
- the traffic analysis engine 110 identifies information about the incoming traffic such as a source of the incoming traffic, traffic patterns, as well as other information. For instance, in some examples, the traffic analysis engine 110 may perform an end-to-end analysis of the traffic.
- a dynamic proxy mapping may be generated for the traffic.
- the network interface associated with an application container 106 is abstracted and a mapping is created between the different sources of incoming traffic and the application container 106.
- the source may be a particular source of the traffic, a VPC (Virtual Private Cloud), VPC's public subnet details, and the like.
- the dynamic proxy agent 104 may add entries to the table 116 that includes data associated with the ingress (App's Network Interface) and the egress being the details of the source of the traffic.
- the application container accesses the egress decision path via the dynamic proxy agent 104.
- the dynamic proxy agent 104 internally abstracts as to which cloud service is trying to communicate to and the source MAC address is masked by the dynamic proxy agent 104.
- the dynamic proxy agent 104 masks the source of origination of that traffic by parsing through the table 116 [0054]
- the dynamic proxy mapping, traffic, and other traffic information may be sent to the dynamic proxy agent 104 for further processing.
- the dynamic proxy agent 104 may deliver the traffic, prevent the traffic from being delivered to the application container 106, send the traffic to a quarantine container 206 and/or perform some other action/operation.
- FIG. 6 illustrates an example computer architecture for a computer 600 capable of executing program components for implementing the functionality described above.
- the computer architecture shown in FIG. 6 illustrates an architecture of a server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, network switch, or other computing device, and can be utilized to execute any of the software components presented herein.
- the computer 600 may, in some examples, correspond to a network infrastructure device discussed herein.
- the computer 600 includes a baseboard 602, or “motherboard,” which may be a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths.
- a baseboard 602 or “motherboard”
- the CPUs 604 can be, for example, standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer 600.
- the CPUs 604 perform operations by transitioning from one discrete, physical state to the next through the manipulation of switching elements that differentiate between and change these states.
- Switching elements generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide an output state based on the logical combination of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adders-subtractors, arithmetic logic units, floating-point units, and the like.
- the chipset 606 provides an interface between the CPUs 604 and the remainder of the components and devices on the baseboard 602.
- the chipset 606 can provide an interface to a RAM 608, used as the main memory in the computer 600.
- the chipset 606 can further provide an interface to a computer-readable storage medium such as a read-only memory (“ROM”) 610 or non-volatile RAM (“NVRAM”) for storing basic routines that help to startup the computer 600 and to transfer information between the various components and devices.
- ROM read-only memory
- NVRAM non-volatile RAM
- the ROM 610 or NVRAM can also store other software components necessary for the operation of the computer 600 in accordance with the configurations described herein.
- the ROM 610 or NVRAM can also store data usable by the computer 600 to generate and/or process attestation information in messages exchanged among the computer 600 and other devices. In other examples, this data may be stored elsewhere, such as in RAM 608.
- the computer 600 can operate in a networked environment using logical connections to remote computing devices and computer systems through a network.
- the chipset 606 can include functionality for providing network connectivity through a Network Interface Controller (NIC) 612, such as a gigabit Ethernet adapter.
- NIC Network Interface Controller
- the NIC 612 can connect the computer 600 to other computing devices over a network. It should be appreciated that multiple NICs 612 can be present in the computer 600, connecting the computer to other types of networks and remote computer systems.
- the NICs 612 may include at least one ingress port and/or at least one egress port.
- An input/output controller 616 may be provided for other types of input/output.
- the computer 600 can be connected to a storage device 618 that provides non-volatile storage for the computer.
- the storage device 618 can store an operating system 620, programs 622, and data 624, for example.
- the storage device 618 can be connected to the computer 600 through a storage controller 614 connected to the chipset 606.
- the storage device 618 can include one or more physical storage units.
- the storage controller 614 can interface with the physical storage units through a serial attached SCSI (“SAS”) interface, a serial advanced technology attachment (“SATA”) interface, a fiber channel (“FC”) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.
- the data 624 may include, for example, dynamic proxy mapping data.
- the computer 600 can store data on the storage device 618 by transforming the physical state of the physical storage units to reflect the information being stored.
- the specific transformation of physical state can depend on various factors, in different embodiments of this description. Examples of such factors can include, but are not limited to, the technology used to implement the physical storage units, whether the storage device 618 is characterized as primary or secondary storage, and the like.
- the computer 600 can store information to the storage device 618 by issuing instructions through the storage controller 614 to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit.
- the computer 600 can further read information from the storage device 618 by detecting the physical states or characteristics of one or more particular locations within the physical storage units.
- the computer 600 can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data, including data to generate and/or process attestation information.
- computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer 600.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Environmental & Geological Engineering (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/304,891 US11689505B2 (en) | 2021-06-28 | 2021-06-28 | Dynamic proxy response from application container |
PCT/US2022/034501 WO2023278211A1 (en) | 2021-06-28 | 2022-06-22 | Dynamic proxy response to application container |
Publications (1)
Publication Number | Publication Date |
---|---|
EP4364388A1 true EP4364388A1 (en) | 2024-05-08 |
Family
ID=82608332
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP22744040.1A Pending EP4364388A1 (en) | 2021-06-28 | 2022-06-22 | Dynamic proxy response to application container |
Country Status (4)
Country | Link |
---|---|
US (2) | US11689505B2 (zh) |
EP (1) | EP4364388A1 (zh) |
CN (1) | CN117597903A (zh) |
WO (1) | WO2023278211A1 (zh) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11115356B2 (en) * | 2019-11-14 | 2021-09-07 | Woofy, Inc. | Emoji recommendation system and method |
US11812362B2 (en) * | 2021-03-01 | 2023-11-07 | Juniper Networks, Inc. | Containerized router with a disjoint data plane |
US11689505B2 (en) | 2021-06-28 | 2023-06-27 | Cisco Technology, Inc. | Dynamic proxy response from application container |
US11785115B2 (en) * | 2021-09-27 | 2023-10-10 | International Business Machines Corporation | Request tracing |
US11936785B1 (en) | 2021-12-27 | 2024-03-19 | Wiz, Inc. | System and method for encrypted disk inspection utilizing disk cloning techniques |
US12081656B1 (en) | 2021-12-27 | 2024-09-03 | Wiz, Inc. | Techniques for circumventing provider-imposed limitations in snapshot inspection of disks for cybersecurity |
KR102479438B1 (ko) * | 2022-01-24 | 2022-12-20 | 한국과학기술원 | 하드웨어 기반의 신뢰할 수 있는 안전한 컨테이너 네트워크 |
US20230336554A1 (en) * | 2022-04-13 | 2023-10-19 | Wiz, Inc. | Techniques for analyzing external exposure in cloud environments |
US12079328B1 (en) | 2022-05-23 | 2024-09-03 | Wiz, Inc. | Techniques for inspecting running virtualizations for cybersecurity risks |
US12061719B2 (en) | 2022-09-28 | 2024-08-13 | Wiz, Inc. | System and method for agentless detection of sensitive data in computing environments |
US12061925B1 (en) | 2022-05-26 | 2024-08-13 | Wiz, Inc. | Techniques for inspecting managed workloads deployed in a cloud computing environment |
US11985058B2 (en) * | 2022-08-04 | 2024-05-14 | Getac Technology Corporation | Interservice communication optimization for microservices |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110314148A1 (en) * | 2005-11-12 | 2011-12-22 | LogRhythm Inc. | Log collection, structuring and processing |
US10191778B1 (en) * | 2015-11-16 | 2019-01-29 | Turbonomic, Inc. | Systems, apparatus and methods for management of software containers |
US20120246303A1 (en) * | 2011-03-23 | 2012-09-27 | LogRhythm Inc. | Log collection, structuring and processing |
US10855725B2 (en) * | 2016-06-02 | 2020-12-01 | Microsoft Technology Licensing, Llc | Hardware-based virtualized security isolation |
US10375111B2 (en) * | 2016-11-12 | 2019-08-06 | Microsoft Technology Licensing, Llc | Anonymous containers |
US11792284B1 (en) * | 2017-11-27 | 2023-10-17 | Lacework, Inc. | Using data transformations for monitoring a cloud compute environment |
US10776194B2 (en) * | 2018-01-31 | 2020-09-15 | Splunk Inc. | Self-monitor for computing devices of a distributed computing system |
US11057393B2 (en) | 2018-03-02 | 2021-07-06 | Cloudentity, Inc. | Microservice architecture for identity and access management |
US11334543B1 (en) * | 2018-04-30 | 2022-05-17 | Splunk Inc. | Scalable bucket merging for a data intake and query system |
US10944654B2 (en) | 2018-06-06 | 2021-03-09 | Servicenow, Inc. | Discovery and mapping of containerized software applications |
US10929415B1 (en) * | 2018-10-01 | 2021-02-23 | Splunk Inc. | Isolated execution environment system monitoring |
US10785122B2 (en) | 2018-10-05 | 2020-09-22 | Cisco Technology, Inc. | Canary release validation mechanisms for a containerized application or service mesh |
US11150963B2 (en) | 2019-02-28 | 2021-10-19 | Cisco Technology, Inc. | Remote smart NIC-based service acceleration |
US11526386B2 (en) | 2019-04-03 | 2022-12-13 | Oracle International Corporation | System and method for automatically scaling a cluster based on metrics being monitored |
US11635995B2 (en) | 2019-07-16 | 2023-04-25 | Cisco Technology, Inc. | Systems and methods for orchestrating microservice containers interconnected via a service mesh in a multi-cloud environment based on a reinforcement learning policy |
US11038803B2 (en) | 2019-10-01 | 2021-06-15 | Salesforce.Com, Inc. | Correlating network level and application level traffic |
US11803408B2 (en) * | 2020-07-29 | 2023-10-31 | Vmware, Inc. | Distributed network plugin agents for container networking |
US20210021533A1 (en) * | 2020-09-25 | 2021-01-21 | Francesc Guim Bernat | Intelligent data forwarding in edge networks |
US20210014133A1 (en) * | 2020-09-25 | 2021-01-14 | Intel Corporation | Methods and apparatus to coordinate edge platforms |
US20210144202A1 (en) * | 2020-11-13 | 2021-05-13 | Christian Maciocco | Extended peer-to-peer (p2p) with edge networking |
US20220116445A1 (en) * | 2021-04-12 | 2022-04-14 | Miltiadis Filippou | Disintermediated attestation in a mec service mesh framework |
US11477165B1 (en) * | 2021-05-28 | 2022-10-18 | Palo Alto Networks, Inc. | Securing containerized applications |
US11689505B2 (en) | 2021-06-28 | 2023-06-27 | Cisco Technology, Inc. | Dynamic proxy response from application container |
-
2021
- 2021-06-28 US US17/304,891 patent/US11689505B2/en active Active
-
2022
- 2022-06-22 WO PCT/US2022/034501 patent/WO2023278211A1/en active Application Filing
- 2022-06-22 EP EP22744040.1A patent/EP4364388A1/en active Pending
- 2022-06-22 CN CN202280046541.0A patent/CN117597903A/zh active Pending
-
2023
- 2023-05-16 US US18/197,867 patent/US11979384B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
CN117597903A (zh) | 2024-02-23 |
WO2023278211A1 (en) | 2023-01-05 |
US11979384B2 (en) | 2024-05-07 |
US20220417219A1 (en) | 2022-12-29 |
US20230283595A1 (en) | 2023-09-07 |
US11689505B2 (en) | 2023-06-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11689505B2 (en) | Dynamic proxy response from application container | |
US20210344692A1 (en) | Providing a virtual security appliance architecture to a virtual cloud infrastructure | |
EP3611883B1 (en) | Secure forwarding of tenant workloads in virtual networks | |
US10728288B2 (en) | Policy-driven workload launching based on software defined networking encryption policies | |
JP7503616B2 (ja) | ネットワーク制御システムのパブリッククラウドへの拡張 | |
US10547463B2 (en) | Multicast helper to link virtual extensible LANs | |
US11088944B2 (en) | Serverless packet processing service with isolated virtual network integration | |
EP3671452A1 (en) | System and method for user customization and automation of operations on a software-defined network | |
US11722356B2 (en) | Enabling integration of solutions with software-defined networking platform | |
CN111614605A (zh) | 基于sdn虚拟防火墙的安全组信息的边界防火墙的自动配置 | |
US20180034703A1 (en) | System and method for providing transmission of compliance requirements for cloud-based applications | |
US11329966B2 (en) | System and method for transferring packets between kernel modules in different network stacks | |
US10547590B1 (en) | Network processing using asynchronous functions | |
JP2024526115A (ja) | コンテナ化されたクロスドメインソリューション | |
US20240137314A1 (en) | Service chaining in fabric networks | |
US11444836B1 (en) | Multiple clusters managed by software-defined network (SDN) controller | |
US11711292B2 (en) | Pre-filtering of traffic subject to service insertion | |
US10848418B1 (en) | Packet processing service extensions at remote premises | |
US20240106855A1 (en) | Security telemetry from non-enterprise providers to shutdown compromised software defined wide area network sites | |
Aderholdt et al. | Multi-tenant isolation via reconfigurable networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: UNKNOWN |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20231213 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) |