Methods, systems, and machine storage media for providing secure access to sandboxed user-defined functions

Abstract

This application relates to secure network access from sandboxed applications. Methods, systems, and computer programs are proposed to enable any sandboxed user-defined function code to securely access the Internet via a cloud data platform. The cloud data platform receives remote procedure calls from user-defined functions (UDFs) executing within a sandboxed process. The UDF includes code associated with at least one operation to be performed. The cloud data platform provides an overlay network to establish a secure exit path for external access to the UDF. The cloud data platform enables the UDF executing within the sandboxed process to initiate network calls.

Description

Technical Field

[0001] The topics disclosed in this article generally relate to methods, systems, machine storage media, and computer programs for providing secure access to sandboxed user-defined functions. background

[0002] Web-based database systems can be provided through cloud data platforms, allowing organizations, customers, and users to store, manage, and retrieve data from the cloud. Regarding this type of data processing, cloud data platforms can enable online transaction processing, online analytical processing, and / or another type of data processing. Furthermore, a cloud data platform can be or may include a relational database management system and / or one or more other types of database management systems.

[0003] Cloud-based data warehouses and other database systems sometimes offer support for custom user functions, such as user-defined functions (UDFs) or stored procedures, enabling these systems to perform operations that are not available through built-in system-defined functions. However, existing techniques for executing UDFs may lack robust security mechanisms to mitigate the associated security risks and ensure that user code is executed securely with sufficient audit visibility. Brief description of the attached diagram

[0004] As illustrated in the accompanying drawings, this disclosure will become apparent from the following more detailed description of examples of embodiments of the technology. The drawings are not necessarily drawn to scale, but rather focus on illustrating embodiments of the present disclosure. In the drawings, similar numbers may describe similar components in different views. Similar numbers with different letter suffixes may represent different instances of similar components. The various drawings illustrate only exemplary embodiments of the present disclosure and should not be considered as limiting the scope of the disclosure.

[0005] Figure 1 An example computing environment is shown according to some example embodiments, which includes a cloud data platform that communicates with a cloud storage provider's system.

[0006] Figure 2 This is a block diagram illustrating components of a computing service manager according to some example embodiments.

[0007] Figure 3 This is a block diagram illustrating components of an execution platform according to some example embodiments.

[0008] Figure 4 It is a computing environment based on some example embodiments, which conceptually illustrates an example software architecture for executing user-defined functions (UDFs) through processes running on a given execution node of an execution platform.

[0009] Figure 5 This is a block diagram illustrating the external access system architecture of user-defined functions (UDFs) according to some example embodiments.

[0010] Figure 6 This is a block diagram illustrating the external function access system architecture according to some example embodiments.

[0011] Figure 7 This is a block diagram illustrating a system architecture of an overlay network according to some example embodiments.

[0012] Figure 8 This is a block diagram illustrating the GENEVE package according to some example embodiments.

[0013] Figure 9 This is a block diagram illustrating a high-level overview of metrics and event flows according to some example embodiments.

[0014] Figure 10 This is a block diagram illustrating a high-level overview of eBPF mapping according to some example embodiments.

[0015] Figure 11 This is a block diagram illustrating eBPF-based packet routing according to some example embodiments.

[0016] Figure 12 This is a block diagram illustrating a packet routing graph according to some example embodiments.

[0017] Figure 13 This is a block diagram illustrating a packet routing graph, according to some example embodiments, depicting how returned packets are routed.

[0018] Figure 14 This is a block diagram illustrating an example service proxy process used by a cloud data platform to route and manage network traffic, according to some example embodiments.

[0019] Figure 15 This is a block diagram illustrating example methods used by a cloud data platform to route and manage network traffic, according to some example embodiments.

[0020] Figure 16 This is a block diagram illustrating an example method used by a cloud data platform to manage network traffic, according to some example embodiments.

[0021] Figure 17 This is a flowchart illustrating the operation of a cloud data platform according to some example embodiments, which executes example methods for allowing any sandboxed user-defined function code to access the Internet.

[0022] Figure 18 A schematic representation of a machine in the form of a computer system according to some example embodiments is shown, within which a set of instructions can be executed to cause the machine to perform any or more of the methods discussed herein. Detailed description

[0023] The following description includes systems, methods, techniques, instruction sequences, and computer program products embodying illustrative embodiments of the present disclosure. In the following description, numerous specific details are set forth for purposes of explanation in order to provide an understanding of various embodiments of the subject matter of the invention. However, it will be apparent to those skilled in the art that embodiments of the subject matter of the invention can be practiced without these specific details. Generally, well-known examples of instructions, protocols, structures, and techniques are not necessarily shown in detail.

[0024] From a user's perspective, external code can become a seamless part of the cloud data platform's functionality, much like any internally defined function or procedure. That is, the cloud data platform can access systems that are essentially outside the cloud data platform (e.g., geocoding systems). Furthermore, users can use any arbitrary external code, regardless of the language used to write the code or the system on which the code executes. Moreover, the cloud data platform described herein allows users to invoke external functions while avoiding the security issues that might arise from executing code within the cloud data platform, and doing so in an orthogonal manner to the functionality of the cloud data platform. Additionally, the techniques used to invoke external functions from the cloud data platform externalize security-sensitive authentication information, as this information is processed by the cloud data platform.

[0025] Example embodiments of this disclosure include cloud data platforms (e.g., cloud-based data warehouse platforms) that enable users to directly access the Internet from user-defined functions (UDFs), where the UDFs comprise code running in a sandboxed process or sandboxed environment. More specifically, example embodiments allow users to connect directly to external resources from sandboxed code. External access from UDFs is a critical requirement for users (e.g., customers) of cloud data platforms, which previous technical solutions (such as external functions) could not meet.

[0026] For the purposes of this description, the example embodiments can be applied to user-defined functions (UDFs), user-defined table functions (UDTFs), user-defined aggregate functions (UDAFs), external functions, Alternatively, this disclosure may be applied to or adopted other stored procedures used in relational databases for performing complex data processing tasks, enforcing business rules, etc. However, for simplicity, detailed embodiments will describe examples of providing secure external access directly to the internet to UDFs executing within a sandboxed environment using familiar programming languages ​​(e.g., Java, Scala, Python, etc.). It will be understood that the same principles can be applied to other types of database logic and programmatic constructs from both sandboxed and non-sandboxed environments. For example, although the example embodiments describe external access to user-defined functions in a sandboxed environment, similar logic can be applied to non-sandboxed environments, such as external access to user-defined functions in containerized environments, or other constructs of cloud data platforms.

[0027] In computer security, a sandbox (e.g., a sandbox environment) is a security mechanism used to isolate running programs, typically to prevent system failures or exploits of software vulnerabilities. Sandboxes can be used to execute untested or untrusted packages, programs, functions, or code (potentially from unverified or untrusted third parties, vendors, users, or websites) without risking damage to the host or operating system. Sandboxes can provide guest programs with a tightly controlled set of resources for running in, for example, storage devices and memory buffers. Network access, the ability to inspect the host system, or read from input devices may be prohibited or restricted. User-defined functions (UDFs) can typically run in a sandbox environment. Some example embodiments described herein can run in a sandbox environment, in conjunction with... Figure 4 The sandbox environment is described and depicted in more detail.

[0028] Traditional methods for accessing the internet require the use of external functions (described in detail below); however, sandboxed UDFs cannot directly access the internet. Currently, user code running in a sandboxed environment or sandboxed process cannot make network calls. The sandbox lacks network devices, and the necessary system calls are blocked. However, simply enabling networking within a sandbox is insufficient, as the cloud data platform must ensure that traffic only reaches permitted destinations, does not impact other workloads, and is well-monitored. For example, currently, users whose workloads within the cloud data platform want to access external services must use the external function feature, which restricts the service to implementing a Hypertext Transfer Protocol Secure (HTTPS) endpoint accessible from the cloud data platform and accepting JavaScript Object Notation (JSON) input while returning JSON output representing batches of lines. While the external function feature is important, it requires clients to be mindful of how they use batches of lines with external functions. Furthermore, while clients can mitigate JSON issues by leveraging client-side serializers / deserializers bundled with JavaScript, this previous solution is cumbersome. Therefore, while the previous solution allowed customers to use the existing external function features to piece together an end-to-end solution for their many data access needs, it was impractical and the customer experience was not very streamlined.

[0029] For example, an external function is a type of UDF that invokes executable code developed, maintained, stored, and executed outside the cloud data platform. This remotely executed code is called a remote service. Information sent to a remote service is typically relayed through a proxy service. Internally, the external function is stored as a database object containing information used by the cloud data platform to invoke the remote service. This stored information may include the Uniform Resource Locator (URL) of the proxy service, which relays information to or from the remote service (e.g., information specified as part of a CREATE EXTERNAL FUNCTION command). The remotely executed code, called a remote service, can behave like a function (e.g., it must return a value). An example of a remote service could be implemented as AWS. Functions, Microsoft Function, in An HTTPS server running on the instance (e.g., Node.js), etc. The cloud data platform directly calls a proxy service instead of the remote service, which relays data to the remote device. The proxy service can improve security by authenticating requests to the remote service. The proxy service can also relay responses from the remote service back to the cloud data platform. Examples of proxy services could include... Application Programming Interface (API) Gateway, Microsoft API management services, etc. Users can write and call their own remote services, or they can call remote services written by third parties. From the perspective of the user running Structured Query Language (SQL) statements, the external function behaves the same as any other UDF.

[0030] Implementing external functions can be cumbersome using existing solutions. To develop external functions, developers typically have to write code to transform batch processing into a format understandable by the final service they're using, where the code needs to exist externally (e.g., in a lambda function or a request converter in a cloud data platform). In any case, this transformation logic ultimately becomes separated from other logic that should belong to it (e.g., error handling, conditional business logic, etc.), making end-to-end maintenance difficult.

[0031] Existing solutions may have added complexity, making technological advancements necessary. For example, APIs may be non-standard, meaning the code required to generate or process batches of records in the format of a cloud data platform can be substantial and may be unique to the cloud data platform implementation. Based on some existing solutions, cloud data platforms currently expose scalar function interfaces for batch processing, requiring users who wish to implement table functions or stored procedures to support additional interfaces. Other existing limitations may include restricted interfaces that interact only via HTTP. To use protocols not mediated by HTTP (e.g., as with most underlying Java Database Connectivity (JDBC) connections), users must build and host an HTTP frontend outside the cloud data platform.

[0032] The examples disclosed herein overcome current technical challenges by providing a general and orthogonal solution that adds external access as an option to all sandboxed code in a cloud data platform. Leveraging external access as an orthogonal component, users are able to implement external variations of any contract exposed by the cloud data platform. Other improvements enable users to write standard code. For example, users already know how to interact with remote services, and they perform this interaction using standard libraries and strategies (e.g., Python request libraries, JDBC, etc.). Example embodiments allow users to incorporate or carry these libraries without modification and enable users to use these libraries with little or no change in their code. The examples disclosed herein overcome current technical challenges by maintaining security and providing control to account administrators. For example, machine administrators must explicitly control access to the outside of the system to prevent accidental data egress. Examples of such systems strictly enforce these controls and provide an agent-based approach to access data stored on a private network.

[0033] The exemplary embodiments of this disclosure overcome the technical challenges associated with internet access by providing strict exit controls and network isolation. The methods, systems, and computer programs described herein leverage the advantages of a secure exit path from a UDF running in a sandboxed process to the internet, allowing direct external access to the UDF. According to some examples, the systems, methods, and computer programs provide a mechanism that allows any sandboxed UDF code to securely reach hosts explicitly permitted by an account administrator (e.g., via an allowlist). Examples provide features and requirements that allow administrators and developers to write standard code and use familiar libraries to perform external access for various scenarios, while allowing account administrators to control data exit.

[0034] The novel solution presented in this paper overcomes previous technical challenges to internet access by providing a secure exit path from a UDF executed in a sandbox to the internet. This new solution allows UDFs to be written in standard code and utilize other third-party libraries, overcoming the usability challenges associated with external functions. For example, code for remote services can be written in languages ​​that other UDFs cannot use; remote services can use functions and libraries that are inaccessible to internal UDFs (e.g., remote services can interface with commercially available third-party libraries); developers can write remote services that can be invoked from cloud data platforms and from other software written to use the same interfaces, among other such technical advantages.

[0035] According to some example embodiments, allowing external access from a UDF will benefit both external customers of the cloud data platform and internal users of the cloud data platform (e.g., native applications, connectors, etc.). Unlocking (etc.). For example, customers and users may utilize data that may not always reside within the cloud data platform, such as metadata, reference data, or even low-latency caches. As illustrated in the examples given in this article, enabling direct external access provides users with a path to connect to these databases via tools such as JDBC or a database software development kit (SDK) to incorporate that data during larger query or data pipeline processes. Once internet access is enabled, code can also be written to interact with Kafka topics from within the cloud data platform.

[0036] In some example implementations, architectural improvements (e.g., functional and non-functional requirements) may include support for standard code and libraries, strict export controls, strict network isolation, performance, and / or additional improvements. For example, by supporting standard code and libraries, customers can bring their code and libraries from on-premises or other hosted environments without modification, such as the custom or proprietary APIs required by cloud data platforms. This overcomes one of the biggest usability challenges from previous solutions, such as external functions.

[0037] For example, by providing strict egress controls, any outbound traffic from the sandbox must pass through one or more egress proxies; however, if authorized by the database administrator, any outbound traffic can be allowed. The cloud data platform can guarantee strict egress controls because violations will be blocked and reported. Strict network isolation is provided because no outbound traffic from the sandbox is allowed to access any other sandbox or any other execution platform instance. Furthermore, the cloud data platform can manage performance, observability, and debuggability by providing efficient external access, while ensuring that outbound traffic is well monitored, tracked, and feedback is provided to both the cloud data platform and users.

[0038] Example implementations include technical solutions that go beyond the characteristics of previous external functions by providing direct access to services that inherently exist outside the cloud data platform. Additional examples include enabling users to store their API keys as secrets within the cloud data platform, configuring integration objects that allow the use of those API keys and access to remote APIs, and creating standard or relatively standard Java or Python functions that use the stored credentials to make invocations using standard APIs (e.g., requests).

[0039] Based on some examples, users may wish to ingest data from a third-party platform (e.g., Software-as-a-Service (SaaS) data ingestion), which effectively acts as a database and exposes a web API. While this can be achieved using existing scalar foreign functions, this prior approach is complex and requires additional steps. For example, using existing scalar foreign functions results in collections being packaged and returned as variable objects, which need to be decomposed when calling SQL, complicating the query call, requiring multiple calls, and / or requiring special handling of variable return types or error conditions. The example embodiments of this disclosure overcome the technical challenges of existing methods by providing direct sandbox access, which includes table function interface technology wrapped around standard methods for invoking and retrieving batches from external resources, thereby reducing the amount of one-off code required to implement these functions.

[0040] The example implementation also provides account administrators with additional features that enhance security, privileges, and capabilities. For instance, administrators can specify where sandboxed functions can connect, such as based on Domain Name System (DNS) names or wildcard-based DNS schemas. Administrators can grant and revoke these access permissions to developers in a fine-grained manner, allowing developers to apply granted access permissions to specific functions they create. Administrators can also selectively grant developers the ability to secretly connect to remote systems, and administrators can easily revoke access and prevent code leaks.

[0041] The example implementations provide developer users with the ability to create Transmission Control Protocol (TCP) or HTTP connections that can be exposed to authorized hosts using authorization already granted by their administrators. Developers can use standard APIs to establish these TCP or HTTP connections without needing to rewrite the JDBC connector to make it work with the cloud data platform's TCP system. Other examples enable external access to any type of sandboxed code, such as UDFs, UDTFs, UDAFs, User Datagram Protocol (UDP), etc. Additional example implementations provide developer users with the ability to enable batch requests. For example, if a user wants to call a batch scalar function (e.g., HERE geocoder), the user can write a batch UDF to do so.

