Devices, systems and methods for container networking

Abstract

There is described devices, systems, and methods for communicating network packets between a containerized application and the kernel of a host environment. The method includes acquiring from within the host environment, a token which represents access to a network interface. The method also includes passing the token from the host environment into the container and instantiating access to the network interface by the containerized application using the token and a portion of memory.

Description

DEVICES, SYSTEMS AND METHODS FOR CONTAINER NETWORKINGCROSS-REFERENCE TO PREVIOUS APPLICATON

[0001] This application claims priority from United States provisional patent application 63 / 619,877 filed on January 11th, 2024, which is incorporated herein by reference in its entirety.FIELD

[0002] The present disclosure generally relates to the field of data communications and networking. In particular, the present disclosure relates to devices, systems, and methods for communicating network packets between a containerized application and a host.INTRODUCTION

[0003] Containerization is a growing trend in several fields within information technology (IT), from desktop and laptop computers to smartphones to servers. It is a revolutionary approach to packaging, distributing, and running software applications. At its core, containerization involves encapsulating an application and its dependencies into a single, self-contained unit known as a container. This container includes everything needed for the application to run consistently across different environments, from development to production, regardless of variations in the underlying infrastructure.

[0004] The importance of containerization in the field of information technology lies in its ability to address key challenges and bring about significant benefits. For example, containerization provides a security barrier between applications or groups of applications and prevent conflicts within the operating environment that supports the applications (e.g., dynamically linked libraries, configuration files, etc.). Containerization also allows parallel execution of services that would otherwise need to have an entire server dedicated to them, whether because of the design of that service, or in a multitenancy context where different customers must not impact one another.

[0005] As such, containerization enhances isolation by encapsulating applications and their dependencies, promoting consistency and security. Each container operates independently of the host system, minimizing conflicts and providing a more predictable runtime environment. This isolation not only improves security but also enables organizations to scale and manage applications with greater ease.

[0006] The resultant improvements in deployment and maintenance simplicity, security, and resource usage make containerization a long-term trend that has been expanding to include an ever-greater number of use cases, on desktop computers, servers, and mobile devices.

[0007] By default, a container is completely isolated from the host in which it resides. In order to be useful, it must have some sort of interaction with the host, and from there with the rest of the world. One method of providing such interaction is by way of networking processes, in which network packets originating from within the container make their way to the host, and optionally from there to the internet or adjacent networks, typically with packets returning along the same path.

[0008] Known methods of networking between container and host include the creation of virtual ethernet pairs, which provides an emulation of a pair of ethernet devices directly connected to each other via a single path. In use, a packet sent to one ethernet device of the pair will arrive at its complement and vice versa. After creation of such a pair, one of the ethernet devices stays on the host and the other is placed in the container. Once established, standard routing configuration on both the host and the container determine what happens to the packets that are received on each side.

[0009] One significant disadvantage of this method is the required processing overhead of emulating the virtual ethernet devices, as well the potential for the ethernet abstraction not fitting the intended use case (e.g., the interface replaces the ethernet address of the packet being transmitted into the container with its own, obscuring its origin).

[0010] Other known methods of networking between container and host include making a virtual "copy" of network interfaces on the host, and then placing the copy in the container. While several variants of this concept exist, in each case there is a need for the resource underlying the interface abstraction to support the resultant multiple interface abstractions referencing it. As such, these methods require schemes for differentiating between the interface copies, e.g., including having the host support multiple Media Access Control (MAC) addresses, or using the host’s Virtual Local Area Network (VLAN) facility. The significant disadvantage with these methods is that such differentiation schemes are not universally supported by underlying hosts, which leads to a decrease in software portability.

[0011] As such, there is a clear need for improved devices, systems and methods for communicating network packets between a containerized application and a host.SUMMARY

[0012] The various embodiments described herein generally relate to devices, systems, and methods for communicating network packets between a containerized application and a host, in particular, the embodiments described herein generally include creating networking end points on a host, and then sending a descriptor associated with the networking endpoint to a containerized application by way of an inter-process communication socket.

[0013] in one aspect of the present disclosure, there is provided a method of estabiishing packet communication between a containerized application and a network interface in a host environment. The method comprises acquiring, from within the host environment, a token which represents access to a network interface. The method also comprises passing the token from the host environment into the container. The method also comprises instantiating access to the network interface by the containerized application using the token and a portion of memory.

[0014] In some examples, the token is a communication endpoint descriptor and the step of acquiring a token further comprises establishing a communication endpoint in the host environment, the communication endpoint being associated with the communication endpoint descriptor and using the communication endpoint descriptor to associate the communication endpoint to a network interface in the host environment.

[0015] In some examples, the step of passing the token into the container comprises sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment.

[0016] In some examples, the portion of memory is a circular buffer, and the step of instantiating access comprises allocating the circular buffer to the communication endpoint using the communication endpoint descriptor and mapping the circular buffer to the containerized application.

[0017] In some examples, the method further comprises reading / writing packets from / to the portion of memory by the containerized application from within the container.

[0018] in some examples, the method is carried out in a Unix-like environment, and establishing a communication end point in the host environment and using the communication endpoint descriptor to associate the communication endpoint to a network interface in the host environment further comprise creating a socket in the host environment using the socketf) function and binding a socket associated with the created file descriptor to the network interface using a bind() function,

[0019] In some examples, sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment comprises sending the file descriptor from the host environment to the containerized application by way of a domain socket in the Unix environment,

[0020] In some examples, allocating the circular buffer to the communication endpoint using the communication endpoint descriptor and mapping the circular buffer to a containerized application further comprise allocating the circular buffer to the socket with the file descriptor using the setsockopt() function and mapping the circular buffer to the containerized application using the mmap() function.

[0021] In some examples, reading / writing packets from / to the portion of memory by the containerized application from within the container is performed using any one of memcpyO, memmove(), and memset(),

[0022] In some examples, a kernel of the host environment reads / writes packets from / to the portion of memory using packet_mmap.

[0023] In another aspect of the present disclosure, there is provided a non- transitory computer-readable storage medium storing a plurality of instructions executable by one or more processors, the plurality of instructions when executed by the one or more processors cause the one or more processors to execute the above method.

[0024] In yet another aspect of the present disclosure, there is provided a system comprising a first process running on a host environment and a second process running in a container. The system comprises one or more computer processors and one of more computer readable storage media for storing computer-implemented instructions, wherein the one or more computer processors are configured to execute the computer- implemented instructions to cause the computer system to perform the above method.

[0025] in yet another aspect of the present disclosure, there is provided an edge device comprising an active agent manager running on a host environment and an active agent running in a container. The system comprises one or more computer processors and one of more computer readable storage media for storing computer-implemented instructions, wherein the one or more computer processors are configured to execute the computer-implemented instructions to cause the computer system to perform a method comprising the step of acquiring, by the active agent manager, from within the host environment, a token which represents access to a network interface. The method also comprises passing the token from the host environment into the container. The method also comprises instantiating, by the active agent, access to the network interface by the containerized application using the token and a portion of memory.

[0026] In some examples, the token is a communication endpoint descriptor and the step of a acquiring a token further comprises establishing a communication endpoint in the host environment, the communication endpoint being associated with the communication endpoint descriptor and using the communication endpoint descriptor to associate the communication endpoint to a network interface in the host environment.

[0027] In some examples, the step of passing the token into the container comprises sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment.

[0028] In some examples, the portion of memory is a circular buffer and the step of using the token comprises allocating the circular buffer to the communication endpoint using the communication endpoint descriptor and mapping the circular buffer to the containerized application.

[0029] In some examples, the method further comprises reading / writing packets from / to the portion of memory by the containerized application from within the container.

[0030] In some examples, the method is carried out in a Unix environment, and wherein establishing a communication endpoint in the host environment and using the communication end point descriptor to associate the communication end point to a network interface in the host environment further comprise creating a socket in the host environment using the socketf) function and binding a socket associated with the created file descriptor to the network interface using a bind() function.

[0031] in some examples, sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment comprises sending the file descriptor from the host environment to the containerized application by way of a domain socket in the Unix environment.

[0032] in some examples, allocating the circular buffer to the communication endpoint using the communication endpoint descriptor and mapping the circular buffer to a containerized application further comprise allocating the circular buffer to the socket with the file descriptor using the setsockopt() function and mapping the circular buffer to the containerized application using the mmap() function.

[0033] In some examples, reading / writing packets from / to the portion of memory by the containerized application from within the container is performed using any one of memcpyO, memmove(), and memset().

[0034] In some examples, a kernel in the host environment reads / writes packets from / to the portion of memory using packet_mmap.DRAWINGS

[0035] The drawings included herewith are for illustrating various examples of devices, methods and systems of the present specification and are not intended to limit the scope of what is taught in any way. In the drawings:

[0036] FIGURE 1 shows a simplified schematic diagram of a computing environment in accordance with embodiments of the present disclosure:

[0037] FIGURE 2 shows a flow diagram of a method of establishing a configurable circular buffer to send or receive packets in accordance with the prior art;

[0038] FIGURE 3 shows a schematic diagram of the use of virtual ethernet devices in accordance with the prior art;

[0039] FIGURE 4 shows a flow diagram of a method of establishing a configurable circular buffer to send or receive packets in accordance with embodiments of the present disciosure;

[0040] FIGURE 5 shows a simplified schematic diagram of the use of a shared configurable circular buffer to send and received packets in accordance with embodiments of the of the disclosure;

[0041] FIGURE 6 shows a schematic diagram of a use case in accordance with embodiments of the present disclosure comprising an instantiated containerized security environment; and

[0042] FIGURE 7 shows an exemplary schematic diagram of hardware components in a host device in accordance with embodiments of the present disclosure.DESCRIPTION OF VARIOUS EMBODIMENTS

[0043] Various embodiments in accordance with the teachings herein will be described below to provide an example of at least one embodiment of the claimed subject matter. No embodiment described herein limits any claimed subject matter. The claimed subject matter is not limited to devices, systems, or methods having all of the features of any one of the devices, systems, or methods described below or to features common to multiple or ail of the devices, systems, or methods described herein. It is possible that there may be a device, system, or method described herein that is not an embodiment of any claimed subject matter.

[0044] Any subject matter that is described herein that is not claimed in this document may be the subject matter of another protective instrument, for example, a continuing patent application, and the applicants, inventors, or owners do not intend to abandon, disclaim, or dedicate to the public any such subject matter by its disclosure in this document.

[0045] It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the embodiments described herein. Also, the description is not to be considered as limiting the scope of the embodiments described herein.

[0046] It should also be noted that the terms “connected” or “connecting” as used herein can have several different meanings depending in the context in which these terms are used. For example, the terms connected and connecting can have a mechanical or data communication connotation. For example, as used herein, the terms connected andconnecting can indicate that two elements or devices can be directly linked to one another or linked to one another through one or more intermediate elements or devices via electrical and / or electromagnetic and / or optical signals, depending on the particular context, so as to be in data communication with other connected devices.

[0047] It should also be noted that, as used herein, the wording “and / or” is intended to represent an inciusive-or. That is, “X and / or Y” is intended to mean X or Y or both, for example. As a further example, “X, Y, and / or Z” is intended to mean X or Y or Z or any combination thereof.

[0048] The example embodiments of the devices, systems, or methods described in accordance with the teachings herein may be implemented as a combination of hardware and software. For example, the embodiments described herein may be implemented, at least in part, by using one or more computer programs, executing on one or more programmable devices comprising at least one processing element and at least one storage element (i.e., at least one volatile memory element and at least one non-volatile memory element). The hardware may comprise input devices including one or more of a touch screen, a keyboard, a mouse, buttons, keys, sliders, and the like, as well as one or more of a display, a printer, and the like depending on the implementation of the hardware.

[0049] It should also be noted that there may be some elements that are used to implement at least part of the embodiments described herein that may be implemented via software that is written in a high-level programming language. The program code may be written in Rust, C++, C#, JavaScript, Python, or any other suitable programming language and may comprise modules or classes, as is known to those skilled in the art. Alternatively, or in addition thereto, some of these elements implemented via software may be written in assembly language, machine language, or firmware as needed. In either case, the language may be a compiled or interpreted language.

[0050] At least some of these software programs may be stored on a computer readable medium such as, but not limited to, a ROM, a magnetic disk, an optical disc, solid-state storage, a USB key, and the like that is readable by a device having a processor, an operating system, and the associated hardware and software that is necessary to implement the functionality of at least one of the embodiments described herein. The software program code, when read by the device, configures the device tooperate in a new, specific, and predefined manner (e.g., as a specific-purpose computer) in order to perform at least one of the methods described herein,

[0051] At least some of the programs associated with the devices, systems, and methods of the embodiments described herein may be capable of being distributed in a computer program product comprising a computer readable medium that bears computer usable instructions, such as program code, for one or more processing units. The medium may be provided in various forms, including non -transitory forms such as, but not limited to, one or more diskettes, compact disks, tapes, chips, and magnetic and electronic storage. In alternative embodiments, the medium may be transitory in nature such as, but not limited to, wire-line transmissions, satellite transmissions, internet transmissions (e.g., downloads), media, digital and analog signals, and the like. The computer useable instructions may also be in various formats, including compiled and non-compiled code.