[0042] The additional examples of the system disclosed in this document prevent code from establishing any connections to hosts not authorized by its specification, and prevent developers from authorizing any code to connect to hosts to which they have not been granted access. The system can prevent any user from seeing the contents of a secret unless that permission has been explicitly granted; for example, a caller of a function should not gain access to a secret simply because they can call that function. Examples of this system can further prevent code from making any DNS requests to hosts to which it is not authorized (e.g., exfiltration risk). The system can ensure external control over any network access, thereby allowing such requests to be routed through a cloud data platform egress proxy, and compromised execution platform nodes should not be able to bypass such restrictions. The additional examples of the system disclosed in this document can capture and report, to account administrators, any attempts to open connections to or perform DNS lookups that are permitted but not authorized.

[0043] Figure 1 An example computing environment 100 according to some embodiments of the present disclosure is shown, which includes a database system in the form of a cloud data platform 102. To avoid obscuring the subject matter of the invention with unnecessary detail, Figure 1Various functional components not directly relevant to conveying an understanding of the subject matter of this invention have been omitted. However, those skilled in the art will readily recognize that various additional functional components may be included as part of the computing environment 100 to facilitate additional functionality not specifically described herein. In other embodiments, the computing environment may include another type of network-based database system or cloud data platform.

[0044] As shown in the figure, computing environment 100 includes a cloud storage platform 104 (e.g., Microsoft Azure Blob or Cloud data platform 102 (cloud storage) communication. Cloud data platform 102 is a network-based system used to report and analyze integrated data from one or more different sources, including one or more storage locations within cloud storage platform 104. Cloud data platform 102 can be a network-based data platform or a network-based data system. Cloud storage platform 104 includes a plurality of computing machines and provides computing system resources, such as data storage and computing power, to cloud data platform 102 on demand.

[0045] The cloud data platform 102 includes a computing service manager 108, an execution platform 110, an agent service 115, and one or more metadata databases 112. The cloud data platform 102 hosts data reporting and analysis services and provides these services to multiple client accounts.

[0046] The Computation Service Manager 108 coordinates and manages the operations of the cloud data platform 102. The Computation Service Manager 108 also performs query optimization and compilation, as well as manages the cluster of computing services (also known as a “virtual repository”) that provide computing resources. The Computation Service Manager 108 can support any number of client accounts, such as end users providing data storage and retrieval requests, system administrators managing the systems and methods described herein, and other components / devices that interact with the Computation Service Manager 108.

[0047] The Compute Service Manager 108 also communicates with client device 114. Client device 114 corresponds to a user of one of multiple client accounts supported by the cloud data platform 102. Users can use client device 114 to submit data storage, retrieval, and analysis requests to the Compute Service Manager 108.

[0048] The compute service manager 108 is also coupled to one or more metadata databases 112, which store metadata about various functions and aspects associated with the cloud data platform 102 and its users. For example, the metadata database 112 may include a summary of data stored in a remote data storage system and data available from a local cache. Additionally, the metadata database 112 may include information about how the data is organized in the remote data storage system (e.g., cloud storage platform 104) and the local cache. The information stored in the metadata database 112 allows systems and services to determine whether a piece of data needs to be accessed without loading or accessing the actual data from storage devices.

[0049] The compute service manager 108 is also coupled to an execution platform 110, which provides multiple compute resources for performing various data storage and retrieval tasks. The execution platform 110 is coupled to a cloud storage platform 104. The cloud storage platform 104 includes multiple data storage devices 120-1 to 120-N. In some embodiments, data storage devices 120-1 to 120-N are cloud-based storage devices located in one or more geographical locations. For example, data storage devices 120-1 to 120-N may be part of a public cloud infrastructure or a private cloud infrastructure. Data storage devices 120-1 to 120-N may be hard disk drives (HDDs), solid-state drives (SSDs), storage clusters, Amazon S3, etc. TM Storage systems or any other data storage technologies. Additionally, cloud storage platform 104 may include distributed file systems (e.g., Hadoop Distributed File System (HDFS)), object storage systems, etc.

[0050] Execution platform 110 includes multiple compute nodes. A set of processes on each compute node executes a query plan compiled by compute service manager 108. The set of processes may include: a first process executing the query plan; a second process that uses a least recently used (LRU) policy to monitor and delete cache files and implements out-of-memory (OOM) error mitigation; a third process that extracts health information from process logs and status to send back to compute service manager 108; a fourth process that establishes communication with compute service manager 108 after system boot; and a fifth process that handles all communication with the compute cluster for a given job provided by compute service manager 108 and transmits information back to compute service manager 108 and other compute nodes of execution platform 110.

[0051] The Compute Service Manager 108, Metadata Database 112, Agent Service 115, and Execution Platform 110 are operatively connected to a platform agent 109, which provides an agent within the Execution Platform 110 as a long-running service to handle operations related to Extended Berkeley Packet Filtering (eBPF). The platform agent 109 may include a Remote Procedure Call (RPC) server via a Unix domain socket that can handle requests sent from the execution platform's worker process. Sample requests may include loading specific eBPF programs, reading / writing BPF mappings, configuring network devices, etc. The platform agent 109 can further handle external access to BPF code and can be extended to capture more BPF use cases while receiving relevant cloud data platform information from any of the following: the Compute Service Manager 108, Metadata Database 112, Agent Service 115, Execution Platform 110, or data sources from alternative operatively connected modules within the cloud data platform 102 or external connections. Figure 6 The platform agent program 109 is described and illustrated.

[0052] In some embodiments, communication links between components of computing environment 100 are implemented via one or more data communication networks. These data communication networks can utilize any communication protocol and any type of communication medium. In some embodiments, the data communication network is a combination of two or more data communication networks (or subnetworks) coupled to each other. In alternative embodiments, these communication links are implemented using any type of communication medium and any communication protocol.

[0053] The computing service manager 108, metadata database 112, execution platform 110, platform agent 109, agent service 115, and cloud storage platform 104 are in Figure 1 The cloud data platform 102 is shown as an independent, discrete component. However, each of the compute service manager 108, metadata database 112, agent service 115, execution platform 110, platform agent 109, and cloud storage platform 104 can be implemented as a distributed system (e.g., multiple systems / platforms distributed across multiple geographical locations). Furthermore, each of the compute service manager 108, metadata database 112, execution platform 110, platform agent 109, agent service 115, and cloud storage platform 104 can scale (independently) according to changes in received requests and the changing needs of the cloud data platform 102. Therefore, in the described embodiment, the cloud data platform 102 is dynamic and supports periodic changes to meet current data processing needs.

[0054] During typical operation, cloud data platform 102 processes multiple jobs determined by compute service manager 108. These jobs are scheduled and managed by compute service manager 108 to determine when and how to execute the job. For example, compute service manager 108 can divide the job into multiple discrete tasks and determine what data is needed to execute each of the multiple discrete tasks. Compute service manager 108 can assign each of the multiple discrete tasks to one or more nodes of execution platform 110 to process the task. Compute service manager 108 can determine what data is needed to process the task and further determine which nodes within execution platform 110 are best suited to process the task. Some nodes may already have cached the data required to process the task and are therefore appropriate candidates for processing the task. Metadata stored in metadata database 112 helps compute service manager 108 determine which nodes in execution platform 110 have cached at least a portion of the data required to process the task. One or more nodes in execution platform 110 use the data cached by the nodes and, if necessary, data retrieved from cloud storage platform 104 to process the task. The goal is to retrieve as much data as possible from the cache within the execution platform 110, as retrieval is typically much faster than retrieving data from the cloud storage platform 104.

[0055] like Figure 1 As shown, the computing environment 100 separates the execution platform 110 from the cloud storage platform 104. In this arrangement, the processing resources and cache resources in the execution platform 110 operate independently of the data storage devices 120-1 to 120-N in the cloud storage platform 104. Therefore, the computing resources and cache resources are not limited to specific data storage devices 120-1 to 120-N. Instead, all computing resources and all cache resources can retrieve data from any data storage resource in the cloud storage platform 104, and store data to any data storage resource in the cloud storage platform 104.

[0056] Platform agent 109 is shown as a component of execution platform 110; however, according to some embodiments of this disclosure, additional example embodiments of platform agent 109 may be implemented by any virtual repository of execution platform 110 (such as execution node 302-1), compute service manager 108, request processing service 208, security manager 422 and / or external components of cloud data platform 102.

[0057] Figure 2 This is a block diagram 200 illustrating components of a computing service manager 108 according to some embodiments of the present disclosure. Figure 2As shown, the compute service manager 108 includes a credential management system 204 and an access manager 202 coupled to an access data storage device 206, which is an example of a metadata database 112. The access manager 202 handles authentication and authorization tasks for the system described herein. The credential management system 204 facilitates access to external resources, such as data resources in a remote storage device, using credentials stored remotely. As used herein, a remote storage device may also be referred to as a “persistent storage device” or a “shared storage device.” For example, the credential management system 204 may (e.g., in the data storage device 206) create and maintain remote credential store definitions and credential objects. A remote credential store definition identifies the remote credential store and includes access information for accessing secure credentials from the remote credential store. A credential object uses non-sensitive information (e.g., a text string) to identify one or more secure credentials retrieved from the remote credential store for accessing external resources. When a request to access an external resource is received at runtime, the credential management system 204 and the access manager 202 use information stored in the data storage device 206 (e.g., credential objects and credential store definitions) to retrieve security credentials for accessing the external resource from the remote credential store.

[0058] Request processing service 208 manages received data storage requests and data retrieval requests (e.g., jobs to be performed on database data). For example, request processing service 208 can determine the data to process in a received query (e.g., a data storage request or a data retrieval request). The data can be stored in a cache within execution platform 110 or in a data storage device within cloud storage platform 104.

[0059] The Management Console Service 210 supports administrators and other system administrators in accessing various systems and processes. Additionally, the Management Console Service 210 can receive requests to execute jobs and monitor workloads on the system.

[0060] The compute service manager 108 also includes a job compiler 212, a job optimizer 214, and a job executor 216. The job compiler 212 parses a job into multiple discrete tasks and generates execution code for each of these tasks. The job optimizer 214 determines the optimal method for executing the multiple discrete tasks based on the data to be processed. The job optimizer 214 also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of job execution. The job executor 216 executes the execution code of jobs received from the queue or determined by the compute service manager 108.

[0061] The job scheduler and coordinator 218 sends received jobs to appropriate services or systems for compilation, optimization, and dispatch to execution platform 110. For example, jobs may be prioritized and then processed in priority order. In embodiments, the job scheduler and coordinator 218 determines the priority of internal jobs scheduled by compute service manager 108 compared to other "external" jobs (such as user queries that may be scheduled by other systems in the database but can utilize the same processing resources in execution platform 110). In some embodiments, the job scheduler and coordinator 218 identifies or assigns specific nodes in execution platform 110 to handle specific tasks. A virtual repository manager 220 manages the operation of multiple virtual repositories implemented in execution platform 110. For example, the virtual repository manager 220 may generate query plans for executing received queries.

[0062] Additionally, the Compute Service Manager 108 includes a Configuration and Metadata Manager 222, which manages information related to data stored in remote data storage devices and local buffers (e.g., buffers in the execution platform 110). The Configuration and Metadata Manager 222 uses metadata to determine which data files need to be accessed to retrieve data for processing specific tasks or jobs. The Monitor and Workload Analyzer 224 oversees the processes executed by the Compute Service Manager 108 and manages the distribution of tasks (e.g., workloads) among execution nodes and virtual repositories in the execution platform 110. The Monitor and Workload Analyzer 224 also reallocates tasks as needed based on the changing workload across the cloud data platform 102, and can also reallocate tasks based on workload queries from users (e.g., "external") that can also be processed by the execution platform 110. The Configuration and Metadata Manager 222 and the Monitor and Workload Analyzer 224 are coupled to the data storage device 226. Figure 2 Data storage device 226 in the context refers to any data storage device within the cloud data platform 102. For example, data storage device 226 could represent a buffer in the execution platform 110, a storage device in the cloud storage platform 104, or any other storage device.

[0063] As described in this embodiment, the compute service manager 108 verifies all communication from the execution platform (e.g., execution platform 110) to ensure that the content and context of the communication are consistent with the tasks known to be assigned to the execution platform. For example, an instance of the execution platform executing query A should not be allowed to request access to a data source D (e.g., data storage device 226) unrelated to query A. Similarly, a given execution node (e.g., execution node 302-1) may need to communicate with another execution node (e.g., execution node 302-2) and should be prohibited from communicating with a third execution node (e.g., execution node 312-1), and any such illegal communication may be logged (e.g., in a log or other location). Furthermore, information stored on a given execution node is limited to data relevant to the current query; any other data is unavailable and is destroyed or encrypted if the key is unavailable.

[0064] Figure 3 This is a block diagram 300 illustrating components of an execution platform 110 according to some embodiments of the present disclosure. Figure 3 As shown, execution platform 110 includes multiple virtual repositories, including virtual repository 1, virtual repository 2, and virtual repository N. Each virtual repository includes multiple execution nodes, and each execution node includes a data cache and a processor. Virtual repositories can execute multiple tasks in parallel using multiple execution nodes. As discussed herein, execution platform 110 can add new virtual repositories and delete existing virtual repositories in real time based on the current processing needs of the system and users. This flexibility allows execution platform 110 to quickly deploy large amounts of computing resources when needed, without having to continue paying for those computing resources when they are no longer needed. All virtual repositories can access data in any data storage device (e.g., any storage device in cloud storage platform 104).

[0065] although Figure 3 Each virtual repository shown includes three execution nodes, but a particular virtual repository can include any number of execution nodes. Furthermore, the number of execution nodes in a virtual repository is dynamic, allowing for the creation of new execution nodes when there is additional demand and the deletion of existing execution nodes when they are no longer needed.

[0066] Each virtual repository can access Figure 1 The data storage devices 120-1 to 120-N shown are used. Therefore, the virtual warehouse does not need to be assigned to a specific data storage device 120-1 to 120-N, but can access data from any of the data storage devices 120-1 to 120-N within the cloud storage platform 104. Similarly, Figure 3Each execution node shown can access data from any of the data storage devices 120-1 to 120-N. In some embodiments, a particular virtual repository or a particular execution node may be temporarily assigned to a specific data storage device, but that virtual repository or execution node may later access data from any other data storage device.

[0067] exist Figure 3 In the example, virtual repository 1 includes three execution nodes 302-1, 302-2, and 302-N. Execution node 302-1 includes a cache 304-1 and a processor 306-1. Execution node 302-2 includes a cache 304-2 and a processor 306-2. Execution node 302-N includes a cache 304-N and a processor 306-N. Each execution node 302-1, 302-2, and 302-N is associated with processing one or more data storage and / or data retrieval tasks. For example, a virtual repository may handle data storage and data retrieval tasks associated with internal services such as clustering services, instantiated view refresh services, file compression services, stored procedure services, or file upgrade services. In other embodiments, a particular virtual repository may handle data storage and data retrieval tasks associated with a particular data storage system or a particular category of data.

[0068] Similar to Virtual Repository 1 discussed above, Virtual Repository 2 includes three execution nodes: 312-1, 312-2, and 312-N. Execution node 312-1 includes cache 314-1 and processor 316-1. Execution node 312-2 includes cache 314-2 and processor 316-2. Execution node 312-N includes cache 314-N and processor 316-N. Additionally, Virtual Repository N includes three execution nodes: 322-1, 322-2, and 322-N. Execution node 322-1 includes cache 324-1 and processor 326-1. Execution node 322-2 includes cache 324-2 and processor 326-2. Execution node 322-N includes cache 324-N and processor 326-N.

[0069] In some embodiments, Figure 3 The execution nodes shown are stateless relative to the data cached by the execution nodes. For example, these execution nodes do not store or otherwise maintain state information about the execution node or data cached by a specific execution node. Therefore, in the event of an execution node failure, the failed node can be transparently replaced by another node. Because there is no state information associated with the failed execution node, a new (replacement) execution node can easily replace the failed node without considering the need to recreate specific state.

[0070] although Figure 3The execution node shown includes a data cache and a processor; however, alternative embodiments may include execution nodes containing any number of processors and any number of caches. Additionally, the size of the cache may vary between different execution nodes. Figure 3 The cache shown stores data retrieved from one or more data storage devices in the cloud storage platform 104 within the local execution node. Therefore, the cache reduces or eliminates bottlenecks that occur in platforms that continuously retrieve data from remote storage systems. Instead of repeatedly accessing data from remote storage devices, the systems and methods described herein access data from a cache within the execution node, which is significantly faster and avoids the bottlenecks discussed above. In some embodiments, the cache is implemented using a high-speed memory device that provides fast access to the data in the cache. Each cache may store data from any storage device in the cloud storage platform 104.

[0071] Furthermore, cache resources and compute resources can vary across different execution nodes. For example, one execution node may contain a large amount of compute resources and a minimal amount of cache resources, making it suitable for tasks requiring significant compute resources. Another execution node may contain a large amount of cache resources and a minimal amount of compute resources, making it suitable for tasks requiring the caching of large amounts of data. Yet another execution node may contain cache resources that provide faster input-output operations, which is useful for tasks requiring the rapid scanning of large amounts of data. In some embodiments, the cache resources and compute resources associated with a particular execution node are determined at the time of its creation based on the expected tasks that the execution node will perform.

[0072] Furthermore, the cache and compute resources associated with a specific execution node can change over time based on the changing tasks performed by that node. For example, if the tasks performed by the execution node become more processor-intensive, more processing resources can be allocated to that node. Similarly, if the tasks performed by the execution node require larger cache capacity, more cache resources can be allocated to that node.

[0073] Although virtual repositories 1, 2, and N are associated with the same execution platform 110, they can be implemented using multiple computing systems located in multiple geographical locations. For example, virtual repository 1 may be implemented by a computing system located in a first geographical location, while virtual repository 2 and virtual repository N may be implemented by another computing system located in a second geographical location. In some embodiments, these different computing systems are cloud-based computing systems maintained by one or more different entities.

[0074] In addition, each virtual repository in Figure 3The virtual repository is shown as having multiple execution nodes. Multiple computing systems located in multiple geographic locations can be used to implement multiple execution nodes associated with each virtual repository. For example, an instance of virtual repository 1 implements execution nodes 302-1 and 302-2 on a computing platform in one geographic location, while implementing execution node 302-N on a different computing platform in another geographic location. The selection of a specific computing system to implement execution nodes can depend on various factors, such as the resource level required by the specific execution node (e.g., processing resource requirements and cache requirements), the resources available at the specific computing system, the communication capabilities of networks within or between geographic locations, and which computing systems have already implemented other execution nodes in the virtual repository.

[0075] Execution platform 110 is also fault-tolerant. For example, if a virtual repository fails, it will be quickly replaced by a different virtual repository located in a different geographical location. A particular execution platform 110 can include any number of virtual repositories. Furthermore, the number of virtual repositories in a particular execution platform is dynamic, allowing the creation of new virtual repositories when additional processing and / or caching resources are needed. Similarly, existing virtual repositories can be deleted when the resources associated with them are no longer needed.

[0076] In some embodiments, virtual repositories can operate on the same data in cloud storage platform 104, but each virtual repository has its own execution node with independent processing and caching resources. This configuration allows requests on different virtual repositories to be processed independently without interference between them. This independent processing, combined with the ability to dynamically add and remove virtual repositories, supports adding new processing capabilities for new users without impacting performance.

[0077] Figure 4 This is a computing environment 400 according to some embodiments of the present disclosure, which conceptually illustrates the use of... Figure 3 An example software architecture for executing user-defined functions (UDFs) by running processes on a given execution node of the execution platform 110.

[0078] As shown in the figure, the execution node 302-1 from the execution platform 110 includes an execution node process 410. In one embodiment, the execution node process 410 runs on the processor 306-1 and may also utilize memory from the cache 304-1 (or another memory device or storage apparatus). As described herein, a “process” or “computational process” can refer to an instance of a computer program executed by one or more threads of the execution node or execution platform.

[0079] As previously described, the compute service manager 108 verifies all communication from the execution platform 110 to ensure that the content and context of the communication are consistent with the tasks known to be assigned to the execution platform 110. For example, the execution platform 110 executing query A is not permitted to request access to a specific data source unrelated to query A (e.g., data storage device 226 or any storage device in the cloud storage platform 104). In one example, execution node 302-1 might need to communicate with a second execution node (e.g., execution node 302-2), but the security mechanisms described herein may disallow communication with a third execution node (e.g., execution node 312-1). Furthermore, any such illegal communication may be logged (e.g., in log 444 or elsewhere). Additionally, information stored on a given execution node is restricted to data relevant to the current query, and any other data cannot be accessed by destroying or encrypting it if the key is unavailable.

[0080] exist Figure 4 In the example, the execution node process 410 is executing the UDF client 412. In one embodiment, the UDF client 412 is implemented to support UDFs written in a specific programming language such as JAVA. In another embodiment, the UDF client 412 is implemented in a different programming language (e.g., C or C++) than the user code 430, which can further enhance the security of the computing environment 400 by using a different codebase (e.g., a codebase with the same or fewer potential security vulnerabilities).

[0081] User code 430 may be provided as a data package, for example, in the form of a JAR (Java Archive) file, which includes the code for one or more UDFs. In one embodiment, server implementation code 432 is a JAR file that starts a server responsible for receiving requests from the execution node process 410, allocating worker threads to execute the user code, returning results, and other types of server tasks.

[0082] In one implementation, operations from a UDF (e.g., a Java-based UDF) can be performed by a user code runtime 424 that executes within a sandbox process 420. In one embodiment, the user code runtime 424 is implemented as a virtual machine, such as the Java Virtual Machine (JVM). Because the user code runtime 424 executes in a separate process relative to the execution node process 410, the risk of manipulating the execution node process 410 is low. The results of the operations, among other types of information or messages, can be stored in a log 444 for viewing and retrieval. In one embodiment, the log 444 can be stored locally in memory at the execution node 302-1, or in a separate location such as a cloud storage platform 104.

[0083] Examples of Log 444 can include observable and debuggable logging. Logging can be automatically configured to observe egress traffic using a logging mechanism with runtime-configurable verbosity levels. For example, using event output logging or event output helpers can allow custom structures, along with optional packet samples, to be passed from an eBPF program to a performance event ring buffer. In response, for example, an execution platform worker can extract logs from Log 444 or extract additional logs from the buffer and write them to the execution platform log. This channel can be used for logging, debugging, sampling, and / or pushing notifications of network policy violations. For example, event output logging or helpers can be configured to pass data through a lock-free, memory-mapped per-CPU performance ring buffer, which is significantly faster (e.g., more efficient) than the default logging support in eBPF.

[0084] Additional examples of logs 444 or other logs from the cloud data platform 102 can be used to provide clear and actionable feedback to the user when their UDF packets are blocked. Utilizing the logging mechanism, the cloud data platform 102 or its components can report details back to the user (e.g., which IP and port have been blocked or which account policy has been violated). Additionally, when an unauthorized DNS request is blocked, the eBPF program can intercept the packet and report back the hostname it was trying to access, entering this information into log 444. This is valuable in helping customers troubleshoot and debug their UDFs.

[0085] Furthermore, high-performance protocols that further provide authentication and encryption for data transmission (e.g., no data serialization or deserialization, no memory copies; operations on batches of records without accessing individual columns, records, or cells; utilizing efficient remote procedure call techniques and network protocols for data transmission) can be used for data transmission (e.g., distributed datasets) to return such results from the user code runtime 424 to the UDF client 412. In one embodiment, the UDF client 412 uses a data transmission mechanism that supports network transmission of columnar data between user code runtimes 424 (and vice versa).

[0086] In one example, security manager 422 can prevent the completion of an operation from a given UDF by throwing an exception (e.g., if the operation is not permitted), or return (e.g., do nothing) if the operation is permitted. In one implementation, security manager 422 is implemented as a Java security manager object, which allows applications to implement security policies such as security manager policy 442, and enables applications to determine what an operation is and whether it is being attempted within a security context that allows the operation to be performed before performing a potentially unsafe or sensitive operation. Security manager policy 442 can be implemented as a file with permissions granted by user code runtime 424. Therefore, an application (e.g., a UDF executed by user code runtime 424) can allow or disallow the operation at least in part based on the security policy.

[0087] In one embodiment, sandbox process 420 is a child process (or a separate process) of execution node process 410. In one embodiment, a sub-process refers to a child process of a given parent process (e.g., execution node process 410 in this example). In one example, sandbox process 420 is a program that reduces the risk of security vulnerabilities by restricting the runtime environment of untrusted applications through security mechanisms such as namespaces and secure computation patterns (e.g., reducing the attack surface to a given operating system kernel by using system call filters on the executing process and all its descendants). Furthermore, in one example, sandbox process 420 is a lightweight process compared to execution node process 410 and is optimized (e.g., security mechanisms tightly coupled to a given operating system kernel) to handle database queries securely within the sandbox environment.

[0088] For example, an instance of a computer program can be instantiated by execution platform 110. For example, execution node 302-1 can be configured to instantiate a user code runtime to execute UDF code and / or create a runtime environment that allows the execution of user code. The user code runtime may include an access control process, which includes access control lists, wherein the access control lists include authorized hosts and access permissions or other types of allowed lists and / or block lists with access control information. Instantiating a sandbox process can determine whether the UDF is allowed and instantiates the user code runtime as a child process of the sandbox process, which is configured to perform at least one operation within the sandbox environment.

[0089] In one embodiment, the sandbox process 420 can utilize virtual network connections to communicate with other components within the subject system. A specific set of rules can be configured for the virtual network connection against other components of the subject system. For example, such rules can be configured for a specific UDF to restrict the locations accessible to operations performed by the UDF (e.g., specific sites on the Internet or components the UDF can communicate with). Therefore, in this example, the UDF can be denied access to specific network locations or sites on the Internet.

[0090] Sandbox process 420 can be understood as providing a constrained computing environment to processes (or multiple processes) within a sandbox, where these constrained processes can be controlled and restricted to limit access to certain computing resources.

[0091] Examples of security mechanisms may include: namespace implementations where each corresponding process group executing in the sandbox environment can access corresponding computing resources (e.g., process ID, hostname, user ID, filename, name associated with network access, inter-process communication, etc.) that are inaccessible to another process group (which can access different resource groups inaccessible to the previous process group); other container implementations, etc. By making the sandbox process 420 execute as a child process of the execution node process 410, in some embodiments, the wait time for processing a given database query can be significantly reduced (e.g., in some cases, the wait time is reduced to one-tenth) compared to other techniques that can utilize virtual machine solutions alone.

[0092] As further shown, sandbox process 420 can utilize sandbox policy 440 to implement a given security policy. Sandbox policy 440 may be a file containing information related to the configuration of sandbox process 420, as well as details regarding restrictions (if any) and permissions for accessing and utilizing system resources. Example restrictions may include restrictions on network access or file system access (e.g., remapping a file system to place files in different locations that may not be accessible, other files may be mounted in different locations, etc.). Sandbox process 420 restricts the use of memory and processor (e.g., CPU) by user code runtime 424, ensuring that other operations on the same execution node can be performed without exhausting resources.

[0093] As described above, sandbox process 420 is a child process (or independent process) of execution node process 410, which effectively means that sandbox process 420 resides in a separate memory space from execution node process 410. In the event of a security vulnerability associated with sandbox process 420 (e.g., a bug or malicious code from a given UDF), if arbitrary memory is accessed by a malicious actor, the data or information stored by the execution node process is protected.

[0094] althoughFigure 4 The above discussion describes components implemented using JAVA (e.g., an object-oriented programming language); however, it should be understood that computing environment 400 supports other programming languages ​​(e.g., interpreted programming languages). In one embodiment, PYTHON is supported for implementing and executing UDFs within computing environment 400. In this example, user code runtime 424 can be replaced by a PYTHON interpreter for executing operations from UDFs (e.g., written in PYTHON) within sandbox process 420.

[0095] Figure 5 A block diagram is shown illustrating an example embodiment of a user-defined function (UDF) external access system architecture 500 according to some example embodiments.

[0096] Such as combination Figure 5 The described and depicted system architecture 500 shows a high-level diagram of the components involved in ensuring the security of the exit to the target host (the exit path will be described in detail below). In the example shown, key 501 provides solid arrows representing control flow (e.g., control path) and dashed arrows representing data flow (e.g., data path) among or between corresponding components of the external access architecture of the UDF. Specifically, example system architecture 500 shows the control and data flows between compute service manager 108, execution platform 110, agent service 115, and target host 550.

[0097] Below is an example of defining a UDF that wants to access maps.googleapis.com (e.g., external access) for geocoding, where the SQL syntax is just one possible example of the applicable code:

[0098]

[0099]

[0100] When the example code above (e.g., UDF) is used in a query, one or more of the following actions are performed.

[0101] UDF 518 can be authorized to access maps.googleapis.com via external access integration 519. External access integration 519 can be an existing or new type of integration object used to control a user's ability to contact a specific host or a group of hosts (e.g., target host 550). For example, external access integration 519 can be used to control locations that can be connected to via sandboxed functions (e.g., UDF 518). In some example embodiments, once a user is granted access to the integration, how the user connects to the host or what they do on the host is unrestricted. Like other integrations, they can only be created by an account administrator, who can then grant access rights (USAGE) to the integration to grant privileges to other users (e.g., roles on the account). According to some examples, this integration can be used for access control; for example, a user with access rights to the integration can construct functions that can access hosts matching a provided allowed list, and then functions whose owners have access rights to the integration are allowed to access those hosts.

[0102] A function (e.g., UDF 518) can specify the specific endpoint or set of endpoints to which the function will connect. This provides the system with a specific host to open queries that use the function. Once this is configured, clients can use standard networking calls as long as the target host 550 is configured. As shown in the example, with proper integration, users can access any endpoint they want (assuming they have the appropriate credentials). To promote good practices for handling credentials, the cloud data platform 102 or its components can adopt secret objects (e.g., an account administrator can provide new credentials including a secret). A user with read (READ) privileges on the secret credentials can then use it to create functions. Unlike the right to use a secret, the right to read allows the contents of the secret to be read from within the UDF.

[0103] Once UDF 518 is authorized, Compute Service Manager 108 or its components can generate an exit policy and sign the exit policy against the UDF (e.g., a signed exit policy 521). Once signed, Compute Service Manager 108 can either pass the signed exit policy 521 or have the exit policy passed to Execution Platform 110 using a query execution plan. The exit policy contains one or more lists of allowed IP addresses (e.g., maps.googleapis.com in this example case).

[0104] The execution platform worker 502 (such as execution node 302-1) will perform two tasks before the UDF begins. First, the execution platform worker 502 will transmit a policy or cause the policy to be transmitted to an egress agent, such as proxy agent 505. Second, the execution platform worker 502 will initiate or set a secure egress path (described in more detail below) for the sandbox process where the UDF resides. Once the UDF 518 starts running, egress traffic from the UDF 518 will be strictly forwarded through the secure egress path to proxy agent 505 (e.g., the egress agent) and ultimately allowed to reach the target public host (e.g., target host 550) through egress gateway 541.

[0105] According to some examples, system architecture 500 also shows a secure exit path 531, which can be configured in different ways, such as by implementing exit controls on network layers 3, 4 and / or 7 and / or using overlay networks to establish a secure exit path to achieve strict exit control and isolation.

[0106] When considering how data is transmitted over a network at Layer 3 (L3) (e.g., network layer), Layer 4 (L4) (e.g., transport layer), and Layer 7 (L7) (e.g., application layer) of the Open Systems Interconnection (OSI) model, customers can be provided with the ability to control outbound traffic at the network, transport, and / or application layers. For example, Layer 3 and Layer 4 outbound control can provide customers with the ability to restrict outbound traffic to specific IP addresses and ports, while Layer 7 outbound control can provide customers with the ability to control more stringent filtering based on, for example, destination and request content (e.g., Uniform Resource Identifier (URI) path, query parameters, headers, etc.). Layer 7 control can provide additional observability, such as the ability for customers and / or cloud data platforms to determine which specific Representational State Transmission (REST) ​​APIs were accessed, while Layer 3 and Layer 4 control can provide logs about IP addresses and ports. For example, Layer 3 / 4 egress controls (e.g., L3 / L4 egress rules) could include allowing only traffic to flow to maps.googleapis.com on port 443; while Layer 7 egress controls (e.g., L7 egress rules) could include allowing only HTTP(S) GET requests to https: / / maps.googleapis.com / maps / api / geocode. As the example shows, by enabling clients to declare that traffic should only flow to maps.googleapis.com, using L3 / L4 egress controls can provide coarse-grained control for some L7 use cases, even if clients cannot declare which REST APIs are allowed.

[0107] In addition to L3 / L4 / L7 exit controls, the example can provide a secure exit path from execution platform 110 to an exit agent or proxy server (e.g., proxy service 115). By providing a secure exit path, support for standard libraries used for network access can be provided. Besides being transparent to user code, the secure exit path 531 for external access to UDFs can also include strict exit isolation, strict exit controls, and / or exit agent implementations. For example, from sandbox 520 (which can be combined with...) Figure 4 Egress traffic from sandbox processes 420 (which are identical or similar to those described and depicted) can be isolated from other sandboxes and existing execution platform workloads, while unauthorized egress traffic can be blocked and / or reported. In some examples, the egress proxy (e.g., proxy service 115) is the sole gateway for any egress traffic from execution platform 110, and the compute service manager 108 or its components are configured to enforce egress proxy policies. In other words, secure egress paths are configured to redirect traffic to the egress proxy (which acts as the egress gateway 541 to the Internet).

[0108] The above example requirement cannot be met by allowing sandboxed code direct access to the execution platform's network (e.g., the eth0 device), and implementing egress control directly on eth0 (e.g., the network interface device name representing the first Ethernet network interface) without impacting other execution platform workloads is challenging. Therefore, an overlay network solution is proposed to establish this secure egress path (wherein combining...) Figure 7 The coverage network is described and depicted in detail.

[0109] Figure 6 This is a block diagram illustrating an external function access system architecture 600 according to an example embodiment, the architecture including control flow for external access. Example embodiments of the control flow include, as in conjunction with... Figure 5 Similar elements and components depicted and described. To avoid obscuring the subject of the invention with unnecessary detail, [details omitted]. Figure 6 The part about combination is omitted. Figure 5 The various functional components described and depicted are redundant with respect to those components. However, those skilled in the art will readily recognize that various additional functional components may be included as part of the system architecture 600 to facilitate additional functions not specifically described herein.

[0110] Control flow begins at step 1 601, starting with execution platform worker 502, which registers policies at platform agent 109. Platform agent 109 writes policies and / or agent information to one or more Berkeley Packet Filter (BPF) maps and / or extended BPF (eBPF) maps, and creates (e.g., prepares) one or more network devices. eBPF is a technology that allows developers to create and run custom programs that can be embedded into the Linux kernel to intercept and analyze system events. BPF is used for packet filtering and network analysis, while eBPF is used for various system monitoring and tracing scenarios, such as those involving system calls, kernel events, and / or network traffic, and can modify and analyze data in real-time or near real-time.

[0111] Returning to execution platform worker 502, control flow continues at step 2 602, where execution platform worker 502 registers the policy at delegated agent 505 of agent service 115. Delegated agent 505 writes the policy into the BPF mapping.

[0112] Starting from execution platform worker 502, the control flow continues at step 3 603, where execution platform worker 502 starts the sandbox process 420 subprocess. The sandbox process 420 subprocess can configure a virtual Ethernet (veth) pair (e.g., UDF execution, event / logging agent, etc.) between execution platform 110 and sandbox process 420.

[0113] Starting with sandbox process 420, control flow continues at step 4604, where the sandbox process terminates. Control flow continues at step 5605, where execution platform worker 502 deregisters from delegated agent 505 and collects any events (e.g., violation events). At step 5605, delegated agent 505 may subsequently clean up policies in the event of execution platform worker 502 crashing or an incident. Finally, in the control flow at step 6606, platform agent 109 similarly deregisters and collects events at the platform agent level. At step 6606, platform agent 109 may clean up policies, for example, after execution platform worker 502 crashes or an incident occurs.

[0114] According to some example embodiments, an egress policy may contain a list of rules, where each rule defines allowed endpoints. Endpoints may include multiple allowed IP addresses and a list of allowed ports.

[0115]

[0116]

[0117] In some examples, policy setup and cleanup, such as execution platform setup for policies on veth entry points, can occur before starting the sandbox process 420. For example, execution platform 110 can extract exit policies from tokens such as JSON Web Token (JWT) strings and populate BPF mappings such as policy mappings and query information mappings. Policy mappings may include information such as sandbox identifiers, destination IP addresses, and destination ports. Query information mappings may include information such as sandbox IP addresses, query identifiers, and sandbox identifiers.

[0118] Policy mappings, query information mappings, BPF mappings, and similar methods can provide lookups to determine allowed ports. According to some examples, policy keys can be used in access control systems to determine whether a user or system is allowed access to a resource based on a policy associated with that resource. For example, a policy key can be a unique identifier used to associate a specific policy with a resource. In one example, a user can use ports in a policy key (e.g., expanding the port range to every port in the policy key) to provide fine-grained control over resource access based on a specific policy. In an additional example, cloud data platforms can add additional mappings to handle large port range lookups that are not easily provided by policy key lookups.

[0119] In the additional example, when a port range cannot be used as a key in the policy key, the port range in the policy value can be used. In this case, the cloud data platform can introduce another internal mapping to store all policy rules. For example, the cloud data platform can use a sandbox identifier and a destination IP address to find the internal mapping, and then find all rules within the mapping. The internal mapping can contain rules, which include port ranges, protocols, etc.

[0120] In an additional example, the source identity in the policy key can be used to specify a security policy for a particular network flow. The source identity is a component of the policy key that identifies the initiator of the network flow, such as an IP address, MAC address, or other identifier. The source identity can be used to match network flows with appropriate security policies. According to one example embodiment, a sandbox identifier (sandboxId) can be used as the identifier; using the sandboxId as the source identity, the cloud data platform can unify the policy mapping definition across execution platform 110 and proxy service 115. In an alternative example embodiment, the sandbox IP address can be used as the identifier.

[0121] In the additional example embodiment, policy validation is the process of verifying that a policy or a set of policies conforms to certain criteria or requirements, which can be predefined rules, industry standards, best practices, etc. The goal of policy validation is to ensure that policies are effective, consistent, and enforceable. Once a new packet arrives at the veth entry point on execution platform host 110, the code first uses the source IP address to look up the QueryInfoMap to find the sandboxId, then uses the sandfoxId to look up the PolicyMap to find the policy and validate the destination. If successful, the packet is forwarded to the Geneve Network Virtualization Encapsulation (GENEVE) tunnel, where the queryId and sandboxId are embedded in the GENEVE header. Otherwise, an error message indicating that the policy was rejected is reported to the eventMap. In another example, once a new packet arrives at the GENEVE entry point, the code extracts the sandboxId from the header and looks up the policy to validate the destination. If successful, the packet is forwarded to eth0. Otherwise, the packet is dropped and / or this sandbox escape error is reported to the eventMap.

[0122] In a further example embodiment, the UDF should be able to obtain the destination IP address from the host pre-configured by the sandbox process 420. However, if the UDF attempts to reach an unexpected destination, an unexpected DNS request may occur. Before terminating the sandbox process 420, the execution platform 110 or its components need to perform execution platform policy cleanup to remove policy entries from the PolicyMap and QueryInfoMap using the sandbox srcIp as the key. In addition to execution platform policy cleanup, the proxy service 115 can also perform policy setting and / or cleanup. Proxy service 115 policy cleanup can be performed before terminating the sandbox process 420. For example, the execution platform 110 may send a policy deregistration request to the delegated agent 505, and the delegated agent 505 may clear the policy in the policy map. In one example, a periodic background job can also be implemented to clear any outdated policies and / or reporting events. Additional examples may include a proxy policy refresh occurring on the execution platform 110, after which the execution platform 110 should re-register the refreshed policy with the proxy service 115.

[0123] For example, execution platform 110 registers a policy with an agent, where the policy registration request includes a signed JWT string and queryInfo(queryId, sandboxId). Delegating agent 505 will then need to verify the JWT using a token and the extracted policy. Afterward, delegating agent 505 will populate the PolicyMap in a manner similar to that described in the execution platform.

[0124] To enable external network access from the sandboxed processes within execution platform 110, custom packet redirection and policy enforcement logic is implemented in the eBPF program code. This eBPF code is compiled into a binary file and appended to the ingress / egress sides of different network interfaces, allowing each packet entering or leaving these network interfaces to be verified via the eBPF code. The cloud data platform or its components ensure that packets are routed through an egress proxy (e.g., proxy service 115) and that destination IP addresses are allowed according to customer-defined egress policies. This requires a group of several BPF mappings with information about allowed destinations.

[0125] For debugging and observability purposes, eBPF code also needs to emit logging events or metrics to BPF mappings. For example, user-space programs (e.g., agents) need to poll events from BPF mappings and send them logs and / or statistics. Additionally, agents need to perform some form of cleanup work on BPF mappings to maintain runtime state. Due to the way Linux functions work, user-space programs or agents can be new binaries. These binaries require the CAP_BPF functionality to manage BPF mappings. These functionality is typically granted by the Red Hat Package Manager (RPM) during installation. If a binary with the functionality is copied to a different location, the functionality may be lost. If the functionality is assigned to the execution platform worker 502 process during execution platform RPM installation, the functionality will only remain in that version of the execution platform binary. If functionality is lost due to copying, the TC_WRAPPER binary is created and installed via RPM.

[0126] Furthermore, eBPF is a powerful kernel feature that can do much more than just packet processing. For example, some other useful features of eBPF include system call tracing and secure implementations via the Linux Security Module (LSM) BPF, which can unify all these use cases and leverage a single agent process to handle all eBPF-related operations. The eBPF agent can also be used for malicious activity monitoring. Platform agent 109 can be an eBPF agent executing on platform 110, and the agent binary can be granted the required functionality. Platform agent 109 is also configured to set up network devices for external access, such that all networking settings are handled by a single executable.

[0127] In the additional example, delegated agent 505 can be an eBPF agent within agent service 115, ensuring the policy agent's responsibility for implementation. For example, delegated agent 505 can poll log entries and metrics from BPF mappings and send polling results to system log data or a local server. Delegated agent 505 can include policy cleanup actions, such as initiating and monitoring the cleanup of connection-tracking BPF mapping entries (e.g., in the event of a failure of execution platform worker 502), cleaning source network address translation (SNAT) BPF mapping entries, and cleaning network devices used by external access to the UDF. Delegated agent 505 can further initialize one or more GENEVE devices, including, for example, configuring GENEVE device IP forwarding and performing packet filtering to allow packets to be forwarded between network devices (e.g., veth, geneve0, eth0, etc.). Delegated agent 505 can utilize external access to initialize veth pair creation for the UDF and monitor or update BPF mapping values ​​and data to be used by the kernel BPF code.

[0128] In the additional example embodiment, a proxy error regarding connection timeout at execution platform 110 is described. Typically, the client side only sees connection timeout errors, providing very little information or guidance on how to proceed. However, if an error occurs due to a proxy error, the delegated agent 505 or execution platform 110 should be able to provide the client with better information to help them recover from such an error. For example, if proxy service 115 fails, delegated agent 505 could tell the client, "Internal service is temporarily unavailable, retry later..." etc. To achieve this, execution platform 110 needs to know if there are any errors in the queries to the proxy side, and what errors have occurred. For example, execution platform 110 could send a deregistration message to proxy service 115 after execution is complete and before the sandbox is destroyed to trigger policy map cleanup. The deregistration message could include the query identifier and sandbox identifier as part of the message fields, and delegated agent 505 could maintain an error cache that caches all error messages detected for queries based on messages polled from the event map. Once a logout request is received, the delegate agent 505 can try to find all relevant error events, metrics, and / or logs using the queryId and sandboxId, and display them in the response (if any).

[0129] In an additional example embodiment, once a push error message is detected, it is sent from the proxy service 115 back to the execution platform 110. However, the message exchange occurs after the UDF execution is complete, and in the event of a timeout, the client must wait until the timeout to know that the query failed, even if it is due to an internal service error within the cloud data platform. Once an error occurs, the example embodiment pushes the proxy error back to the execution platform 110, allowing the execution platform 110 to immediately fail the query with an appropriate error. In one example, once the corresponding event is retrieved, the proxy service 115 pushes the error event back at the application layer via a remote procedure call (e.g., gRPC).

[0130] In another example, proxy service 115 redirects packets back to execution platform 110 at the BPF layer and adds an error message to the GENEVE header. In this approach, the error message is added to the GENEVE header, and it directly reroutes the packet back to execution platform 110. For example, execution platform 110 could parse the GENEVE header at the BPF layer and publish it as an error event, which would then be detected at the application layer. When execution platform 110 is able to obtain a set of proxy errors, the errors are sent back to the client from execution platform 110, as described in the table below. Specifically, Table 1 is an example of the proposed message mapping, showing the errors sent to the client and the errors received by execution platform 110 from proxy service 115, based on the example above:

[0131]

[0132] Figure 7 This is a block diagram illustrating a system architecture 700 of an external access overlay network 701 according to some embodiments. (As shown above...) Figure 5 The secure exit path for external access to UDFs must meet stringent requirements, including strict exit isolation, strict exit control, and / or exit proxy implementation. This requirement cannot be met without impacting the workload of other execution platforms by allowing sandboxed code (e.g., UDF1711) to directly access the network of execution platform 110 (e.g., eth0 device 724). Therefore, Figure 7 A coverage network solution was proposed to establish this secure exit path. Figure 7The overlay network solution can be used to establish secure exit paths and can include an overlay network, which is a virtual network of nodes and logical links built on top of an existing physical or virtual network. Overlay network 701 creates a new layer in which traffic can be procedurally routed through new virtual network routes or paths (e.g., overlay 727) without requiring physical links (e.g., physical 725). It also enables cloud data platforms or their components to define and manage traffic flows regardless of the underlying physical infrastructure.

[0133] Figure 7 A secure exit path from a sandbox (e.g., sandbox process 420) to an exit agent (e.g., agent service 115) is demonstrated, with an overlay network used to implement exit control and isolation. For example, packets sent on the secure exit path traverse three logical hops, where the hops (e.g., tiers) are highlighted with dashed lines as tier 1 (T1) 710, tier 2 (T2) 720, and tier 3 (T3) 730.

[0134] At layer 1 (T1) 710, the first step in enabling external access from sandbox process 420 is to place the Ethernet device into its namespace. (As mentioned above...) Figure 6 The example embodiment described uses virtual Ethernet (veth) pairs to place Ethernet devices within their namespaces. Virtual Ethernet (veth) pairs allow communication between network namespaces. A veth pair is a pair of virtual network interfaces connected together in such a way that any traffic (e.g., data) sent through one interface of the veth pair is received by the other interface of the veth pair, providing a way for isolated environments to communicate with each other and / or with the host system. For example, each veth pair may consist of two virtual network interfaces, which may be referred to as a "parent interface" and a "child interface." The parent interface may be attached to the host system and / or another network interface, while the child interface may be attached to a virtual machine or container. For example, when traffic is sent through the child interface of a veth pair, the traffic is transmitted to the parent interface of the veth pair, and then the traffic is transmitted to the destination network.

[0135] For example, at layer 1 (T1) 710, at one end of the veth pair, veth0 712 is placed in the sandbox's namespace, while at the other end, veth1 713 is placed in the default namespace of execution platform 110. Any packets sent on veth0 712 are immediately received on veth1 713, and vice versa. For packets arriving on veth1 713, the system ensures that the egress policy allows their destination by attaching one or more Extended Berkeley Packet Filter (eBPF) hooks 714 to the veth1 713 device. The eBPF hooks may include an eBPF program that intercepts and / or modifies system calls and / or other kernel events by allowing developers to monitor and control system behavior in real-time or near real-time.

[0136] For example, eBPF can include an in-kernel virtual machine, allowing code execution in kernel space. It can be used to supplement or replace kernel packet handling, etc. The eBPF hook 714 on veth1 713 ensures that only packets with permitted destinations are forwarded to the next hop (e.g., generic0 device 721). Otherwise, the packet is dropped and a violation is reported. This also ensures that no packets can be sent to other sandboxes or execution platform 110 instances.

[0137] At layer 2 (T2) 720, after retrieving packets from sandbox process 420 and verifying that their destination is permitted, the system needs to send the packets to the egress agent, agent service 115. A GENEVE tunnel is used for T2 720. In virtualized environments (such as...) Figure 7 In a virtualized environment, GENEVE (Generic Network Virtual Encapsulation) can include a network tunneling protocol for transmitting network traffic between or within virtual machines over an IP network. GENEVE devices can include virtual network devices that implement the GENEVE protocol and are used to provide overlay networks across multiple physical hosts or clusters. For example, GENEVE encapsulates a 723 packet within a 722 packet in a UDP packet and uses a network virtualization header to allow multiple virtual networks to transmit over the same physical network infrastructure (e.g., physical 725). Figure 8 The GENEVE package is further described and depicted. When GENEVE devices are grouped... Figure 7 When used in the example embodiments, those skilled in the art will understand that embodiments and examples of the subject matter of this invention can be practiced with other network tunneling protocols. At T2 720, the system uses GENEVE to embed a policy identifier for each packet, so that the proxy service 115 can use this information to perform more fine-grained egress control.

[0138] At layer 3 (T3) 730, the egress proxy (proxy service 115) acts as a security barrier and the sole egress gateway (e.g., egress gateway 541) from execution platform 110. When a packet is received on the GENEVE device geneve0 731 in proxy service 115, the packet is decapsulated 728 to retrieve the original packet 732 and policy ID. The policy ID is used to look up the egress policy and verify that the original destination (e.g., the IP address of maps.google.com) is permitted. This verification generates a verified packet 733, which is essentially the same as what was performed at veth1 713 in execution platform 110. This second check is used to prevent compromised execution platform 110 (e.g., a "zero-trust execution platform") from leaking data. Any breach is reported to the security procedures. If the packet passes all checks, the system uses Source Network Address Translation (SNAT) to change the source address of the packet from the sandbox IP address to the egress proxy IP address. This is necessary because sandbox IP addresses are private and typically unroutable, while routable IP addresses are required to send response packets to Internet 781 using UDF external access. The system maintains connection mappings to correctly identify the target execution platform and sandbox instance for response packets. These three parts (Layers 1-3) work together to ensure that traffic from sandbox process 420 is well isolated and only reaches permitted destinations on Internet 781.

[0139] In an additional example embodiment, we explore static hostname resolution in the Compute Service Manager 108. The L3 / L4-based egress control discussed above is based on IP addresses. However, almost every internet connection begins with DNS, so protecting domain name resolution from UDFs is crucial, especially to prevent data leakage via DNS. In this additional example, hostname resolution is performed in the Compute Service Manager 108 at the start of the query, and the mapping is sent to the execution platform 110 in the egress policy document. eBPF-based networks can implement IP restrictions based on this static mapping. The mapping can also be used to populate a host file in a sandbox. For allowed destinations, the host can be used for name resolution. If an attempt is made to perform DNS resolution for an disallowed name, the eBPF code discards the DNS packet and reports a user error. This static approach can be used in most of the use cases explored herein because the job is typically short-lived. However, this approach may not be optimal for services that use DNS for failover or load balancing (e.g., round-robin scheduling), and a mitigation measure is to select an appropriate Time-to-Live (TTL) field in the IP header of the packet to indicate the maximum number of hops the packet can travel before being dropped by the gateway, in order to refresh the IP list.

[0140] Additional example embodiments of overlay network 701 may include allowing dynamic DNS resolution from UDFs at runtime, and supporting custom DNS resolvers. For example, an account administrator may specify allowed DNS resolvers in an allowed list (e.g., a list of allowed hosts), allowing DNS requests to pass through exit controls. In another example, the system may implement a dedicated DNS resolver at a secure location (e.g., proxy service 115) and proxy all hostname lookups from one or more UDFs. For example, the system may provide a local DNS proxy with networking and security features for containerized applications using eBPF technology to enable fast and secure communication between containers.

[0141] Although Figure 7 The examples described herein illustrate the use of an overlay network for external access; however, those skilled in the art will understand that the overlay network described herein can be further used internally by components of a cloud data platform. For example, in addition to external access, the system can also be used to allow instances of the same or related workloads to communicate with each other through example embodiments of the overlay network. For instance, one or more sandbox instances of the same job can be configured to communicate with each other through the overlay network described herein.

[0142] Figure 8 This illustrates an example embodiment as shown in Figure 7 The block diagram of the GENEVE package 800 used.

[0143] The GENEVE encapsulation protocol is an encapsulation protocol implemented in Linux for creating tunnels between two network devices. For example, in... Figure 7 As described herein, in a virtualization environment, GENEVE can include a network tunneling protocol for transmitting network traffic between or within virtual machines over an IP network. GENEVE is implemented in this document because it uses User Datagram Protocol (UDP) as the transport protocol and encapsulates raw data packets into payloads, thereby allowing cloud data platforms to set different destinations while providing flexibility in customizing their metadata.

[0144] like Figure 8 The packets encapsulated in GENEVE format described herein include a tunnel header encapsulated in UDP via IP. The GENEVE format includes an external Media Access Control (MAC) address 801 that provides the source or destination address in the outermost layer of the network packet header. In the GENEVE format, the external IP 802 refers to the outermost IP header of the encapsulated packet, including the source execution platform IP address and the destination proxy IP address. The external UDP header 803 refers to the outermost UDP header of the encapsulated packet, which may include information about the source and destination UDP ports, as well as other information.

[0145] The GENEVE header 804 includes several fields, including, for example, the GENEVE protocol version, variable length options, encapsulation protocol, Virtual Network Identifier (VNI), and other information. GENEVE option 805 provides additional information about the encapsulated data packet, such as a policy identifier (ID). GENEVE internal 806 refers to the original data packet that was encapsulated and transmitted over the virtual network. Figure 7 and Figure 8 In the example, the internal packet includes a source address (which may include the sandbox IP address) and a destination address (such as the IP address of maps.google.com). Encapsulating the internal packet within the GENEVE header allows the virtual network to maintain the same level of isolation, security, control, and performance as the physical network. Once the internal 806 has been decapsulated from the GENEVE header, it can be decrypted and processed by the receiving device, as described above. Figure 7 As stated above.

[0146] The internal Transmission Control Protocol (TCP) header 807 is the header of the raw TCP packet encapsulated and transmitted over the virtual network. The internal TCP payload 808 is the actual data transmitted within the TCP packet, which is encapsulated and transmitted over the virtual network. When a TCP packet is encapsulated in a GENEVE header, the entire packet (including the TCP header and payload) becomes the internal packet. The last element in the GENEVE encapsulation format is the Frame Check Sequence (FCS) 809, which refers to the cyclic redundancy check value added to the end of the packet to ensure packet integrity during transmission.

[0147] Figure 9 This is a block diagram of environment 900, which illustrates a high-level overview diagram, according to an example embodiment, depicting the flow of metrics and events from the BPF layer to the client, including appropriate processing. In some examples, environment 900 may include [missing information - likely related to a specific configuration or feature]. Figure 7 The same components as those in the system architecture 700 that are depicted and described. Figure 9 Similar to in many ways Figure 7 They share some similar features and components; for the sake of brevity, only refer to Figure 9 Specific elements are described in detail. To avoid obscuring the subject matter of the invention with unnecessary detail, Figure 9 Various functional components that are not closely related to conveying an understanding of the subject matter of this invention have been omitted. However, those skilled in the art will readily recognize that various additional functional components may be included as part of the environment 900 to facilitate additional functions not specifically described herein.

[0148] In execution platform 110, sandbox 920 with strategy A (which can be similar to a combination) Figure 4 and Figure 7 The sandbox process described and depicted (420) includes UDFs and veth0, such as in combination Figure 7 What is described and depicted.

[0149] In proxy service 115, proxy program 905 (e.g., combined with...) Figure 5 The delegated agent 905, as described and depicted, can be configured to poll event mappings (such as BPF event mapping 916) to retrieve events and metrics, perform appropriate processing, and log appropriate messages for debugging purposes and / or publish metrics as cloud data platform metrics. Polling 917 can be forwarded from BPF event mapping 916 to agent 905. Agent 905 sends an error list 998 to execution platform worker 502, which may include, for example, a logout response.

[0150] In response to receiving the error list 998, the execution platform worker 502 can provide one or more error messages 999 to the client devices of the cloud data platform user. Additionally, the execution platform worker 502 can send a destruction message 987 to the sandbox 920 with policy A to initiate the cleanup of any policy and destroy the corresponding sandbox. Once the UDF calculation is complete, the execution platform 110 will destroy the corresponding sandbox. Simultaneously, the execution platform worker 502 sends a deregistration message 989 to the agent 905, which may include, for example, a query identifier and a sandbox identifier (e.g., deregistering a policy using query_id and sandbox_id).

[0151] Once agent 905 receives deregistration message 989, agent 905 will look in the error cache to retrieve all error metrics associated with the query and return them to execution platform 110 in the response. Appropriate mapping cleanup will also be performed. Agent 905 publishes metric 936. Once execution platform 110 receives the response, it will perform analysis based on all the error results it has (e.g., including both execution platform errors and / or agent service errors) and determine what the appropriate error should be returned to the client in user error message 999.

[0152] Agent service 115 can generate and log useful metrics and events that can be used to improve the developer, customer, and / or user experience. BPF event mapping 916 can be used to pass events and / or metrics from the BPF layer to the application layer, and similarly applies to agent services. For example, BPF metrics can be written into a signal mapping and published along with cloud data platform metrics. Table 2 (below) shows several examples of debug and error metrics according to the example embodiments; however, additional metrics and / or events can be captured and logged according to this disclosure. Table 2 is an example of different categories of metrics according to some examples, including combinations of BPF metrics, startup metrics, runtime metrics, termination metrics, etc., as shown below:

[0153]

[0154] Table 2 includes example metric names and descriptions that can help cloud data platforms and / or users identify, monitor, and respond to performance management issues in production. For example, it provides metrics for understanding sandbox overhead, such as startup latency for different components within the sandbox or understanding runtime overhead.

[0155] The remaining events can be written to one or more event maps, such as BPF event map 916, where messages written to event maps can contain common fields. Metrics, events, and other logs can be added, modified, and / or deleted based on user preferences and / or the development of the cloud data platform. According to some examples, eBPF code writes metric and / or event messages triggered by bugs or debugging / monitoring purposes to BPF event maps. Once metrics and events are published (e.g., publishing metric 936), one of the most important things is how to associate each metric / event with the query that initiated the connection.

[0156] As an example, the query ID and sandbox ID are used to provide identifiers for associating metrics and / or events with queries. This option is utilized by using...<query_id><sandbox_id> The identifier is constructed, where it can be globally unique and directly associated with the query and policy used by sandbox 920 with policy A. However, the query ID and sandbox ID are identifiers known to execution platform 110, and information that can be extracted on the proxy side may include the source IP address (e.g., execution platform IP), source port, destination IP address, and destination port. Additional processes may be required to associate all this information.

[0157] Figure 10 This is a block diagram of environment 1000, which illustrates a high-level overview, according to an example embodiment, depicting the flow of metrics and events from the eBPF layer to the client. In some examples, environment 1000 may include [missing information - likely related to a specific implementation or feature]. Figure 7The system architecture described and / or combined with the system architecture 700 is depicted and described. Figure 9 The environment depicted and described has some or all of the same components as those in 900. Figure 10 Similar to in many ways Figure 7 and Figure 9 They share certain similar features and components; for the sake of brevity, only refer to Figure 10 Specific elements are described in detail. To avoid obscuring the subject matter of the invention with unnecessary detail, Figure 10 Various functional components that are not closely related to conveying an understanding of the subject matter of this invention have been omitted. However, those skilled in the art will readily recognize that various additional functional components may be included as part of the environment 1000 to facilitate additional functions not specifically described herein.

[0158] Figure 10 This describes how traffic will flow when data packets are sent from execution platform 110 to the Internet (similar flows will apply to returned data packets). Figure 10 As shown, both the execution platform 110 and the proxy service 115 can use, for example, BPF mappings to maintain ID mappings 1006 and 1016.

[0159] The ID mapping 1006 on the execution platform 110 side includes the sandbox IP 1007 as the key and the identifier as the value.<query_id><sandbox_id> Whenever a sandbox is created, destroyed, or updated, the execution platform 110 performs an update 1002 on the ID mapping 1006. eBPF code 1014 can initiate a lookup 1003 for an identifier with the sandbox IP 1007 when processing packets, and encode the identifier as part of the GENEVE header in the generate0 1021.

[0160] The ID mapping 1016 on the proxy service 115 side includes <(ep_ip,sport),(dst_ip,dport)> as the key (e.g., the execution platform IP address, source port, destination IP address, and destination port), and an identifier as the value (<query_id><sandbox_id> The eBPF code 1032 at geneve0 1031 can parse the header to retrieve the identifier and provide an update 1034 to the ID mapping 1016. If an entry is found, agent 905 can perform a post-processing lookup 1033 of the ID mapping 1016 to associate each metric / event with an identifier before logging or publishing. In some implementations, this is only a best-effort approach, as some metrics may not find an associated identifier, depending on whether the mapping has been updated when the metric / event is published. Example embodiments enable debugging metrics and / or events to be easily associated with the query in question based on query identifier information. The same identifier can be used for policy mapping at both agent service 115 and / or execution platform 110.

[0161] In the additional example embodiment, an environment 1000, illustrating a high-level overview of metrics and event flows, is shown using the IP address of the execution platform 110 and the IP address of the sandbox 1020b (with policy B).<ep_ip><sandbox_ip> This serves as an identifier for each metric / event. It can be directly obtained from the socket buffer on the proxy service side 115.<sk_buff> The data structure reads the execution platform 110 IP address but not the sandbox IP address. Therefore, the sandbox IP address still needs to be passed from the execution platform 110 ID mapping 1006 to the proxy service 115 via the GENEVE header. This metric only contains IP information, so manually mapping the IP address to the corresponding query is still required during debugging.

[0162] according to Figure 10 The implementation of this mechanism allows for traffic flow from execution platform 110 to proxy service 115, which may include the following example. Starting with execution platform 110, sandbox 1020b (with policy B 1008) includes a user-defined function (UDF) 1011, where the sandbox process configures a virtual Ethernet (veth) pair between sandbox 1020b (e.g., veth1 1012) and execution platform (e.g., veth2 1013). Once a new packet arrives at the veth2 1013 ingress point on the execution platform 110 host, eBPF code 1014 performs a lookup 1003 on the ID mapping 1006 to locate the source IP address.<sandbox_id> Then use<sandbox_id> Look up the policy map to find the associated policy (e.g., policy B 1008) and verify the destination.

[0163] If successful, the packet will be forwarded to the GENEVE tunnel (e.g., geneve0 device 1021), where<query_id> and<sandbox_id> Embedded in the GENEVE header. eBPF code 1023, appended to the egress side of geneve0 device 1021, performs NAT on the internal packet to change the source IP address stored in the GENEVE header to the eth0 1024 IP address. Next, the kernel encapsulates this packet with metadata from GENEVE tunnel-related data, including the remote IP address of proxy service 115. BPF redirection code 1035 is called to redirect the encapsulated packet to the egress side of geneve0 device 1031 on proxy service 115, and the encapsulated packet is transmitted to eth0 1026 on the proxy service side. eBPF code 1032, appended to the ingress side of geneve0 1031, performs a series of tasks (combined with...) Figure 12 (Detailed description) to decapsulate data packets and route them based on the destination IP address.

[0164] Figure 11 This is a block diagram 1100 illustrating eBPF-based packet routing for flow control processing relative to the local network stack processing, according to an example embodiment. The examples depicted in block diagram 1100 demonstrate how packets can be routed from an execution platform sandbox (e.g., a separate network namespace) to the public internet and packet return paths. Some examples may demonstrate network interfaces employed on execution platform 110 and / or an egress agent (e.g., agent service 115), and eBPF programs attached to each network interface, where eBPF is an in-kernel virtual machine that allows code execution in kernel space. Figure 11 Includes a key 1101 that depicts three symbols, including an IP table filter hook 1111, an eBPF TC hook 1120, and an eBPF XDP hook 1130, each of which is used on the inlet side 1105 and the outlet side 1125 of the block diagram 1100.

[0165] eBPF programs 1114 and 1124 can run sandboxed programs within the operating system kernel. This allows for the secure and efficient extension of kernel functionality without requiring changes to the kernel source code or loading of kernel modules. Particularly in the networking domain, eBPF programs provide programmability for the cloud-native world using software-defined networking. Furthermore, eBPF offers security and efficiency. It is far more secure than requiring eBPF programs to load kernel modules through a verification process; and efficiency is guaranteed by a Just-in-Time (JIT) compiler, which ensures the native execution speed of the eBPF bytecode. Finally, using eBPF provides the benefit of isolation. Compared to IP tables or IP routing, eBPF programs only need to be attached to newly introduced network devices (e.g., veth and GENEVE), and other existing network devices used in execution platform 110 will remain unaffected.

[0166] Combined with the following text Figure 11 The eBPF can be a program executable within the kernel for tracking, monitoring, and processing one or more packets. Various hook points can exist within the kernel, allowing the eBPF program to be attached to a veth device. Flow control (TC) can include tools for manipulating packets at a very low level. For example, it can attach an eBPF program to network devices on the ingress and / or egress sides. On the ingress side 1105, eBPF program 1114 can be executed before the packet is passed to the local network stack. Similarly, on the egress side 1125, eBPF program 1124 is executed after the local network stack has finished processing (e.g., local process 1108). GENEVE encapsulation protocols (such as those combining...) Figure 7 and Figure 8 The examples described and depicted are encapsulation protocols implemented in Linux for creating tunnels between two network devices. Although those skilled in the art will understand that other encapsulation protocols may be implemented according to different example embodiments.

[0167] Based on some examples, a high-level logical architecture is depicted in block diagram 1100. All Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) packets exiting the UDF sandbox can be routed through the egress proxy. Flow control (TC) can be attached to some or all eBPF procedures on the ingress side 1105 and / or egress side 1125 of the network interfaces created on the execution platform 110 and the proxy host. The eBPF procedures will primarily perform packet encapsulation and / or decapsulation for the tunnel between the execution platform 110 and the proxy service 115, packet redirection between network interfaces on the same host, SNAT (e.g., source IP network address translation) on one or more proxy hosts before packets are sent to the public Internet, policy enforcement based on policy identifiers (e.g., policy_ID) embedded in the encapsulated packet header, and so on.

[0168] According to some examples, such as the egress proxy of proxy service 115, it communicates with execution platform 110 but not with compute service manager 108. A UDF manager (e.g., UDFNetManager) running on each execution platform host is provided to assign IP addresses to sandbox process 420, making the IP addresses within the sandbox's network namespace unique within a single host. Further examples include IP addresses within the sandbox's network namespace being the same across different execution platform instances, where these instances can be accessed through the same or different egress proxies. Therefore, in order to uniquely identify the sandbox environment from the egress proxies, the cloud data platform requires a tuple of the execution platform IP address and the sandbox namespace IP address.

[0169] According to some examples, Network Address Translation (NAT) 1140 and / or Source IP NAT (SNAT) are critical components for forwarding packets to the public internet because each sandbox on the execution platform will be assigned a private IP address. To ensure that returned packets can get back to the sandbox, the agent needs to implement NAT / SNAT. According to this disclosure, there are three example methods for implementing this functionality.

[0170] In the first example embodiment, two-level NAT translation using eBPF code can be implemented by translating the private IP address in the sandbox to the execution platform IP address. Then, in the proxy host, the execution platform IP address is translated to the proxy IP address to access the public internet. In this approach, NAT and connection tracking can be implemented entirely within the eBPF program.

[0171] In the second example embodiment, two-level NAT translation using IP tables can be implemented by translating the private IP addresses in the sandbox to the execution platform IP addresses. Then, in the proxy host, the execution platform IP addresses are translated to proxy IP addresses to access the public internet. Both translations can utilize IP tables.

[0172] In the third example embodiment, the compute service manager 108 is configured to manage IP address mapping, where NAT only needs to be performed once using the IP table in the proxy host. In this third example embodiment, the compute service manager needs to implement an IP allocation service to assign a unique IP to each sandbox. During allocation, the compute service manager also needs to record the mapping between the execution platform IP and the unique IP. This example also includes: the egress proxy host needs to communicate with the compute service manager to inquire about the mapping between the sandbox IP and the execution platform IP. In the forwarding path, the egress proxy will use the IP table to translate the sandbox IP address to the egress proxy host IP. In the return path, the egress proxy will need to inquire with the compute service manager 108 about the execution platform 110 IP address to which the destination sandbox IP belongs, and then perform packet encapsulation.

[0173] Figure 11 The logical architecture provides five processing stages: a pre-routing stage 1102, an input stage 1103, a forwarding stage 1104, an output stage 1106, and a post-routing stage 1107. NAT / SNAT 1140 executes during the pre-routing stage 1102, the output stage 1106, and the post-routing stage 1107. The filtering process 1110 executes during the input stage 1103, the forwarding stage 1104, and the output stage 1106. The filtering process may include the use of IP table filtering hooks 1111. On the ingress side 1105, the eBPF program 1114 receives input from the eBPF XDP hook 1130 and provides output to the connected eBPF flow control hook 1120, which then routes the information to the pre-routing stage 1102. On the egress side 1125, the post-routing stage 1107 provides output to the eBPF flow control hook 1120 connected to the eBPF program 1124.

[0174] Figure 12 This is a block diagram illustrating a packet routing diagram 1200 according to an example embodiment, which depicts how packets are routed from execution platform 110 to proxy service 115. More specifically, Figure 12 This demonstrates how packets can be routed from a sandbox (e.g., 10.1.1.1) in execution platform 110 to a remote destination (e.g., 8.8.8.8).

[0175] Packet routing diagram 1200 begins with the virtual Ethernet (veth) pair being created. At step 1 1291, one end of the veth pair (e.g., veth0 1201) is moved to the network namespace within sandbox0 1220, while the other end (e.g., veth1 1202) remains on the host. The routing table within the sandbox0 1220 namespace will default to routing any packets using the veth1 1202 IP address 10.1.1.2 as the gateway. Therefore, packets will be sent from veth0 1201 and received by veth1 1202.

[0176] At step 2 1292, an eBPF program is attached to the ingress side (e.g., the receive side) of veth1 1202, and this eBPF program will perform certain tasks. For example, the eBPF program may perform one or more of the following tasks: (A) Check the policy regarding whether packets from sandbox0 1220 are allowed to access 8.8.8.8. If the packet is not allowed to access, the eBPF program will discard the packet and send an event to the userspace application. (B) Set up GENEVE tunnel-related data to prepare packet encapsulation, where the data includes, for example, the remote IP address of the proxy service and custom metadata (e.g., policy_ID and execution platform IP address). (C) Call bpf_redirect to redirect the packet to the egress side of generate0 device 1203.

[0177] Packet routing diagram 1200 continues at step 3 1293. The eBPF program is attached to the egress side of generate0 device 1203, which performs SNAT on the internal packet to change the source IP address to the eth0 1204 IP address of the current execution platform. Next, the kernel can encapsulate this packet with the metadata set by the task (B) mentioned above.

[0178] At step 4 1294, the encapsulated data packet is transmitted over the network. At step 5 1295, the actual packet decapsulation is performed by the kernel (e.g., no additional eBPF code is required). At step 6 1296, the eBPF program is attached to the ingress side (e.g., the receive side) of the generic11205, and this eBPF program performs the following tasks: (A) checks one or more policies based on the policy identifier regarding whether the packet should be allowed or blocked. If the packet should be blocked, the packet is discarded and this attempt is treated as a security event. (B) allows the packet through the local network stack without redirection.

[0179] Packet routing diagram 1200 continues at step 7 1297, where packets are routed based on the destination IP address (e.g., 8.8.8.8), which will pass through the default routing rules on the proxy host and will be transmitted under eth0 1206. At step 8 1298, the eBPF program will be attached to the egress side of eth0 1206, which will SNAT from the execution platform eth0 1206 IP address to the proxy service eth0 1206 IP address.

[0180] Figure 13 This is a block diagram illustrating a packet routing diagram 1300 according to an example embodiment, which depicts how return packets are routed from a remote source 1301 (e.g., 8.8.8.8) back to sandbox0 1320 (e.g., 10.1.1.1). In some examples, packet routing diagram 1300 may include combinations with... Figure 12 The packet routing diagram 1200 depicts and describes some or all of the same components. Figure 13 Similar to in many ways Figure 12 They share some similar features and components; for the sake of brevity, only refer to Figure 13 Specific elements are described in detail. To avoid obscuring the subject matter of the invention with unnecessary detail, Figure 13 Various functional components that are not closely related to conveying the understanding of the subject matter of the invention have been omitted. However, those skilled in the art will readily recognize that various additional functional components may be included as part of the packet routing diagram 1300 to facilitate additional functions not specifically described herein.

[0181] Packet routing diagram 1300 begins at step 1, 1391, where the remote upstream forwards the packet back to the egress proxy server, such as proxy service 115. At step 2, 1392, the eBPF procedure is attached to the ingress side of the eth0 1302 interface. The procedure performs the following actions: (A) Checks the destination port number on the packet and looks it up in the NAT table maintained by the cloud data platform. If no entry is found for the corresponding port number, the packet continues. (B) If an entry is found in the NAT table, the original execution platform IP address is looked up. (C) The packet's destination IP address is rewritten to match the execution platform IP address. (D) GENEVE encapsulation metadata is set (e.g., remote IP address, execution platform IP address, etc.). (E) The packet is redirected to the egress side of the GENEVE device.

[0182] Packet routing graph 1300 continues at step 3 1393, where the kernel encapsulates the packet according to the GENEVE metadata set at step 2 1392. At step 4 1394, the packet is transmitted over the wire, and at step 5 1395, the kernel decapsulates the packet. Packet routing graph 1300 continues at step 6 1396, where the packet arrives (e.g., connected to) the generic0 device 1306. The eBPF program is attached to the entry point of the generic0 device 1306, and the eBPF program performs the following operations: (A) fixes the MAC address of the packet. (B) performs a reverse SNAT from the execution platform IP address to the sandbox IP address. (C) the eBPF program then allows the packet to pass through the network stack 1307 in the execution platform host namespace, where the packet is sent to veth1 1308 according to the routing table. At step 7, the packet is sent back to veth0 1309.

[0183] In additional example embodiments, multiple eBPF programs are attached to different locations for tracing and monitoring purposes. For example, in one example implementation, at least four eBPF programs are implemented, including veth1 for outgoing packets implemented on the execution platform entry side, geneve0 for returning packets implemented on the execution platform entry side, geneve1 for outgoing packets implemented on the proxy entry side, and eth0 for returning packets implemented on the proxy entry side.

[0184] Figure 14 This is a block diagram illustrating an example service proxy process 1400 according to an example embodiment, which is used by a cloud data platform to route and manage network traffic between client applications and cloud data platform services. The example embodiment provides external access to a UDF (User-Defined Function) to enable users to transfer (e.g., send) arbitrary packets of data from the UDF sandbox to the public internet, including, for example, forwarding packets from the execution platform via an exit proxy host to allow fine-grained access control and traffic visibility.

[0185] Based on some examples, when a packet lands on a proxy host, three steps are typically performed: (1) packet decapsulation, (2) policy enforcement, and (3) packet forwarding to the upstream destination. Each of these three steps can be performed using one of three methods, including: (1) via the service proxy process (in conjunction with...) Figure 14 (detailed description), (2) in the kernel by the eBPF program (in combination with) Figure 15 (detailed description), and / or (3) a combination of eBPF program and service agent processes (in combination) Figure 16 (Detailed description)

[0186] According to an example embodiment using the first method, the proxy service process provides strong encryption and authentication mechanisms to protect traffic between the client and the cloud data platform service. According to the first method of the service proxy process, this example method instructs that all data packets encapsulated on the execution platform side will be sent directly to the port that the proxy service process is monitoring (e.g., listening to).

[0187] For example, proxy service process 1400 begins at step 1401, where a User Datagram Protocol (UDP) listener (such as a process or application) waits for incoming UDP packets on a specific port number (e.g., port 8888). Because UDP is a connectionless protocol, it allows data packets to be sent from one application to another without first establishing a connection. The application using proxy service process 1400 opens a UDP listener, binds it to the specific port number on the host, and waits for incoming UDP packets. When a UDP packet arrives at the specific port (e.g., port 8888), the listener captures the packet at step 1401 and processes it according to rules defined by the application. At step 1402, the proxy service process intercepts and analyzes the captured packets at a decapsulation filter designed to analyze traffic that has been encapsulated or tunneled using a specific protocol and strip the encapsulation so that the raw traffic can be analyzed and processed. For example, if the traffic is encapsulated using the GENEVE protocol, the decapsulation filter can intercept the incoming traffic and remove the GENEVE header and options, making the raw internal packets available for processing. This decapsulation filter allows security and monitoring tools to inspect traffic at the application layer, which is typically impossible if the traffic is still encapsulated.

[0188] At step 1403, an external authorization filter is available to the user to configure a network or HTTP(S) filter to invoke external services (e.g., via gRPC or HTTP) for authentication and / or authorization purposes. For example, the external authorization filter may include a policy enforcement action designed to evaluate requests for network resources based on external policies or rules (e.g., user privileges, group membership, time of day, location, etc.) to determine whether the request should be allowed or denied. The policy enforcement filter can be used to restrict access to sensitive databases based on user roles or privileges assigned to users by account administrators. If the filter determines that the request should be denied, a denial is sent to the policy agent at step 1404, and the request is rejected. If the filter determines that the user is authorized to access the resource, the agent service process continues to step 1405.

[0189] At step 1405, the bridge is used to connect the internal listener to the upstream network, where the bridge acts as a networking device to connect two or more segments together. For example, by using the bridge at step 1405, the proxy server process can route traffic from the external network to the internal listener without exposing the listener directly to the external network (e.g., thereby providing an additional layer of security).

[0190] Based on the internal packet protocol determined at step 1406, the proxy service process forwards the packet to a UDP listener at step 1407, or to a TCP listener at step 1410. At step 1407, the proxy service process forwards the packet to a UDP listener (e.g., a networking device acting as an intermediary between the client and server) on the proxy server's internal address. At step 1408, the process continues to a UDP proxy filter, a networking component operating within the UDP proxy server to inspect and / or modify UDP traffic as it passes through the server. The UDP proxy filter examines each UDP packet and determines how to handle it based on a set of predefined rules and / or policies (e.g., security and access control policies). At step 1409, the process continues to a dynamic forwarding upstream cluster (e.g., a server cluster), responsible for processing requests and / or providing responses to downstream clients or services.

[0191] Returning to step 1406, according to the internal packet protocol, at step 1410, the proxy service process forwards the packet to a Transmission Control Protocol (TCP) listener at the proxy server's internal address. The TCP listener may be a networking component configured to operate within the server to accept incoming TCP connections from downstream clients. The TCP listener may divide the data to be transmitted into one or more segments and transmit each segment over the network using IP to step 1411.

[0192] At step 1411, the TCP proxy filter receives segments and / or intercepts and analyzes the TCP traffic between the client and server hosts (e.g., modifying or filtering man-in-the-middle traffic before forwarding it to its destination). At step 1412, the process continues to the dynamic forwarding upstream cluster (e.g., a server cluster), which is responsible for processing requests and / or providing responses to downstream clients or services.

[0193] Figure 15 This is a block diagram illustrating an example of a second method 1500 according to an example embodiment, which is used by a cloud data platform to route and manage network traffic between client applications and cloud data platform services.

[0194] According to an example embodiment using the second method, a pure eBPF method is implemented to provide a way to indicate that all packet processing will occur within an eBPF program. At step 1501, the policy agent is configured to push a policy into the kernel at step 1502 via an eBPF or BPF mapping, which is a shared memory address between user space 1510 and kernel 1520. When a packet lands on the agent host, at step 1503, packet decapsulation, policy enforcement, and packet forwarding are all performed within an eBPF program attached to the Linux kernel's flow control (TC) subsystem. For example, a TC GENEVE device utilizes the flow control subsystem to perform its encapsulation and decapsulation functions over TCP.

[0195] Example embodiments of the second method 1500 achieve superior performance because data packets do not pass through user space 1510, and most of the eBPF program can be shared with the execution platform side, including pushing policies into the eBPF program.

[0196] Figure 16 This is a block diagram illustrating an example of a third method 1600 according to an example embodiment, which is used by a cloud data platform to route and manage network traffic between a client application and cloud data platform services.

[0197] According to an example embodiment using the third method 1600, by combining (e.g., as in...) Figure 14 The service agent process described in the document (and, for example, as in) Figure 15 The eBPF process described in [the document] implements the composition method. An example of this method begins at step 1601, which instructs that packets will be decapsulated within the eBPF process attached to the TC GENEVE device. At step 1602, the IP table pre-routing rule redirects packets to the local host and the port the service agent process will listen on. For example, the pre-routing rule redirects all TCP packets from the GENEVE device to local port 8888 and all UDP packets from the GENEVE device to local port 8889. The service agent process retrieves the SO_ORIGINAL_DST socket option set by the IP table. This socket option is a parameter used to modify the behavior of the endpoints of the bidirectional communication channel between the two networking applications. The service agent process then performs a composition similar to [the previous method]. Figure 14 The described method forwards packets to the correct upstream destination.

[0198] Figure 17A flowchart of a method 1700 for applying a packet strategy, according to some example embodiments, is depicted. Method 1700 may be embodied as machine-readable instructions executable by one or more hardware components (e.g., one or more processors), such that the operation of method 1700 can be performed by components of cloud data platform 102. Therefore, method 1700 is described below with reference to examples of components of cloud data platform 102. However, it should be understood that method 1700 can be deployed on various other hardware configurations and is not intended to be limited to deployment within cloud data platform 102.

[0199] According to embodiments, the operations of method 1700 may be repeated in different ways or involve intermediate operations not shown. While the operations of method 1700 may be depicted and described in a specific order, the order in which the operations are performed may vary between embodiments, including performing specific operations in parallel or performing a set of operations in separate processes. Although the various operations in this flowchart are presented and described sequentially, those skilled in the art will recognize that some or all of the operations may be performed in a different order, combined or omitted, or performed in parallel.

[0200] Operation 1702 is used to receive remote procedure calls from user-defined functions (UDFs) executing within a sandbox process via cloud data platform 102. Operation 1704 is used to provide an external access overlay network via cloud data platform 102 to establish a secure exit path for external access to the UDF. Operation 1706 is used to enable UDFs containing code running in the sandbox process to initiate network calls via cloud data platform 102.

[0201] Another general aspect is a system that includes memory containing instructions and one or more computer processors. When the instructions are executed by one or more computer processors, they cause one or more computer processors to perform operations. In yet another general aspect, a tangible machine-readable storage medium (e.g., a non-transitory storage medium) includes instructions that, when executed by a machine, cause the machine to perform operations.

[0202] Implementations of the subject matter may include one or more individual or combined features, as illustrated below by example.

[0203] Example 1 is a method comprising: receiving, via one or more hardware processors, a remote procedure call associated with a user-defined function (UDF) executed within a sandbox process, the UDF including code associated with at least one operation to be performed; providing an overlay network to establish a secure exit path for external access to the UDF; and enabling the UDF executed within the sandbox process to initiate network calls at least partially based on the overlay network.

[0204] In Example 2, the subject of Example 1 may optionally include establishing a secure exit path for external access to the UDF by: enabling external access from the sandbox process by identifying virtual Ethernet pairs used to place Ethernet devices in the namespace of the sandbox process; and performing packet authentication to verify packets.

[0205] In Example 3, the subject of any of Examples 1-2 may optionally include deploying an Extended Berkeley Packet Filter (eBPF) on an exit agent host to decapsulate packets, wherein decapsulating packets includes extracting a policy identifier; receiving an exit policy from the execution platform based at least in part on the policy identifier; and consulting the exit policy to ensure that the packet destination is authorized.

[0206] In Example 4, the subject of any of Examples 1-3 may optionally include capturing log data including error events related to the UDF; and revoking access permissions in response to the log data.

[0207] In Example 5, the subject of any of Examples 1-4 may optionally include providing direct external access to a UDF executed within a sandbox process via a secure exit path to a public Internet host in response to a network call.

[0208] In Example 6, the subject of any of Examples 1-5 may optionally include instantiating a sandbox process as a child process of a platform agent configured to determine whether a UDF is allowed to initiate a network call; and instantiating user code runtime as a child process of a sandbox process configured to perform at least one operation in the sandbox environment.

[0209] In Example 7, the subject of any of Examples 1-6 may optionally include instantiating a user code runtime to execute UDF code, the user code runtime being instantiated within the sandbox process of the execution node.

[0210] In Example 8, the subject of any of Examples 1-7 may optionally include collecting metric event information associated with the UDF, which includes execution statistics associated with the execution of UDF code by the user code runtime.

[0211] In Example 9, the subject of any of Examples 1-8 includes preventing code from making Domain Name System (DNS) requests to unauthorized hosts. This prevention includes specifying where sandboxed functions can connect based on DNS names or DNS patterns based on wildcards.

[0212] In Example 10, the subject of any of Examples 1-9 may optionally include code that instantiates a user code runtime to execute a UDF, the user code runtime including an access control list that includes an authorized host and access permissions.

[0213] Example 11 is a system comprising: one or more hardware processors of a machine; and at least one memory storing instructions that, when executed by the one or more hardware processors, cause the system to perform operations including: receiving, via the one or more hardware processors, a remote procedure call from a user-defined function (UDF) executed within a sandbox process, the UDF including code related to at least one operation to be performed; providing an overlay network to establish a secure exit path for external access to the UDF; and enabling the UDF executed within the sandbox process to initiate network calls at least partially based on the overlay network.

[0214] In Example 12, the subject of Example 11 may optionally include establishing a secure exit path for external access to the UDF by: enabling external access from the sandbox process by identifying virtual Ethernet pairs used to place Ethernet devices in the namespace of the sandbox process; and performing packet authentication to verify packets.

[0215] In Example 13, the subject of any of Examples 11-12 may optionally include the operation further comprising: deploying an Extended Berkeley Packet Filter (eBPF) on the egress proxy host to decapsulate packets, wherein decapsulating packets includes extracting a policy identifier; receiving an egress policy from the execution platform based at least in part on the policy identifier; and consulting the egress policy to ensure that the packet destination is authorized.

[0216] In Example 14, the subject of any of Examples 11-13 may optionally include the operation further comprising: capturing log data including error events related to the UDF; and revoking access rights in response to the log data.

[0217] In Example 15, the subject of any of Examples 11-14 may optionally include the operation further comprising: in response to a network call, providing direct external access to the UDF executed within the sandbox process via a secure exit path to a public Internet host.

[0218] In Example 16, the subject of any one of Examples 11-15 may optionally include the operation further comprising: instantiating a sandbox process as a child process of a platform agent configured to determine whether a UDF is allowed to initiate a network call; and instantiating user code runtime as a child process of a sandbox process configured to perform at least one operation in the sandbox environment.

[0219] In Example 17, the subject of any of Examples 11-16 may optionally include the operation further comprising: instantiating a user code runtime to execute UDF code, the user code runtime being instantiated within the sandbox process of the execution node.

[0220] In Example 18, the subject of any of Examples 11-17 may optionally include the operation further comprising: collecting metric event information associated with the UDF, the metric event information including execution statistics associated with the execution of UDF code by the user code runtime.

[0221] In Example 19, the subject of any of Examples 11-18 may optionally include the operation further including: preventing code from making Domain Name System (DNS) requests to unauthorized hosts, the prevention including specifying where the sandboxed function can connect based on DNS name or DNS mode based on wildcards.

[0222] In Example 20, the subject of any of Examples 11-19 may optionally include the operation further comprising: instantiating a user code runtime to execute code of a UDF, the user code runtime including an access control list that includes an authorized host and access permissions.

[0223] Example 21 is a machine storage medium embodying instructions that, when executed by a machine, cause the machine to perform operations including: receiving remote procedure calls via one or more hardware processors from a user-defined function (UDF) executing within a sandbox process, the UDF including code related to at least one operation to be performed; providing an overlay network to establish a secure exit path for external access to the UDF; and enabling the UDF executing within the sandbox process to initiate network calls at least partially based on the overlay network.

[0224] In Example 22, the subject of Example 21 may optionally include establishing a secure exit path for external access to the UDF by: enabling external access from the sandbox process by identifying virtual Ethernet pairs used to place Ethernet devices in the namespace of the sandbox process; and performing packet authentication to verify packets.

[0225] In Example 23, the subject of any of Examples 21-22 may optionally include the operation further comprising: deploying an Extended Berkeley Packet Filter (eBPF) on the egress proxy host to decapsulate packets, wherein decapsulating packets includes extracting a policy identifier; receiving an egress policy from the execution platform based at least in part on the policy identifier; and consulting the egress policy to ensure that the packet destination is authorized.

[0226] In Example 24, the subject of any of Examples 21-23 may optionally include the operation further comprising: capturing log data including error events related to the UDF; and revoking access rights in response to the log data.

[0227] In Example 25, the subject of any of Examples 21-24 may optionally include the operation further comprising: in response to a network call, providing direct external access to the UDF executed within the sandbox process via a secure exit path to a public Internet host.

[0228] In Example 26, the subject of any one of Examples 21-25 may optionally include the operation further comprising: instantiating a sandbox process as a child process of a platform agent configured to determine whether a UDF is allowed to initiate a network call; and instantiating user code runtime as a child process of a sandbox process configured to perform at least one operation in the sandbox environment.

[0229] In Example 27, the subject of any of Examples 21-26 may optionally include the operation further comprising: instantiating a user code runtime to execute UDF code, the user code runtime being instantiated within the sandbox process of the execution node.

[0230] In Example 28, the subject of any of Examples 21-27 may optionally include the operation further comprising: collecting metric event information associated with the UDF, the metric event information including execution statistics associated with the execution of UDF code by the user code runtime.

[0231] In Example 29, the subject of any of Examples 21-28 may optionally include the operation further including: preventing code from making Domain Name System (DNS) requests to unauthorized hosts, the prevention including specifying where the sandboxed function can connect based on DNS name or DNS mode based on wildcards.

[0232] In Example 30, the subject of any of Examples 21-29 may optionally include the operation further comprising: instantiating a user code runtime to execute code of a UDF, the user code runtime including an access control list that includes an authorized host and access permissions.

[0233] Example 31 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any one of Examples 1 to 30. Example 32 is an apparatus including means for implementing any one of Examples 1 to 30.

[0234] Figure 18A schematic representation of a machine 1800 in the form of a computer system according to an example embodiment is shown, within which a set of instructions can be executed to cause the machine 1800 to perform any or more of the methods discussed herein. Specifically, Figure 18 A schematic representation of machine 1800 is shown as an example of a computer system, within which instructions 1816 (e.g., software, programs, applications, applets, or other executable code) for causing machine 1800 to perform any or more of the methods discussed herein can be executed. For example, instructions 1816 may cause machine 1800 to perform any or more operations of any or more of the methods described herein. As another example, instructions 1816 may cause machine 1800 to implement portions of the data flow described herein. In this way, instructions 1816 transform a general, unprogrammed machine into a specific machine 1800 (e.g., computing service manager 108, execution platform 110, client device 114) specifically configured to perform any of the described and illustrated functions in the manner described herein.

[0235] In alternative embodiments, machine 1800 operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, machine 1800 may operate as a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. Machine 1800 may include, but is not limited to, server computers, client computers, personal computers (PCs), tablet computers, laptop computers, netbooks, smartphones, mobile devices, network routers, network switches, network bridges, or any machine capable of sequentially or otherwise executing instructions 1816, which specify actions to be taken by machine 1800. Furthermore, although only a single machine 1800 is shown, the term "machine" should also be understood to include a collection of machines 1800 that individually or jointly execute instructions 1816 to perform any or more of the methods discussed herein.

[0236] Machine 1800 includes processor 1810, memory 1830, and input / output (I / O) components 1850, which are configured to communicate with each other, for example, via bus 1802. In example embodiments, processor 1810 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processors 1812 and 1814 capable of executing instructions 1816. The term "processor" is intended to include multi-core processor 1810, which may include two or more independent processors (sometimes referred to as "cores") capable of executing instructions 1816 simultaneously. Although Figure 18 Multiple processors 1810 are shown, but machine 1800 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

[0237] Memory 1830 may include main memory 1832, static memory 1834, and memory cell 1836, all of which may be accessed by processor 1810, for example, via bus 1802. Main memory 1832, static memory 1834, and memory cell 1836, including machine storage medium 1838, may store instructions 1816 embodying any or more of the methods or functions described herein. During execution by machine 1800, instructions 1816 may also reside wholly or partially in main memory 1832, static memory 1834, memory cell 1836, at least one processor 1810 (e.g., in the processor's cache memory), or any suitable combination thereof.

[0238] I / O component 1850 includes components for receiving input, providing output, generating output, transmitting information, exchanging information, capturing measurement values, etc. The specific I / O component 1850 included in a particular machine 1800 will depend on the type of machine. For example, a portable machine such as a mobile phone may include a touch input device or other such input mechanism, while a headless server machine is unlikely to include such a touch input device. It will be appreciated that I / O component 1850 may include... Figure 18Many other components are not shown. The grouping of I / O components 1850 according to function is merely for the purpose of simplifying the discussion below, and such grouping is by no means limiting. In various example embodiments, I / O components 1850 may include output components 1852 and input components 1854. Output components 1852 may include visual components (e.g., displays such as plasma display panels (PDPs), light-emitting diode (LED) displays, liquid crystal displays (LCDs), projectors, or cathode ray tube (CRT) displays), acoustic components (e.g., speakers), other signal generators, etc. Input components 1854 may include alphanumeric input components (e.g., keyboards, touchscreens configured to receive alphanumeric input, photoelectric keyboards, or other alphanumeric input components), pointing-based input components (e.g., mice, touchpads, trackballs, joysticks, motion sensors, or other pointing instruments), haptic input components (e.g., physical buttons, touchscreens or other haptic input components that provide position and / or force for touch or touch gestures), audio input components (e.g., microphones), etc.

[0239] Various technologies can be used to implement communication. I / O component 1850 may include communication component 1864, operable to couple machine 1800 to network 1881 via coupling 1883, or to device 1880 via coupling 1882. For example, communication component 1864 may include a network interface component or another suitable device interfaced with network 1881. In further examples, communication component 1864 may include wired communication components, wireless communication components, cellular communication components, and other communication components providing communication via other modes. Device 1880 may be another machine or any of a variety of peripheral devices (e.g., peripheral devices coupled via Universal Serial Bus (USB)). For example, as described above, machine 1800 may correspond to any of client device 114, computing service manager 108, and execution platform 110, and device 1880 may include any other system or device among these systems and devices.

[0240] Various memories (e.g., 1830, 1832, 1834 and / or the memory and / or storage unit 1836 of processor 1810) may store one or more sets of instructions 1816 and data structures (e.g., software) that embody or are utilized by any or more of the methods or functions described herein. When executed by processor 1810, these instructions 1816 cause various operations to implement the disclosed embodiments.

[0241] As used herein, the terms “machine storage medium,” “device storage medium,” and “computer storage medium” have the same meaning and may be used interchangeably in this disclosure. These terms refer to one or more storage devices and / or media (e.g., centralized or distributed databases and / or associated caches and servers) that store executable instructions and / or data. Accordingly, these terms should be considered to include, but are not limited to, solid-state memory, as well as optical and magnetic media, including memory internal or external to a processor. Specific examples of machine storage media, computer storage media, and / or device storage media include non-volatile memory, including, for example: semiconductor memory devices such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), field-programmable gate arrays (FPGAs), and flash memory devices; disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROMs and DVD-ROMs. The terms “machine storage medium,” “computer storage medium,” and “device storage medium” specifically exclude carrier waves, modulated data signals, and other such media (at least some of which are included in the term “signal medium” discussed below).

[0242] In various example embodiments, one or more portions of network 1881 may be an ad hoc network, intranet, extranet, virtual private network (VPN), local area network (LAN), wireless LAN (WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), the Internet, a portion of the Internet, a portion of the public switched telephone network (PSTN), a common old-style telephone service (POTS) network, a cellular telephone network, a wireless network, etc. A network, another type of network, or a combination of two or more such networks. For example, network 1881 or a portion thereof may include a wireless or cellular network, and coupling 1883 may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile Communications (GSM) connection, or another type of cellular or wireless coupling. In this example, coupling 1883 may implement any of a variety of data transmission technologies, such as Single Carrier Radio Transmission (1xRTT), Evolution-Data Optimized (EVDO), General Packet Radio Service (GPRS), Enhanced Data Rate Evolution of GSM (EDGE), including 3G, fourth-generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High-Speed ​​Packet Access (HSPA), Global Microwave Access Interoperability (WiMAX), the 3rd Generation Partnership Project (3GPP) for Long Term Evolution (LTE) standards, other technologies defined by various standards-setting organizations, other long-range protocols, or other data transmission technologies.

[0243] Instruction 1816 can be transmitted or received on network 1881 using a transmission medium via a network interface device (e.g., a network interface component included in communication component 1864) and utilizing any of a variety of well-known transmission protocols (e.g., Hypertext Transfer Protocol (HTTP)). Similarly, instruction 1816 can be transmitted to or received by device 1880 via coupling 1882 (e.g., peer-to-peer coupling) using a transmission medium. The terms “transmission medium” and “signal medium” have the same meaning and are used interchangeably in this disclosure. The terms “transmission medium” and “signal medium” should be understood to include any intangible medium capable of storing, encoding, or carrying instructions 1816 for execution by machine 1800, and include digital or analog communication signals or other intangible media facilitating communication of such software. Therefore, the terms “transmission medium” and “signal medium” should be understood to include any form of modulated data signal, carrier wave, etc. The term “modulated data signal” means a signal that has one or more characteristics set or modified in such a way as to encode information in the signal.

[0244] As described herein, examples may include logic, multiple components, or mechanisms, or may be operated by logic, multiple components, or mechanisms. A circuit system is a collection of circuits implemented in a tangible entity, which includes hardware (e.g., simple circuits, gates, logic). Circuit system members can be flexible with time and the variability of the underlying hardware. A circuit system includes members that can perform a specified operation individually or in combination during operation. In the examples, the hardware of the circuit system may be invariably designed to perform a specific operation (e.g., hardwired). In the examples, the hardware of the circuit system may include physically connected components (e.g., execution units, transistors, simple circuits) that include physically modified computer-readable media (e.g., through the movable placement of invariant aggregated particles, magnetically, electrically) encoding instructions for a specific operation. When the physical components are connected, the basic electrical characteristics of the hardware components are changed (e.g., from insulator to conductor, or from conductor to insulator). These instructions enable embedded hardware (e.g., execution units or loading mechanisms) to create members of the circuit system in the hardware via variable connections so that portions of a specific operation are performed during operation. Thus, when the device operates, the computer-readable media is communicatively coupled to other components of the circuit. In the example, any physical component can be used in more than one member of more than one circuit system. For example, under operation, an execution unit can be used in a first circuit of a first circuit system at one point in time, and reused by a second circuit of the first circuit system or by a third circuit of the second circuit system at different times.

[0245] The terms “machine-readable medium,” “computer-readable medium,” and “device-readable medium” have the same meaning and are used interchangeably in this disclosure. These terms are defined to include both machine storage media and transmission media. Therefore, these terms include both storage devices / media and carrier / modulated data signals.

[0246] Various operations of the example methods described herein can be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Similarly, the methods described herein can be implemented, at least in part, by processors. For example, at least some operations of the methods described herein can be performed by one or more processors. The execution of certain operations can be distributed among one or more processors, which not only reside within a single machine but are deployed across multiple machines. In some example embodiments, one or more processors may reside in a single location (e.g., in a home environment, office environment, or server farm), while in other embodiments, the processors may be distributed across multiple locations.

[0247] Although embodiments of the present disclosure have been described with reference to specific example examples, it will be apparent that various modifications and changes can be made to these embodiments without departing from the broader scope of the subject matter of the invention. Therefore, the specification and drawings are to be considered illustrative rather than restrictive. The accompanying drawings, which form a part of this application, illustrate specific embodiments in which the subject matter can be practiced by way of illustration rather than limitation. The illustrated embodiments are described in sufficient detail to enable those skilled in the art to implement the teachings disclosed herein. Other embodiments and embodiments derived therefrom may be used, such that structural and logical substitutions and changes can be made without departing from the scope of the present disclosure. Therefore, this detailed description should not be construed as limiting, and the scope of the various embodiments is defined only by the appended claims together with their equivalents, which enjoy the full scope of the claims.

[0248] Such embodiments of the subject matter of this invention may be referred to herein, individually and / or collectively, by the term "invention," merely for convenience and not intended to voluntarily limit the scope of this application to any single invention or inventive concept (if more than one invention or inventive concept is actually disclosed). Therefore, while specific embodiments have been illustrated and described herein, it should be understood that the specific embodiments shown may be replaced by any arrangement calculated to achieve the same purpose. This disclosure is intended to cover any and all modifications or variations of the various embodiments. After reading the above description, combinations of the above embodiments and other embodiments not specifically described herein will be apparent to those skilled in the art.

[0249] In this document, the terms “a” or “an”, as is common in patent documents, are used to include one or more, and are not related to any other instance or use of “at least one” or “one or more”. In this document, the term “or” is used to mean a non-exclusive “or”, so unless otherwise stated, “A or B” includes “A but not B”, “B but not A”, and “A and B”. In the appended claims, the terms “including” and “in which” are used as their plain English equivalents to the corresponding terms “comprising” and “wherein”. Furthermore, in the appended claims, the terms “including” and “comprising” are open-ended; that is, a system, apparatus, article, or process that includes elements other than those listed after such terms in the claims is still considered to fall within the scope of the claims.

Claims

1. A method for providing secure access for sandboxed user-defined functions, comprising: receiving, by one or more hardware processors, a remote procedure call related to a user-defined function (UDF) executing within a sandbox process, the UDF comprising code related to at least one operation to be performed; providing an overlay network to establish a secure egress path for UDF external access; implementing the overlay network using a tunneling protocol; and enabling the UDF executing in the sandbox process to initiate a network call based at least in part on the overlay network. establishing the secure egress path for UDF external access comprises:

2. The method of claim 1, wherein, enabling external access from the sandbox process by identifying a virtual Ethernet pair for placing an Ethernet device in a namespace of the sandbox process; and performing packet validation to validate a data packet.

3. The method of claim 2, further comprising: deploying an extended Berkeley Packet Filter (eBPF) on an egress proxy host to decapsulate the data packet, wherein decapsulating the data packet comprises extracting a policy identifier; receiving an egress policy from an execution platform based at least in part on the policy identifier; and consulting the egress policy to ensure data packet destination authorization.

4. The method of claim 1, further comprising: capturing log data comprising an error event related to the UDF; and implementing revocation of access usage rights in response to the log data.

5. The method of claim 1, further comprising: providing direct external access to the UDF executing within the sandbox process via the secure egress path to a public internet host in response to the network call.

6. The method of claim 1, further comprising: instantiating the sandbox process as a child process of a platform agent configured to determine whether to allow the UDF to initiate the network call; and instantiating a user code runtime as a child process of the sandbox process configured to perform the at least one operation in a sandboxed environment.

7. The method of claim 1, further comprising: instantiating a user code runtime to execute the UDF code, the user code runtime instantiated within the sandbox process of an execution node.

8. The method of claim 7, further comprising: collecting metric event information associated with the UDF, the metric event information comprising execution statistics associated with execution of the UDF code by the user code runtime.

9. The method of claim 1, further comprising: preventing the code from making a domain name system (DNS) request to an unauthorized host, the preventing comprising specifying where a sandboxed function can connect to based on a DNS name or based on a wildcarded DNS pattern.

10. The method of claim 1, further comprising: instantiating a user code runtime to execute code of the UDF, the user code runtime comprising an access control list, the access control list comprising authorized hosts and access usage rights. ​ ​ ​ 11. A system for providing secure access for sandboxed user-defined functions, comprising: one or more hardware processors of a machine; and at least one memory storing instructions that, when executed by the one or more hardware processors, cause the system to perform operations comprising: receiving, by the one or more hardware processors, a remote procedure call from a user-defined function (UDF) executing within a sandbox process, the UDF comprising code related to at least one operation to be performed; providing an overlay network to establish a secure egress path for external access of the UDF; implementing the overlay network using a tunneling protocol; and enabling the UDF executing in the sandbox process to initiate a network call based at least in part on the overlay network.

12. The system of claim 11, wherein, establishing the secure egress path for external access of the UDF comprises: enabling external access from the sandbox process by identifying a virtual Ethernet pair for placing an Ethernet device in a namespace of the sandbox process; and performing packet validation to validate a data packet.

13. The system of claim 12, the operations further comprising: deploying an extended Berkeley Packet Filter (eBPF) on an egress proxy host to decapsulate the data packet, wherein decapsulating the data packet comprises extracting a policy identifier; receiving an egress policy from an execution platform based at least in part on the policy identifier; and consulting the egress policy to ensure data packet destination authorization.

14. The system of claim 11, the operations further comprising: capturing log data comprising an error event related to the UDF; and implementing revocation of access usage rights in response to the log data.

15. The system of claim 11, the operations further comprising: providing direct external access to the UDF executing within the sandbox process via the secure egress path to a public internet host in response to the network call.

16. The system of claim 11, the operations further comprising: instantiating the sandbox process as a child process of a platform agent configured to determine whether to allow the UDF to initiate the network call; and instantiating a user code runtime as a child process of the sandbox process configured to perform the at least one operation in a sandboxed environment.

17. The system of claim 11, the operations further comprising: instantiating a user code runtime to execute the UDF code, the user code runtime instantiated within the sandbox process of an execution node.

18. The system of claim 17, the operations further comprising: collecting metric event information associated with the UDF, the metric event information comprising execution statistics associated with execution of the UDF code by the user code runtime.

19. The system of claim 11, the operations further comprising: preventing the code from making a domain name system (DNS) request to an unauthorized host, the preventing comprising specifying, based on a DNS name or a wildcard-based DNS pattern, where a sandboxing function is able to connect.

20. The system of claim 11, the operations further comprising: instantiating a user code runtime to execute code of the UDF, the user code runtime comprising an access control list comprising authorized hosts and access usage rights.

21. A machine-storage medium embodying instructions that, when executed by a machine, cause the machine to perform operations, the operations comprising: receiving, by one or more hardware processors, a remote procedure call from a user-defined function (UDF) executing within a sandbox process, the UDF comprising code related to at least one operation to be performed; providing an overlay network to establish a secure egress path for UDF external access; implementing the overlay network using a tunneling protocol; and enabling the UDF executing in the sandbox process to initiate a network call based at least in part on the overlay network.

22. The machine-storage medium of claim 21, wherein, establishing the secure egress path for UDF external access comprises: enabling external access from the sandbox process by identifying a virtual Ethernet pair for placing an Ethernet device in a namespace of the sandbox process; and performing packet validation to validate a packet.

23. The machine-storage medium of claim 22, the operations further comprising: deploying an extended Berkeley Packet Filter (eBPF) on an egress proxy host to decapsulate the packet, wherein decapsulating the packet comprises extracting a policy identifier; receiving an egress policy from an execution platform based at least in part on the policy identifier; and consulting the egress policy to ensure a packet destination is authorized.

24. The machine-storage medium of claim 21, the operations further comprising: capturing log data comprising an error event related to the UDF; and implementing revocation of access usage rights in response to the log data.

25. The machine-storage medium of claim 21, the operations further comprising: providing direct external access to the UDF executing within the sandbox process via the secure egress path to a public internet host in response to the network call.

26. The machine-storage medium of claim 21, the operations further comprising: instantiating the sandbox process as a child process of a platform agent configured to determine whether to allow the UDF to initiate the network call; and instantiating a user code runtime as a child process of the sandbox process configured to perform the at least one operation in a sandboxed environment.

27. The machine-storage medium of claim 21, the operations further comprising: instantiating a user code runtime to execute the UDF code, the user code runtime instantiated within the sandbox process of an execution node.

28. The machine-storage medium of claim 27, the operations further comprising: collecting metric event information associated with the UDF, the metric event information including execution statistics associated with execution of the UDF code by the user code runtime.

29. The machine-storage medium of claim 21, the operations further comprising: preventing the code from making domain name system (DNS) requests to unauthorized hosts, the preventing including specifying, based on DNS name or wildcard-based DNS patterns, where a sandboxing function is able to connect to.

30. The machine-storage medium of claim 21, the operations further comprising: instantiating a user code runtime to execute code of the UDF, the user code runtime including an access control list, the access control list including authorized hosts and access usage rights.

Images