[0052] As used herein, the term “containerization” means a form of virtualization that enables the packaging and isolation of applications along with their dependencies. It involves encapsulating an application, its runtime, libraries, and other necessary components into a standardized unit known as a “container”.

[0053] As used herein, the term “container" means any isolated or partly-isolated executable software package that includes everything needed to run an application, including the code, runtime, libraries, and system tools using the resources of a host device.

[0054] As used herein, the term “kernel” means the core component of an OS responsible for managing the system’s resources and providing essential services to other parts of the software. A kernel acts as an intermediary between application programs and the computer hardware, facilitating communication and coordination between software and hardware components.

[0055] As used herein, the term “Unix-like” means any operating systems that share similarities with the original Unix operating system. Unix-like operating systems include, but are not limited to, Linux®, FreeBSD®, Open BSD, and macOS®.

[0056] As used herein, the term “namespace” generally refers to a feature of the Unix, or Unix-like, kernel that partitions kernel resources such that one set of processessees one set of resources while another set of processes sees a different set of resources.

[0057] As used herein, the term “network namespace” means a Linux kernel feature that allows processes to have their own isolated network stack. Processes running in different network namespaces can have their own network interfaces, routing tables, firewall rules, and other network-related resources without interfering with each other. Network namespaces provide a form of network isolation, which is particularly useful for containerization technologies.

[0058] As used herein, the term “host device” means any networked device in which information flows are consumed and / or generated. Host devices include, but are not limited to, user devices such as laptops, smartphones, tablets, and televisions, as well as Internet of Things (loT) devices, such as refrigerators and smart thermostats. Host devices, as defined herein also include hardware and / or software servers that provide functionality to other end point devices.

[0059] As used herein, the term “restricted service" means any network-accessible service where the abilities to read, modify, and / or delete information stored by that service, or cause actions to be taken by that service, is dependent on the identification and / or authentication of the user who is seeking to perform that action.

[0060] As used herein, the term “edge device" means any device that provides an endpoint device with an entry point to a network. Edge devices include, but are not limited to, network access devices (e.g., routers, gateways and Wi-Fi access points) and user devices (e.g., laptops, smartphones, tablets) having tethering capabilities and / or being capable of acting as wireless access points and routers for devices connected thereto.

[0061] As used herein, the term “application” (also reference herein as a “process”) means any computer program designed to perform specific tasks for end-users, business processes, or other applications.

[0062] As used herein, the term “resource” means any entity that can be used or consumed to perform tasks and support the operation of computer systems and applications. Resources can include hardware components, software, data, and various other elements that contribute to the functioning of a computer system.

[0063] As used herein, the term “token” means any piece of data used by, for example, a process or application, to identify a resource in a computing environment.

[0064] FIGURE 1 shows a schematic diagram of a computing environment 100 in accordance with embodiments of the present disclosure. Containers have emerged as a transformative technology in the realm of software development and deployment, offering a portable and efficient solution for packaging applications and their dependencies.

[0065] Containers 101 , 102 provide a level of isolation for applications 103, 104. Each container encapsulates its application and dependencies, ensuring that it runs independently of other containers on the same host. This isolation is achieved through features provided by the underlying operating system (OS) 107 and prevents applications 103, 104 from interfering with each other or with the host system.

[0066] Containers 101 , 102 share the host OS's kernel 108 but have their own user space. This means that multiple containers can run on the same host, each with its own fiie system, libraries, and processes, but ail using the same kernel 108. Containers are typically deployed using an immutable infrastructure approach. Once an image is created, it is not modified during runtime. This minimizes the attack surface by reducing the chances of unauthorized changes to the runtime environment. Security updates can be applied by creating new container images rather than modifying running containers. This agility is beneficial for security because it enables the fast deployment of patches and updates in response to security vulnerabilities. It also aids in isolating and mitigating potential security incidents.

[0067] Containers are designed to be portable across different environments. Since they encapsulate all the dependencies needed to run an application, they can run consistently on any system that supports containerization, regardless of the underlying infrastructure. This portability is a key advantage for both development and deployment workflows. Containers on the same host can interact with each other, but they are, by default, isolated from the host and other containers.

[0068] At the core of containerization are technologies (e.g., Docker™) that provide the infrastructure and mechanisms to create, manage, and run containers 101 , 102. For instance, Docker utilizes a client-server architecture, where the Docker client communicates with the Docker daemon, responsible for container operations such as building, running, and managing.

[0069] Containers 101 , 102 are instantiated from container images, which are seif- contained, executable packages encompassing the application 103, 104, binaries and libraries (bins / libs 105, 106), and other necessary settings. These images serve as the blueprint for containers, ensuring consistency across various environments.

[0070] Binaries, comprising the executable files of an application, are a fundamental component of containers 101 , 102. Containers encapsulate these binaries, along with their dependencies, ensuring a self-sufficient environment for the application to run. Libraries are shared components of an application that are required for functionality and are integrated into the container image. Containers 101 , 102 encapsulate these libraries, preventing conflicts with those on the host system. This encapsulation guarantees that the application runs with the correct versions of libraries, mitigating compatibility issues and creating a reliable and reproducible runtime environment.

[0071] Containers leverage the kernel 108 of a host’s OS 107 for low-level operations, including process scheduling, resource management, and system calls. Unlike virtual machines, containers share a host’s kernel while maintaining isolation at the user space level. This shared kernel approach contributes to the lightweight nature of containers, reducing resource overhead and enhancing efficiency.

[0072] Containers 101 , 102 also interact with hardware infrastructure 109 of a host. In particular, containers 101 , 102 interact with processor 111 through the host OS’s kernel 108. Processor 111 executes containerized processes as if they were native, maximizing performance and efficiency.

[0073] Containers 101 , 102 also manage memory through kernel 108, utilizing the memory resources allocated by the host system. Memory isolation is achieved through namespaces, ensuring that each container has its own isolated view of the system's memory. This isolation prevents one container from accessing the memory space of another, enhancing security and stability.

[0074] Containerized applications 103, 104 interact with the kernel 108 for systemlevel operations. The binaries and libraries 105, 106 of applications 103, 104 are executed within the isolated environment provided by their respective container 101 , 102. Interactions with the host system, such as file access or network communication, are mediated by the container runtime, ensuring controlled and secure operations.

[0075] Containerization provides several security benefits, which are particularity advantageous for security applications as those described in more detail herein with reference to FIGURE 6. For example, compliance with security standards and regulations can be more easily achieved and maintained through standardized container configurations. Container images can also be signed and verified to ensure their integrity and authenticity. This helps in preventing the deployment of compromised or tampered images. The use of signed images enhances the overall security of containerized applications.

[0076] Furthermore, containers 101, 102 encapsulate application dependencies, making it easier to manage and control the versions of libraries and components used by applications 103, 104. This reduces the risk of security vulnerabilities resulting from outdated or incompatible dependencies. Containers 101 , 102 can be configured to run with minimal privileges, reducing the impact of a potential security breach. Most importantly, applications 103, 104 can be run within containers 101 , 102, respectively, in a way that is isolated from the host system, thereby limiting the potential for malicious activities.

[0077] An example host device 700 in accordance with embodiments of the present disclosure is shown in FIGURE 7. In some embodiments, the host device 700 includes a router or Wi-Fi access point running an application with storage, communication, and processing means. However, it is contemplated that in other embodiments, other computer systems may be used as a host device. For example, in some embodiments, the host device may include a desktop computer, a tablet computer, a laptop, or similar, or in other embodiments, a smart phone running an operating system such as, for example, Android®, iOS®, Windows® mobile, or similar.

[0078] In some embodiments, the host device 700 may comprise one or more processors 701 , one or more networking interfaces 702, and memory 705. In some embodiments, the host device 700 may also comprise one or more Input / Output (I / O) interface(s) 703 and a display 704.

[0079] The term "processor" as used herein refers to any quantity and combination of a processor and may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functionality described herein may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individualprocessors, some of which may be shared. Other hardware, conventional and / or custom, may also be included.

[0080] In some embodiments, one or more processors 701 , one or more memories 707 and one or more networking interfaces 702 are configured for bidirectional data communication through the internal network 706 of the host device 700, and accordingly can include network adaptors and drivers suitable for the type of network used. One or more memories 705 may include volatile storage and non-volatile storage for storing program code executed by one or more processors 701 and / or data used during operation of one or more processors 701.

[0081] A memory of one or more memories 705 may be a semiconductor medium (including, for example, a solid-state memory), a magnetic storage medium, an optical storage medium, and / or any other suitable type of memory. In some embodiments, one or more memories 705 include a containerized security environment 707, as described in more detail elsewhere herein.

[0082] A known mechanism for efficiently handling packets in a host software / hardware environment is "packet^mmap", which refers to a type of memory mapping feature in the Linux kernel related to packet processing. Memory mapping in Linux refers to the technique of associating a resource with a contiguous block of virtual memory addresses, allowing for direct access to the resource, or to share that resource between several processes. This association enables efficient data transfer between processes, between processes and the kernel, and to and from the resource, streamlining read and write operations. In Linux, the mmap() system call is commonly used for memory mapping, providing a uniform interface for applications to manipulate files or interact with hardware.

[0083] Packet_mmap is a feature which allows the kernel to add packets to a ring buffer (also known as a “packet ring”, and referred to herein as a “circular buffer”). This process is very efficient because it does not require any system calls (i.e., expensive because they halt the process and transfer control to the kernel and then back again) from the application. The kernel writes incoming packets into the circular buffer and an application reads it (and vice versa for sending).

[0084] FIGURE 2 shows a flow diagram of a method of establishing a configurable circular (i.e., ring) buffer to send or receive packets in accordance with the prior art. In ahost environment, the method first includes creating a communication endpoint having a particular communication endpoint identifier at step 201.

[0085] In some embodiments of the present disclosure, the communication endpoint can be a socket, and the creation of the communication endpoint can be performed by using the socket() function. The socket() function is a system call in computer programming, particularly in networking. In the context of Unix-like operating systems, including Linux, it is used to create a new communication endpoint, or socket. A socket serves as an interface for communication between processes, either on the same device or across a network. The socket() function takes parameters specifying the communication domain, socket type, and protocol. Once created, the socket can be used for various communication tasks, such as establishing connections, sending and receiving data, and enabling inter-process communication.

[0086] This socket() function call returns a file descriptor (FD), which acts as a communication endpoint identifier. A file descriptor is a unique identifier or index that the operating system assigns to an open file or input / output resource, such as a file, socket, or a pipe. It's a non-negative integer, and when a program opens or creates a file, the operating system returns a file descriptor that the program can use to reference and manipulate that resource.

[0087] In other words, a FD is a generic identifier that references a resource that the kernel is holding on behalf of an application. For each application, the kernel stores a table of FDs, mapped to their respective resources. When the application later needs to access a resource, it passes the FD back to the kernel, which then looks up the resource in the table. In the rest of the method set out below, all calls (other than socket()) take the socket’s FD as an argument.

[0088] Then, at step 202, the method includes configuring the communication endpoint. In some embodiments, configuration of the communication endpoint can be performed using setsockoptf), which is a system call in Unix-like operating systems, including Linux, used to set options on a socket. It allows a program to configure various behaviors of a socket after it has been created using the socket() system call.

[0089] The setsockopt() function takes several parameters, including the file descriptor. Common use cases for setsockopt() include configuring socket options related to socket behavior, communication protocols, and network settings.

[0090] Then, at step 203, the method includes binding the communication end point with a network interface, in some embodiments of the present disclosure, this can be performed using bind() in Unix-like operating systems. The bind() system call is used in network programming to associate a socket with a specific network interface. The FD now represents a raw socket that is bound to a chosen network interface.

[0091] Finally, at step 204, the method includes mapping the circular buffer to an application, which allows for the sending and receiving of packets by reading and writing to the circular buffer associated with the socket. In some embodiments, step 204 also includes mapping the circular buffer to the kernel 108. Thus, via the previous association of the token to a network interface as created using the method described above, an association is established between the application 103, 104 running in the container and a network interface on the host. In some embodiments of the present disclosure, this can be achieved using mmap(). The mmap() system call in Unix-like operating systems, including Linux, is used to map a resource into memory. The name "mmap" stands for "memory map". This fu notion allows a program, including the operating system kernel itself, to access the contents of a file or a device as if it were an array in memory.

[0092] Several methods of transferring or communicating packets from a host to a container are known. The most common of these, conceptually shown in FIGURE 3, is known as virtual ethernet (or “veth”), which involves the creation of a pair of network interfaces (i.e., a “veth pair), each of which emulates an ethernet device 304, 306. A veth pair is a type of virtual network interface used in Linux systems to create a virtual network link between two network namespaces. Network namespaces provide isolation for network resources, allowing different processes or containers to have their own network stack with separate interfaces, routing tables, and other network-related configurations.

[0093] In use, these arrangements are created by first creating a pair of ethemet interfaces. These interfaces are often named “vethO” and “vethl". Once created, vethO and vethl are linked together as if they were connected by a physical ethernet cable (also known as a virtual ethernet cable 305). Each interface in the pair is then placed into a different network namespace. This separation allows for network isolation. In the embodiments shown in FIGURE 3, the first virtual ethernet device 304 (including vethO) is placed in the host environment 301 and the second virtual ethernet device 306 (including vethl ) is placed in the container 302.

[0094] Once the interfaces are in separate namespaces, they can be configured individually. This includes assigning IP addresses, setting up routing tables, and configuring other network parameters. With the veth pair set up, applications in the respective namespaces can communicate with each other over the virtual link. Network traffic sent through one interface of the pair 303 can be received by the other 307. In summary, a veth pair provides a virtual network link between two network namespaces, allowing for network communication between processes in those namespaces.

[0095] While the entire process of traversing paired veth devices 304, 306 happens within the kernel 108, it does require a significant amount of overhead. Each of vethO and vethl is a full network interface requiring configuration of the usual range of options (e.g., firewall rules, QoS queues, etc.), which have to be evaluated for every packet. Furthermore, in the case that a process, such as active agents 611 , 613 described elsewhere herein in greater detail, requires individual packets inspection capabilities, those packets still need to traverse the barrier between kernel and user process, which typically involves a system call to the kernel.

[0096] In seeking to overcome the above-mentioned problems associated with the prior art, the inventors have understood that a novel use of the packet_mmap() feature in Unix-like systems can provide technically advantageous devices, systems, and methods for communicating network packets between a containerized application and a host.

[0097] In other embodiments, the inventors have further realized that it is surprisingly possible to create tokens in the kernel memory mapping mechanism on the host, and then pass those tokens (e.g., a file descriptor) into the container. In the case of a file descriptor, Unix domain sockets can allow the transfer from host to an application running in the container. Once the token is received by the application inside the container, it can be used to set up the shared-memory mechanism.

[0098] FIGURE 4 shows a flow diagram of a method 400 of establishing a configurable circular buffer to send or receive packets in accordance with embodiments of the present disclosure. First steps 402 and 403 of the method of are performed in the host environment 401, in a process known as the Host Abstraction Layer (HAL). A Host Abstraction Layer (HAL) is a software abstraction layer that provides a consistent interface to hardware resources or platform-specific functionalities. It abstracts the underlying hardware details, allowing software developers to write code that isindependent of the specific hardware or platform it runs on. The purpose of a HAL is to enable portability and ease the development of software applications that can run on different systems without modification. In the context of networking or distributed systems, a Host Abstraction Layer may abstract details related to network communication, such as socket management, addressing, and protocol handling. This abstraction allows applications to be written without being tightly coupled to the specifics of the underlying networking infrastructure, making it easier to port applications across different environments.

[0099] In some embodiments, the process implementing steps 402, 403 and 404 can be the Active Agent Manager 615 of FIGURE 6.

[0100] The method first includes acquiring, from within the host environment, a token which represents access to a network interface. In some embodiments, this comprises establishing a communication endpoint in the host environment, the communication endpoint being associated with the communication endpoint descriptor. This may also comprise using the communication endpoint descriptor to associate the communication endpoint to a network interface in the host environment.

[0100] In the embodiments shown in FIGURE 4, at step 402, a communication endpoint is created. The endpoint can be identified by way of an endpoint descriptor, which is typically attributed to a communication endpoint when the communication endpoint is created.

[0101] In some embodiments, this can be done via a call made using the socketQ function. In some embodiments, such a call would specify at least that the socket should be a networking socket (i.e., a socket destined to receive networking packets, as opposed to, for example, a Unix Domain socket) and that it should also be a “raw” socket (i.e., destined to receive networking packets prior to them being processed in any way). A raw socket is a type of socket in computer networking that provides direct access to the underlying communication protocols, allowing applications to send and receive data without the need for the operating system’s network protocol stack. Unlike higher-level socket types that operate at the transport layer (e.g., TCP or UDP), raw sockets operate at a lower level, typically at the network layer.

[0102] Creation of a “raw socket" is necessary to provide an interface for networking at one abstraction layer down from what is typically used by application-levelcode. A raw socket is created for handling networking directly (i.e., for handling packet information itself, as opposed to only the data contained within a packet). The establishment of a communication endpoint typically also involves the creation of a token which can subsequently be used to refer to and access the communication endpoint. In some embodiments, the socket() function call returns a file descriptor (FD) as a token, which acts as at least one argument of the other calls set out in the method.

[0103] Then, at step 403, the endpoint is bound to a network interface. In some embodiments, this step can be performed by making a call using bind(). As mentioned above, in networking and socket programming, bind() is a function used to associate a socket with a specific network address, such as an IP address and port number. In other words, the bind() call provides an indication to kernel 108 that the socket created at step 402 should be bound to a particular network interface (e.g., the Wi-Fi interface). The FD now represents a raw socket that is bound to a specific network interface.

[0104] The bind() process must be performed in the host environment because the network interface being called by the bind() function belongs to the host’s namespace. While there are methods of allowing a containerized application to use resources in a host's namespace, such methods are inefficient from a security perspective.

[0105] Then, generally, the method comprises passing the token from the host environment into the container. In some embodiments, this includes sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment.

[0106] In the embodiments shown in FIGURE 4, at step 404, novel use of a mechanism in Unix-like systems is employed. The mechanism, which is called Unix Domain Sockets, is typically used for inter-process communication. A Unix domain socket, also known as a Unix socket, is a communication endpoint within the Unix or Unix-like operating systems for inter-process communication (I PC). Unlike network sockets, Unix domain sockets exist entirely within the operating system's file system.

[0107] At step 404, the communication end point descriptor is sent from the host environment 401 to an application running on a container 405 via an inter-process communication method.

[0108] in some embodiments, this step can be performed by sending the FD from the host environment 401 to an application running on container 405 by way of the Unix Socket Domain.

[0109] In practice, this is achieved by having the kernel duplicate the file descriptor in question from the table of the sending process (e.g., active agent manager 615) and place it into a table associated with the application being run in the container 405. Thus, the FD passes through the Unix Domain Socket channel, through the container barrier, and into the container. The end result is that an application running inside a container owns the FD that references a network interface on the host. This method is possible even if the network interface referenced by the FD is, e.g., for security reasons, not visible from within the container 405.

[0110] Finally, the general method comprises using, from within the container, the token to instantiate access to the network interface by the containerized application. In some embodiments, this comprises allocating the circular buffer to the communication endpoint using the communication endpoint descriptor and mapping the circular buffer to an application running in the container.

[0111] In the embodiments shown in FIGURE 4, once the application being run in the container 405 has the FD, the process carried out inside the container comprises the two remaining initialization steps, namely allocating and attaching a circular buffer to the FD, at step 406, and mapping that circular buffer to the application being run inside the container 405, at step 407.

[0112] In some embodiments, this is done by first calling setsockopt() at step 406 to allocate a circular buffer to the FD.

[0113] As will be appreciated by the skilled reader, setsockopt() is a generic function for configuring several aspects of different types of socket. The devices, systems and methods described herein make use of setsockopt() to inform the kernel 108 that the application 103, 104 will be reading the from the socket using the packet ring method. In some embodiments of the present disclosure, this is done by calling setsockoptQ with PACKET_RX_RING. In response to this call, the kernel 108 executes a number of functions, including allocating a circular buffer in memory 110 and then ensuring that all packets received are then placed into the circular buffer. As will be appreciated by the skilled reader, the same call to setsockoptQ is also used to specify configuration detailsof the circular buffer (e.g., the size of the circular buffer). Similarly, in some embodiments of the present disclosure, devices, systems and methods described herein make use of setsockopt() to inform the kerne! 108 that an application (either 103 or 104) will be writing to the socket using the packet ring method. In some embodiments of the present disclosure, this is done by calling setsockoptQ with PACKET__TX_RING.

[0114] Then, at step 407, a call is made to mmap() in order to map the circular buffer to the application being run inside the container. Specifically, the mmap() function maps a section of the memory 110 attributed to the application in such a way that both the kernel 108 and an application 103, 104 can read from and write to the same piece of memory 110. The inventors of the present disclosure have understood that a particularity of a particular application 103, 104 calling mmap() is that the function allows another application (or the kernel 108) to use the memory attributed to the particular application making the call.

[0115] At that point, it is now possible for the containerized application to send and receive packets directly to and from the network interface specified at step 403, without any abstraction or intermediation. Once communication between the kernel and the containerized application is established via means of a shared circular buffer, sending and receiving data is highly efficient, only needing the usual methods of setting and retrieving working application memory, instead of system calls. These usual methods include machine instructions which move the contents of a processor register into a memory address (and vice versa), or via the use of memory co-processors (often referred to as DMA, or Direct Memory Access) which set, copy, and move blocks of memory without the central processor being involved. Often, functions such as memcpy(), memmove(), and memset() are wrappers over these methods.

[0116] FIGURE 5 shows a simplified schematic diagram of the use of a shared configurable circular buffer 504 to send and received packets in accordance with embodiments of the of the disclosure. Using the method described above, when a packet is received from the client 503, packets enter the kernel in the host environment 501 and then are almost immediately (e.g., prior to being handled by a firewall) placed in the circular buffer 504. Then, from inside the container 502, the application simply sees that a new packet has arrived in the circular buffer, which leads to the packet being received by the application. The only overhead is required to copy the packet data into the circular buffer. This is a security advantage of the presently disclosed devices, systems andmethods, as fewer packets need be copied through the system as compared to traditional methods of interacting with containerized applications (e.g., virtual ethernet devices).

[0117] Another significant advantage of using the above method is that it does not require any system call (or syscalls) on the part of the application. As will be appreciated by the skilled reader, every time a syscall is made, it provides an opportunity for the kernel to enforce the barrier between host and container. The above method only requires memory being read and written, which is a highly performance-sensitive operation that the kernel does not intermediate, and so the barrier between host and container does not exist in this very narrow context. In other words, the method described herein uses memory-mapped mechanisms, which were originally created for performance reasons. As such, there is no penalty for the host / container barrier traversal, which results in a method that is generally faster than all existing container networking methods.

[0118] Moreover, the security of this method is advantageous as compared to existing methods. In the case of the virtual ethernet, the emulation of the ethernet devices presents a significant attack surface area. The methods required "copying” of interfaces are worse in this respect, as they interface with not the kernel's emulation of a network device, but the driver software of the device itself. This software varies from device to device, and thus represents a very large, combined attack surface area if the method is used in multiple hardware contexts.

[0119] Furthermore, support for the memory-mapped interfaces used in accordance with the methods contained in the present disclosure is dependent on kernel 108, not on any of the driver of any particular networking device / interface. In particular, the packetjrimap is widely available in Linux devices.

[0120] The aforementioned technical advantages are particularly significant for security applications. These advantages will be described in more detail with respect to the exemplary system of FIGURE 6.

[0121] FIGURE 6 shows a schematic diagram of containerized security environment 603 of an edge device 600 in accordance with example embodiments of the present disclosure. In the exemplary embodiment of FIGURE 6, the host device (i.e. , the device hosting the containers) will be referred to as an edge device. Edge device 600 can be connected to the internet 602 by way of an internet connection 601 using known methods. An active agent manager 615 is loaded on to edge device 600 as a piece ofsoftware. Loading the active agent manager 615 onto the edge device may be performed using any number of known methods. For example, the active agent manager 615 may be loaded onto the edge device 600 as part of a factory install, or it may subsequently be downloaded from an app store platform. In some embodiments, the active agent manager 615 may be configured to be rendered inoperable if downloaded onto an edge device running an out-of-date operating system (OS), and / or an OS that is otherwise deemed to be unsecure. In some embodiments, the active agent manager 615 may be configured to only run on a cryptographically signed OS.

[0122] Active agent manager 615 is configured to establish an encrypted connection 616 to secure cloud 620. As will be appreciated by the skilled reader, an encrypted connection can include, but is not limited to, access to a remote (e.g. office) LAN. Such access may be established via, for example, IP Sec, OpenVPN, etc., or other known protocols. Other examples of encrypted connections include, but are not limited to, a WireGuard™ tunnel, a cloud access security broker (CASB) connection, and a connection secured using secure file transfer protocol (FTPS). Active agent manager 615 may establish an encrypted Wi-Fi connection 606 with smartphone 605 and may connect to end point device 609 by way of secured ethernet connection 608.

[0123] Active agent manager 615 is configured to detect connection requests from endpoint devices 605 and 609. In some embodiments, active agent managers 615 may hold records of endpoint device identities for all endpoint devices that have previously been authenticated using known methods. In some embodiments active agent managers 615 may be pre-configured to recognize a certain number of end point device identities. In some embodiments, active agent managers 615 may receive records of endpoint device identities for all endpoint devices listed in a user’s profile from a secure cloud as a result of an authentication of the active agent manager 615.

[0124] Active agent manager 615 may monitor all traffic being sent from devices with which it is connected, as well as all traffic destined to devices with which it is connected. In some embodiments, active agents monitor all traffic transiting through edge device 600. In some embodiments, monitoring of traffic includes the use of an extended Berkley packet filer (eBPF). In some embodiments, monitoring of traffic includes data processing techniques such as deep packet inspection (DPI).

[0125] In some embodiments, an example of which is shown in FIGURE 6, a single active agent manager 615 running on a single edge device 600 may instantiate multipleactive agents 611 , 613. As will be appreciated by the skilled reader, each active agent 611 , 613 may be established using a different user profile associated with the different user, and may connect to different endpoint devices 605, 609 using different means, as required. For example, active agent 613 may connect to endpoint device 609 by way of secured ethernet connection 608. Moreover, a single user may have multiple user profiles (e.g., one associated with work, another associated with personal use). In such scenarios, a single user may require the instantiation of multiple active agents (i.e., one for each user profile).

[0126] As will be appreciated, one of the significant advantages of implementing active agents 611, 613 as part of containers 610, 612 is ease with which it is possible to instantiate and disinstantiate active agents 611 , 613. Significant portions of the state associated with network configuration and the creation of secure connections to various destinations is contained within the edge device kernel, and any errors in managing that state represents a potential security flaw. Therefore, the use of containers 610, 612 enhances the security of the system, as well as reduces errors unrelated to security.

[0127] In some embodiments, a secure communication link (such as an encrypted tunnel / connection) may be established between edge device 600 and a network destination. In the example shown in FIGURE 6, first an encrypted connection 616 is established between active agent 611 and restricted service 618. As will be appreciated by the skilled reader, an encrypted connection can inciude, but is not limited to, access to a remote (e.g. office) LAN. Such access may be established via, for example, IPSec, OpenVPN, etc., or other known protocols. Other examples of encrypted connections include, but are not limited to, a WireGuard™ tunnel, a cloud access security broker (CASB) connection, and a connection secured using secure file transfer protocol (FTPS).

[0128] There are a number of technical advantages to using the devices, systems and methods described herein in systems in accordance with the Example shown in Figure 6. For example, packets (generally) contain the address of the last interface through which it transited (i.e., the MAC address). If using the virtual ethernet device arrangement mentioned above, the MAC address of all packets end up being that of the virtual ethernet card on the outside of the container. This removes a critical part of the identity process (i.e., otherwise the MAC address would have been that of the endpoint device). By attaching directly to the network interface using the methods described here, it is possible to access packets coming from the endpoints before nearly any processingis done on them (e.g., routing, firewalling, etc.). Moreover, accessing packets at such an early stage removes the need for any processing to be done by the kernel, thereby saving processing cycles. Furthermore, yet another benefit of receiving packets before the kernel has processed them is that there is no need to compensate or address the problem of what a kernel might do with a packet (e.g., because of a firewall) before it reaches the containerized application.

[0129] In some embodiments of the present disclosure, as referenced as 618 or 619 in FIGURE 6, a restricted service may be another edge device configured in a similar way to edge device 600. In such embodiments, a secure connection between endpoints in two separate physical locations can be established, with the two intermediating edge devices arranging and managing information flows between the two endpoints.

[0130] Active agents 611 , 613 are configured to monitor and manage information flows to and from one or more endpoint devices 605, 609. In some embodiments, examples of managing and monitoring information flows to and from one or more endpoint devices 605, 609 include, but are not limited to, the following capabilities.

[0131] In some embodiments, active agents 611 , 613 are configured to generate and collect metadata about information flows and endpoint devices. In some embodiments, such metadata may include the timing and volume of information flows, their sources and destinations, the types of resources being accessed (e.g., a web site or a video chat), and the organization(s) responsible for the resource(s) being accessed via that information flow.

[0132] In some embodiments, active agents 611 , 613 are configured to record metadata, both locally and at a centralized location. For example, active agents 211 , 213 may be configured to record and store metadata locally and send metadata to secure cloud 220 for further processing.

[0133] In some embodiments, active agents 611 , 613 are configured to establish behavioral baselines (also known as baseline traffic) for endpoint devices based on stored metadata, where the usual behavior of users and endpoint devices can be compared to subsequent behaviors to detect compromised endpoint devices, compromised identities, or malicious actions. A non-limiting example of this is a situation in which a corporation may provide employees with access to a suite of software as a service (Sa aS) business tools from a first supplier and an employee of the corporationstarts using business tools from a second supplier. In such a situation, the baseline traffic may be characterized as being between an employee’s device(s) and the servers of the first supplier, and a deviation from such baseline traffic may be when information flows are directed towards servers of the second supplier. Another non-limiting example of this is a situation in which baseline traffic to a networked printer is characterized by documents being sent to the printer from various locations, and a deviation from such baseline traffic may be when the printer begins sending out packets to the internet, which deviation could be an indication that the printer has been compromised and is now part of a botnet. As will be appreciated by the skilled reader, in each example, the baseline and deviation can be recognized without knowing anything specific about what is going on, just that an established pattern of usage has changed.

[0134] In some embodiments, active agents 611 , 613 are configured to route, encrypt, filter, and attenuate the bandwidth of information flows based on analysis of the stored metadata, and / or based on user profile configuration, for the purposes of enhancing or optimizing security and / or Quality of Service (QoS). In some embodiments, such analysis may be performed locally (e.g., by the active agent 611 , 613 on edge device 600) or remotely by secure cloud 620. In some embodiments, such analysis can be performed by a combination of local and remote analysis, in which some analysis is performed locally on edge device 600 and some remotely on the secure cloud 620, for example.

[0135] In some embodiments, active agents 611 , 613 are configured to generate alerts to be sent to the users associated with the user profiles used to instantiate and configure active agents 611 , 613. Such alerts may be sent to the users themselves and / or to one or more contacts at the organization whose restricted services are being accessed.

[0136] In some embodiments, active agents 611 , 613 are configured to provide “identity at the edge" functionality including, but not limited to, login into websites and / or webservices that are known and can interact with the secure cloud. For example, a user may wish to log into a website hosted on a web server. When the user opens their laptop and directs their browser to the website, the web server can acquire the IP address of the requesting laptop via the edge device, which may be doing Network Address Translation (NAT). The web server may, in cooperation with the secure cloud, match the IP address of the laptop to an IP address of one of active agents 611 , 613. The web sitemay then ask active agents 611 , 613 if either of them detected the website request. If, for example, active agent 611 confirms that it detected the website request, the authentication of active agent 611 is then further “extended” to the web site request. The web server may then return a cookie containing a standard “logged in" token for that particular user.

[0137] As such, by providing “identity at the edge” functionality, active agents can extend a user’s authentication (which was extended to it using known methods) to a website request, and thereby seamlessly and transparently login to websites and webservices without the need for user / password login procedures.

[0138] The devices, systems, and methods disclosed herein are directed to providing enhanced methods for communicating network packets between a containerized application and a host. While the applicant’s teachings described herein are in conjunction with various embodiments exemplary use cases for illustrative purposes, it is not intended that the applicant’s teachings be limited to such embodiments as the embodiments described herein are intended to be examples. On the contrary, the applicant’s teachings described and illustrated herein encompass various alternatives, modifications, and equivalents, without departing from the embodiments described herein, the general scope of which is defined in the appended claims.

Claims

CLAIMS1. A method of establishing packet communication between a containerized application and a network interface in a host environment, the method comprising: acquiring, from within the host environment, a token which represents access to a network interface; passing the token from the host environment into the container; and instantiating access to the network interface by the containerized application using the token and a portion of memory.

2. The method of claim 1 , wherein the token is a communication endpoint descriptor and the step of acquiring a token further comprises: establishing a communication endpoint in the host environment, the communication endpoint being associated with the communication endpoint descriptor; and using the communication endpoint descriptor to associate the communication endpoint to a network interface in the host environment.

3. The method of ciaim 2, wherein the step of passing the token into the container comprises: sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment.

4. The method of claim 3, wherein the portion of memory is a circular buffer, and the step of instantiating access comprises: allocating the circular buffer to the communication endpoint using the communication endpoint descriptor; and mapping the circular buffer to the containerized application.

5. The method of any one of claims 1 to 4, wherein the method further comprises: reading / writing packets from / to the portion of memory by the containerized application from within the container.

6. The method of any one of claims 2 to 5, wherein the method is carried out in a Unix- like environment, and wherein establishing a communication endpoint in the host environment and using the communication endpoint descriptor to associate the communication endpoint to a network interface in the host environment further comprise: creating a socket in the host environment using the socket() function; and binding a socket associated with the created file descriptor to the network interface using a bind() function.

7. The method of claim 6, wherein sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment comprises: sending the file descriptor from the host environment to the containerized application by way of a domain socket in the Unix environment.

8. The method of claim 7, wherein allocating the circular buffer to the communication endpoint using the communication endpoint descriptor and mapping the circular buffer to a containerized application further comprise: allocating the circular buffer to the socket with the file descriptor using the setsockopt() function; and mapping the circular buffer to the containerized application using the mmap() function.

9. The method of claim 8, when dependent on claim 5, wherein reading / writing packets from / to the portion of memory by the containerized application from within the container is performed using any one of memcpyQ, memmove(), and memsetQ.

10. The method of claim 9, wherein a kernel of the host environment reads / writes packets from / to the portion of memory using packetjrimap.

11. A non-transitory computer-readable storage medium storing a plurality of instructions executable by one or more processors, the plurality of instructions when executed by the one or more processors cause the one or more processors to execute the method of any one of ciaims 1 to 10.

12. A system comprising a first process running on a host environment and a second process running in a container, the system comprising: one or more computer processors; and one of more computer readable storage media for storing computer- implemented instructions, wherein the one or more computer processors are configured toexecute the computer-impiemented instructions to cause the computer system to perform a method comprising: acquiring, by the first process, from within the host environment, a token which represents access to a network interface; passing the token from the host environment into the container; and instantiating, by the second process, access to the network interface by the containerized a ppi i cation using the token and a portion of memory.

13. The system of claim 12, wherein the token is a communication end point descriptor and the step of acquiring a token further comprises: establishing a communication endpoint in the host environment, the communication endpoint being associated with the communication endpoint descriptor; and using the communication endpoint descriptor to associate the communication end point to a network interface in the host environment.

14. The system of ciaim 13, wherein the step of passing the token into the container comprises: sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment.

15. The system of ciaim 14, wherein the portion of memory is a circular buffer and the step of using the token comprises:allocating the circular buffer to the communication endpoint using the communication endpoint descriptor; and mapping the circular buffer to the containerized application.

16. The system of one of claims 12 to 15, wherein the method further comprises: reading / writing packets from / to the portion of memory by the containerized application from within the container.

17. The system of any one of claims 12 to 16, wherein the method is carried out in a Unix environment, and wherein establishing a communication endpoint in the host environment and using the communication endpoint descriptor to associate the communication endpoint to a network interface in the host environment further comprise: creating a socket in the host environment using the socketQ function; and binding a socket associated with the created file descriptor to the network interface using a bind() function.

18. The system of claim 17, wherein sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment comprises: sending the file descriptor from the host environment to the containerized application by way of a domain socket in the Unix environment.

19. The system of claim 18, wherein allocating the circular buffer to the communication endpoint using the communication endpoint descriptor and mapping the circuiar buffer to a containerized application further comprise: allocating the circular buffer to the socket with the file descriptor using the setsockopt() function; and mapping the circular buffer to the containerized application using the mmap() function.

20. The system of claim 19, when dependent on ciaim 16, wherein reading / writing packets from / to the portion of memory by the containerized application from within the container is performed using any one of memcpyO, memmovef), and memset().

21. The system of claim 20, wherein a kernel in the host environment reads / writes packets from / to the portion of memory using packetjrimap.

22. An edge device comprising an active agent manager running on a host environment and an active agent running in a container, the system comprising: one or more computer processors; and one of more computer readable storage media for storing computer- implemented instructions, wherein the one or more computer processors are configured to execute the computer-implemented instructions to cause the computer system to perform a method comprising: acquiring, by the active agent manager, from within the host environment, a token which represents access to a network interface; passing the token from the host environment into the container; andinstantiating, by the active agent, access to the network interface by the containerized application using the token and a portion of memory.

23. The edge device of claim 22, wherein the token is a communication endpoint descriptor and the step of acquiring a token further comprises: establishing a communication end point in the host environment, the communication end point being associated with the communication endpoint descriptor; and using the communication endpoint descriptor to associate the communication end point to a network interface in the host environment.

24. The edge device of ciaim 23, wherein the step of passing the token into the container comprises: sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment.

25. The edge device of claim 24, wherein the portion of memory is a circular buffer and the step of using the token comprises: allocating the circular buffer to the communication endpoint using the communication endpoint descriptor; and mapping the circuiar buffer to the containerized application.

26. The edge device of one of claims 22 to 25, wherein the method further comprises:reading / writing packets from / to the portion of memory by the containerized application from within the container.

27. The edge device of any one of ciaims 22 to 26, wherein the method is carried out in a Unix environment, and wherein establishing a communication endpoint in the host environment and using the communication endpoint descriptor to associate the communication end point to a network interface in the host environment further comprise: creating a socket in the host environment using the socket() function; and binding a socket associated with the created fiie descriptor to the network interface using a bind() function.

28. The edge device of ciaim 27, wherein sending the communication endpoint descriptor from the host environment to the containerized application by way of an inter-process communication method of the host environment comprises: sending the fiie descriptor from the host environment to the containerized appiication by way of a domain socket in the Unix environment.

29. The edge device of claim 28, wherein ailocating the circuiar buffer to the communication endpoint using the communication endpoint descriptor and mapping the circuiar buffer to a containerized application further comprise: aliocating the circular buffer to the socket with the fiie descriptor using the setsockopt() function; and mapping the circular buffer to the containerized application using the mmap() function.

30. The edge device of ciaim 29, when dependent on claim 26, wherein reading / writing packets from / to the portion of memory by the containerized application from within the container is performed using any one of memcpy(), memmove(), and memset().

31. The edge device of claim 30, wherein a kerne! in the host environment reads / writes packets from / to the portion of memory using packet_mmap.

Images