CN117235339A - Data platform with unified privileges - Google Patents

Abstract

The application relates to a data platform with unified privileges. A data platform for developing and deploying user applications within a unified security context. The data platform authorizes the first user to use the editor to access source code of the user application based on a security policy of the security context and authorizes the first user to use the application and the data manager to set a use privilege for the second user to use the user application based on the security policy of the security context. To provide the user application to the second user, the data platform deploys the user application by: instantiating a User Defined Function (UDF) server and an application engine of the UDF server within a security context, instantiating a user application as an application of the application engine within the security context, and authorizing access to data by the user application based on a security policy of the security context.

Description

Data platform with unified privileges

Technical Field

Examples of the present disclosure relate generally to databases and, more particularly, to database security.

Background

Data platforms are widely used for data storage and data access in computing and communication environments. With respect to architecture, the data platform may be a localized deployed data platform (on-premises data platform), a network-based data platform (e.g., a cloud-based data platform), a combination of both, and/or include another type of architecture. Regarding the type of data processing, the data platform may implement online transaction processing (OLTP), online analytical processing (OLAP), a combination of both, and/or another type of data processing. Further, the data platform may be or include a relational database management system (RDBMS) and/or one or more other types of database management systems.

Providers of data on a data platform may wish to have a way to conveniently protect their data.

Brief Description of Drawings

The present disclosure will be understood more fully from the detailed description given below and from the accompanying drawings of various examples of the disclosure.

FIG. 1 illustrates an example computing environment including a network-based data platform in communication with a cloud storage provider system, according to some examples of this disclosure.

Fig. 2 is a block diagram illustrating components of a computing service manager according to some examples of the present disclosure.

Fig. 3 is a block diagram illustrating components of an execution platform according to some examples of the present disclosure.

FIG. 4A is a deployment diagram of a computing environment for providing an application, according to some examples of the present disclosure.

Fig. 4B, 4C, and 4D are interaction and data flow diagrams of computing environments for providing user applications according to some examples of the present disclosure.

FIG. 5 is a deployment diagram of a computing environment of a data platform that provides a unified security context for development and deployment of user applications, according to some examples of the present disclosure.

Fig. 6 is an activity diagram illustrating a method of developing and deploying user applications in a unified security context by data platform 102, according to some examples of the present disclosure.

Fig. 7 illustrates a diagrammatic representation of machine in the form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed in accordance with some examples of the present disclosure.

Detailed Description

There are many existing solutions for building applications that access data on a data platform, but most solutions involve different permission boundaries for writing application code, deploying code, running applications, updating applications, and using applications. These gaps (gaps) across the security boundary are where errors are likely, or where authorization material needs to be stored in order to interact with the system. For example, a user may need to store authorization material in a continuous integration job (job) in order to push a built artifact (artifact) to the artifact management system. Even in simple systems, where the creation and use of applications often occur in the same organization, it is necessary to store the credentials of the data platform. By providing a combination of the following, a user is able to create, deploy, and execute an application without storing credentials or other authorization material at an off-platform location (off-platform location): an editor for editing and creating applications within the data platform; a method for providing an object as a native database object, the native database object running as a User Interface (UI) application; methods for packaging and sharing applications; and methods for sharing data across accounts of a data platform, all operating within the same security context.

In some examples, development, operation, and end users are shared in the same security context with a unified privilege (privilees) defining the security boundaries of the security context. The various components of the system may work directly on the data platform. This provides an authorization boundary across various aspects of the user application lifecycle. Operations such as distributing user applications may operate within the native application framework of the data platform to reduce the number of additional security boundaries. Thus, a user may avoid storing authentication or authorization material for the integrated system in an off-platform data store. There are potential vulnerabilities whenever security credentials are stored for: such as pushing code between systems, pushing built artifacts between systems, starting up computing resources, or operating running systems. These vulnerabilities include that the authorization material may be stolen, and the authorization material may expire, causing the operable system to cease functioning prior to replacement.

In some examples, the entire lifecycle of an application from concept to delivery is managed within a unified security context on the data platform. Since all work on the artifact is stored on the data platform throughout the lifecycle of the artifact and the application and data sharing manager using the data platform share the distributed version of the application (distribution build), a single security boundary is provided.

In some examples, the data platform provides an application editing surface that writes files to a data store within the data platform to store source code of the application.

In some examples, the interactive editing session of the application source code is provided by connecting to a user application in the form of a secure Web application provided by the data platform.

In some examples, an interactive editing session of application source code is provided using an editor provided by a data platform.

In some examples, promotion of development code to production is accomplished by modifying a user application or a data store storing source code of the user application to change the source code currently attached to a default version used by the user application. An end user hits (hit) a user application endpoint, where their authentication context is used to launch the user application, and the user application runs in a security context that has been configured within the data platform.

In some examples, a data platform for developing and deploying user applications in a unified security context. The data platform authorizes the first user to use the editor to access source code of the user application based on a security policy of the security context and authorizes the first user to use the application and the data manager to set a use privilege for the second user to use the user application based on the security policy of the security context. To provide the user application to the second user, the data platform deploys the user application by: instantiating a User Defined Function (UDF) server and an application engine of the UDF server within a security context, instantiating a user application as an application of the application engine within the security context, and authorizing the user application to access data of the data platform based on a security policy of the security context.

In some examples, the data platform includes one or more processors and memory storing instructions. When the instructions are executed by the one or more processors, the data platform authorizes the first user to use the editor to access source code of the user application based on a security policy of the security context, and authorizes the first user to use the application and the data manager to set a use privilege for the second user to use the user application based on the security policy of the security context. The data platform provides the user application to the second user based on the security policy of the security context by: the method includes instantiating a user-defined function (UDF) server within a security context, instantiating an application engine of the UDF server within the security context, instantiating a user application as an application of the application engine within the security context, and authorizing the user application to access data of the data platform based on a security policy of the security context.

Reference will now be made in detail to specific examples for implementing the inventive subject matter. Examples of these specific examples are shown in the accompanying drawings and specific details are set forth in the following description in order to provide a thorough understanding of the subject matter. It should be understood that these examples are not intended to limit the scope of the claims to the examples shown. On the contrary, they are intended to cover such alternatives, modifications and equivalents as may be included within the scope of the disclosure.

FIG. 1 illustrates an example computing environment 100 including a data platform 102 in communication with a client device 112, according to some examples of the disclosure. Various functional components that are not germane to an understanding of the present subject matter are omitted from fig. 1 in order to avoid obscuring the present subject matter in unnecessary detail. However, those skilled in the art will readily appreciate that various additional functional components may be included as part of the computing environment 100 to facilitate additional functionality not specifically described herein.

As shown, the data platform 102 includes a database store 106, a computing service manager 104, an execution platform 110, and a metadata database 114. Database storage 106 includes a plurality (a pluralityof) computing machines and provides computer system resources, such as data storage and computing power, to data platform 102 on demand. As shown, database storage 106 includes a plurality of data storage devices, data storage device 1 108a through data storage device N108 d. In some examples, data storage devices 1 through N are cloud-based storage devices located at one or more geographic locations. For example, the data storage devices 1 to N may be part of a public cloud infrastructure or a private cloud infrastructure. The data storage devices 1 through N may include Hard Disk Drives (HDDs), solid State Drives (SSDs), storage clusters, amazon S3 (TM) storage systems, or any other data storage technology. In addition, the database storage 106 may include a distributed file system (e.g., hadoop Distributed File System (HDFS)), an object storage system, and the like.

The data platform 102 is used to report and analyze integrated data from one or more different sources, including storage devices 1 through N within the database storage 106. The data platform 102 hosts data reporting and analysis services and provides data reporting and analysis services to a plurality of customer accounts. Administrative users can create and manage identities (e.g., users, roles, and groups) and use privileges to allow or deny access to resources and services by the identities. Typically, the data platform 102 maintains a plurality of customer accounts for a plurality of respective customers. The data platform 102 maintains each customer account in one or more storage devices of the database store 106. In addition, the data platform 102 may maintain metadata associated with the customer account in the metadata database 114. Each customer account includes a plurality of data objects, examples of which include users, roles, privileges, data stores or other data locations (referred to herein as "buffers" or "multiple buffers"), and so forth.

The computing service manager 104 coordinates and manages the operation of the data platform 102. The computing service manager 104 also performs query optimization and compilation, as well as managing clusters (also referred to as "virtual warehouses") of computing services that provide computing resources. The computing service manager 104 may support any number and any type of clients, such as end users providing data storage and retrieval requests, system administrators managing the systems and methods described herein, and other components/devices interacting with the computing service manager 104. As an example, the computing service manager 104 communicates with the client device 112. A user of one of a plurality of client accounts supported by the data platform 102 may use the client device 112 to interact with the data platform 102 and utilize the functionality of the data platform 102. In some examples, computing service manager 104 does not receive any direct communications from client device 112 and receives communications regarding jobs only from queues within data platform 102.

The computing service manager 104 is also coupled to a metadata database 114. Metadata database 114 stores data regarding various functions and aspects associated with data platform 102 and its users. In some examples, metadata database 114 includes data stored in a remote data storage system as well as summaries (surarray) of data available from a local cache. In addition, metadata database 114 may include information regarding how data is organized in remote data storage systems (e.g., database storage 106) and local caches. The metadata database 114 allows systems and services to determine whether a piece of data needs to be accessed without loading or accessing the actual data from a storage device.

The computing service manager 104 is also coupled to an execution platform 110, the execution platform 110 providing a plurality of computing resources that perform various data storage and data retrieval tasks. In some examples, the computing service manager 104 communicates jobs and tasks with the execution platform 110 using queues within the data platform 102. This isolates the operations of the execution platform 110 and the client device 112. The execution platform 110 is coupled to the database storage 106. The execution platform 110 includes a plurality of computing nodes. The collection of processes on the compute nodes execute a query plan compiled by the compute service manager 104. The process set may include: executing a first process of a query plan; monitoring and deleting the micro-partition file using a least recently used (least recently used, LRU) policy and implementing a second process of a low-memory (ook) error mitigation process; a third process that extracts health information from the process log and status to send back to the computing service manager 104; a fourth process of establishing communication with the computing service manager 104 after system boot (boot); and a fifth process that handles all communications with the computing clusters of a given job provided by the computing service manager 104 and communicates information back to the computing service manager 104 and other computing nodes of the execution platform 110.

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

As shown in fig. 1, the data storage devices (data storage device 1 108a through data storage device N108 d) are decoupled (decoupled) from the computing resources associated with the execution platform 110. The architecture supports dynamic changes of the data platform 102 based on changing data storage/retrieval requirements and changing user and system requirements. Support for dynamic changes allows the data platform 102 to expand rapidly in response to changing demands on systems and components within the data platform 102. Decoupling of the computing resources from the data storage device supports storage of large amounts of data without requiring a correspondingly large amount of computing resources. Similarly, such decoupling of resources supports a significant increase in computing resources used at a particular time without a corresponding increase in available data storage resources.

The computing service manager 104, metadata database 114, execution platform 110, and database store 106 are shown in fig. 1 as separate discrete components. However, each of the computing service manager 104, metadata database 114, execution platform 110, and database store 106 may be implemented as a distributed system (e.g., distributed across multiple systems/platforms located in multiple geographic locations). In addition, each of the computing service manager 104, metadata database 114, execution platform 110, and database store 106 may scale up or down (independently of each other) according to the changes in the received requests and the changing needs of the data platform 102. Thus, in the depicted example, the data platform 102 is dynamic and supports periodic changes to meet current data processing requirements.

During operation, data platform 102 processes a plurality of jobs as determined by computing service manager 104. These jobs are scheduled and managed by the computing service manager 104 to determine when and how to execute the jobs. For example, the computing service manager 104 may divide a job into a plurality of discrete tasks and may determine what data is needed to perform each of the plurality of discrete tasks. The computing service manager 104 may assign each of the plurality of discrete tasks to one or more nodes of the execution platform 110 to process the task. The computing service manager 104 may determine what data is needed for the processing task and further determine which nodes within the execution platform 110 are best suited for the processing task. Some nodes may already have cached the data needed for the processing task and are therefore good candidates for the processing task. Metadata stored in the metadata database 114 helps the computing service manager 104 determine which nodes in the execution platform 110 have cached at least a portion of the data required for the processing task. One or more nodes in the execution platform 110 process tasks using data cached by the nodes and, if necessary, retrieved from the database storage 106. It is desirable to retrieve as much data as possible from the cache within the execution platform 110 because the retrieval speed is typically faster than retrieving data from the database storage device 106.

As shown in fig. 1, the computing environment 100 separates the execution platform 110 from the database storage 106. In this arrangement, the processing resources and cache resources in execution platform 110 operate independently of the data storage devices (data storage device 1 108a through data storage device N108 d) in database store 106. Thus, the computing resources and cache resources are not limited to a particular one of data storage device 1 108a through data storage device N108 d. Instead, all computing resources and all cache resources may retrieve data from and store data to any data storage resource in database storage 106.

Fig. 2 is a block diagram illustrating components of computing service manager 104 according to some examples of the present disclosure. As shown in fig. 2, the computing service manager 104 includes an access manager 202 and a key manager 204 coupled to a data storage device 206. The access manager 202 handles authentication and authorization tasks for the systems described herein. The key manager 204 manages the storage and authentication of keys used during authentication and authorization tasks. For example, access manager 202 and key manager 204 manage keys for accessing data stored in a remote storage device (e.g., a data storage device in database storage 106). As used herein, a remote storage device may also be referred to as a "persistent storage device" or "shared storage device.

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

The management console service 210 supports access to various systems and processes by administrators and other system administrators. In addition, the management console service 210 may receive requests to execute jobs and monitor the workload on the system.

Computing service manager 104 also includes a job compiler 212, a job optimizer 214, and a job executor 216. Job compiler 212 parses the job into a plurality of discrete tasks and generates execution code for each of the plurality of discrete tasks. Job optimizer 214 determines the best method to perform a plurality of discrete tasks based on the data that needs to be processed. Job optimizer 214 also handles various data pruning operations and other data optimization techniques to increase the speed and efficiency of executing jobs. Job executor 216 executes execution code of jobs received from the queues or determined by the computing service manager 104.

Job scheduler and coordinator 218 sends the received jobs to the appropriate service or system for compilation, optimization, and dispatch to execution platform 110. For example, jobs may be prioritized and processed in this order of priority. In some examples, job scheduler and coordinator 218 determines the priority of internal jobs scheduled by computing service manager 104 with other "external" jobs (such as user queries that may be scheduled by other systems in the database but that may utilize the same processing resources in execution platform 110). In some examples, job scheduler and coordinator 218 identifies or assigns particular nodes in execution platform 110 to process particular tasks. Virtual warehouse manager 220 manages the operation of multiple virtual warehouses implemented in execution platform 110. As described below, each virtual warehouse includes a plurality of execution nodes, each of which includes a cache and a processor.

In addition, the computing service manager 104 includes a configuration and metadata manager 222, the configuration and metadata manager 222 managing information related to data stored in remote data storage devices and local caches (e.g., caches in the execution platform 110). The configuration and metadata manager 222 uses metadata to determine which data micro-partitions need to be accessed to retrieve data for processing a particular task or job. The monitor and workload analyzer 224 oversees the processes performed by the computing service manager 104 and manages the allocation of tasks (e.g., workloads) across virtual warehouses and execution nodes in the execution platform 110. The monitor and workload analyzer 224 also redistributes tasks based on varying workloads throughout the data platform 102, as needed, and may also redistribute tasks based on user (e.g., "external") query workloads that may also be processed by the execution platform 110. The configuration and metadata manager 222 and the monitor and workload analyzer 224 are coupled to a data storage device 226. The data storage device 226 in FIG. 2 represents any data storage device within the data platform 102. For example, the data storage 226 may represent a cache in the execution platform 110, a storage device in the database storage 106, or any other storage device.

The computing service manager 104 validates all communications from the execution platform (e.g., execution platform 110) to verify that the content and context of the communications are consistent with 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 data source D (e.g., data storage device 226) unrelated to query a. Similarly, a given executing node (e.g., executing node 1 304 a) may need to communicate with another executing node (e.g., executing node 2 304 b) and should be prohibited from communicating with a third executing node (e.g., executing node 1 316 a), and any such illegal communications may be logged (e.g., in a log or other location). Furthermore, the information stored on a given execution node is limited to data related to the current query, and any other data is not available, in the event that a key is not available, by destruction or encryption.

Fig. 3 is a block diagram illustrating components of execution platform 110 according to some examples of the present disclosure. As shown in fig. 3, the execution platform 110 includes a plurality of virtual warehouses including virtual warehouse 1 302a and virtual warehouse 2 302b through virtual warehouse N302 c. Each virtual warehouse includes a plurality of execution nodes, each of which includes a data cache and a processor. The virtual warehouse may perform multiple tasks in parallel by using multiple execution nodes. As discussed herein, the execution platform 110 may add new virtual warehouses and delete (drop) existing virtual warehouses in real-time based on current processing needs of the system and the user. This flexibility allows the execution platform 110 to quickly deploy large amounts of computing resources when needed, without having to continue to pay for those computing resources when they are no longer needed. All virtual warehouses may access data from any data storage device (e.g., any storage device in database storage 106).

Although each virtual warehouse shown in fig. 3 includes three execution nodes, a particular virtual warehouse may include any number of execution nodes. Furthermore, the number of execution nodes in the virtual warehouse is dynamic such that new execution nodes are created when there is additional demand and deleted when existing execution nodes are no longer needed.

Each virtual warehouse has access to any one of the data storage devices 1 to N shown in fig. 1. Thus, the virtual warehouse is not necessarily assigned to a particular data storage device 1 through N, but may access data from any one of the data storage devices 1 through N within the database storage arrangement 106. Similarly, each of the executing nodes shown in FIG. 3 may access data from any of the data storage devices 1 through N. In some examples, a particular virtual warehouse or particular execution node may be temporarily assigned to a particular data storage device, but the virtual warehouse or execution node may later access data from any other data storage device.

In the example of fig. 3, virtual warehouse 1 302a includes a plurality of execution nodes, as shown by execution node 1304a, execution node 2 304b, and execution node N304 c. Execution node 1304a includes cache 1 306a and processor 1 308a. Execution node 2 304b includes cache 2 306b and processor 2 308b. Execution node N304 c includes cache N306 c and processor N308 c. Each executing node 1 to N is associated with processing one or more data storage and/or data retrieval tasks. For example, the virtual warehouse may handle data storage and data retrieval tasks associated with internal services (e.g., a cluster service, materialized view refresh service, file compression service, storage program service, or file upgrade service). In other implementations, a particular virtual warehouse may handle data storage and data retrieval tasks associated with a particular data storage system or class of data.

Similar to virtual warehouse 1 302a discussed above, virtual warehouse 2 302b includes multiple execution nodes, as shown by execution node 1 310a, execution node 2 310b, and execution node N310 c. Execution node 1 310a includes cache 1 312a and processor 1 314a. Execution node 2 310b includes cache 2 312b and processor 2 314b. Execution node N310 c includes cache N312 c and processor N314 c. In addition, virtual warehouse N302 c includes a plurality of execution nodes, as shown by execution node 1 316a, execution node 2 316b, and execution node N316 c. Execution node 1 316a includes cache 1 318a and processor 1 320a. Execution node 2 316b includes cache 2 318b and processor 2 320b. Execution node N316 c includes cache N318 c and processor N320 c.

In some examples, the execution node shown in fig. 3 is stateless with respect to the data that the execution node is caching. For example, the executing nodes do not store or otherwise maintain state information about the executing nodes or the data cached by a particular executing node. Thus, in the event of a failure of an executing node, the failed node may be transparently replaced with another node. Since there is no state information associated with the failed execution node, the new (replacement) execution node can easily replace the failed node without considering recreating the particular state.

Although the execution nodes shown in fig. 3 each include one data cache and one processor, alternative examples may include execution nodes that include any number of processors and any number of caches. In addition, the size of the cache may vary between different executing nodes. The cache shown in fig. 3 stores data retrieved from one or more data storage devices in database storage 106 in the local execution node. Thus, the cache reduces or eliminates bottlenecks that occur in platforms that constantly retrieve data from remote storage systems. The systems and methods described herein do not repeatedly access data from a remote storage device, but rather access data from a cache in an executing node, which is significantly faster and avoids the bottleneck problems discussed above. In some examples, the cache is implemented using a cache memory device that provides fast access to cached data. Each cache may store data from any storage device in database storage 106.

Furthermore, the cache resources and computing resources may vary between different execution nodes. For example, an execution node may contain a large amount of computing resources and a minimum of cache resources, thereby making the execution node available for tasks requiring a large amount of computing resources. Another execution node may contain a large amount of cache resources and minimal computing resources, thereby making the execution node available for tasks that require caching large amounts of data. Yet another execution node may contain cache resources that provide faster input-output operations, which is useful for tasks that require fast scanning of large amounts of data. In some examples, cache resources and computing resources associated with a particular execution node are determined at the time of creation of the execution node based on the intended task to be performed by the execution node.

Additionally, the cache resources and computing resources associated with a particular execution node may change over time based on the changing tasks performed by the execution node. For example, if the tasks performed by the executing nodes become more processor intensive, more processing resources may be allocated to the executing nodes. Similarly, if a task performed by an executing node requires more cache capacity, more cache resources may be allocated to the executing node.

Although virtual warehouses 1, 2, and N are associated with the same execution platform 110, the virtual warehouses may be implemented using multiple computing systems at multiple geographic locations. For example, virtual warehouse 1 may be implemented by a computing system at a first geographic location, while virtual warehouse 2 and virtual warehouse N are implemented by another computing system at a second geographic location. In some examples, the disparate computing systems are cloud-based computing systems maintained by one or more disparate entities.

In addition, each virtual warehouse as shown in fig. 3 has a plurality of execution nodes. Multiple computing systems located at multiple geographic locations may be used to implement multiple execution nodes associated with each virtual warehouse. For example, an instance of virtual warehouse 1 302a implements execution node 1 304a and execution node 2 304b on one computing platform at one geographic location, and execution node N304 c at a different computing platform at another geographic location. The selection of a particular computing system to implement an execution node may depend on various factors, such as the level of resources (e.g., processing resource requirements and cache requirements) required by the particular execution node, the resources available at the particular computing system, the communication capabilities of the network within or between geographic locations, and which computing systems have implemented other execution nodes in the virtual warehouse.

The particular execution platform 110 may include any number of virtual warehouses. In addition, the number of virtual warehouses in a particular execution platform is dynamic such that new virtual warehouses are created when additional processing resources and/or cache resources are needed. Similarly, when resources associated with the virtual warehouse are no longer needed, the existing virtual warehouse may be deleted.

In some examples, the virtual warehouses may operate on the same data in the database storage 106, but each virtual warehouse has its own execution node with independent processing resources and cache resources. This configuration allows independent processing of requests on different virtual warehouses without interfering with each other between requests. This independent processing, combined with the ability to dynamically add and remove virtual warehouses, supports the addition of new processing capabilities for new users without affecting the performance observed by existing users.

FIG. 4A is a deployment diagram of a computing environment 400 for providing a Web application as a first type of database object, according to some examples. The data platform 102 utilizes the computing environment 400 to provide a security framework for user applications 410 to be executed by the execution platform 110 of the data platform 102. The user application 410 and all components supporting the user application 410, such as, but not limited to, the Web application engine 408 and the User Defined Function (UDF) server 406, collectively referred to herein as "Web applications", are treated by the data platform 102 as a first type of database object, as can be instantiated using one or more commands within a database query, as shown in the following code segments:

Wherein:

< webapp_name > specifies an identifier of the Web application that is unique to the schema that created the Web application.

< version_name > specifies an identifier of the Web application version.

< app_root > is a reference to the scratch pad URL (stage URL) that points to the root of the user application 410. When the user application is running, files under the app_root will be available to the Web application engine 408. While versions may be in the same scratch pad within the data platform 102, separated only by prefixes, it may be useful for each version to have a different scratch pad to better manage privileges and cleaning.

The < file_name > is a path of a user file to be run as part of the Web application engine 408. This is relative to < app_root >.

< wasehouse_name > is the name of the virtual repository, e.g., virtual repository 1 302a of data platform 102 to run user application 410.

< comment_string_language > is an annotation describing the Web user application 410.

A partial list of privileges enforced by security manager policy 420 and/or sandbox policy 422 for user application 410 and its supporting components is described in tables 1 and 2:

TABLE 1

TABLE 2

In some examples, there are objects of the data platform 102 on which the user application 410 depends, such as, but not limited to, storage locations or scratch pads for storing files, and virtual warehouses, such as virtual warehouse 1 302a, into which the user application 410 is loaded. When the user application 410 and its associated components referencing the scratch pad are created, the user application 410 inherits the READ privileges to the scratch pad and the use privileges to the virtual warehouse. If the privileges of the scratch pad were changed after the user application 410 was created such that the owner of the user application 410 no longer has privileges to the scratch pad, the request for the user application 410 would fail with an error stating that the user application 410 does not exist. If the privileges of the repository were changed after the user application 410 was created, the logic that enabled the repository to be used would appear as if the repository was not set. In some examples, the scratch pad or data location is embedded into the user application 410 or one of the associated components of the user application, and the privileges to the user application 410 and the scratch pad are associated together. In some examples, user application 410 and its related components may be shared with other owners or users according to privileges stored in security manager policy 420 and/or sandbox policy 422.

Thus, when instantiated, the user application 410 and all its supporting components inherit all of the attributes of the first class of objects within the database provided by the data platform 102, including privileges and restrictions that may be used by the data platform 102 to manage database objects. In some examples, the user application 410 is provided by the UDF server 406 using the Web application engine 408 as a service, and can be accessed over a network (e.g., the internet) by a Web application browser runtime (runtime) component 404 using protocols for accessing documents and files on the world wide Web, the Web application browser runtime component 404 being included in the browser 402 hosted by the client device 112.

As described with reference to fig. 2, the computing service manager 104 implements a security policy that validates all communications from the execution platform 110 to verify that the content and context of the communications are consistent with tasks known to be assigned to the execution platform 110. For example, the execution platform 110 executing query a is not allowed to request access to a particular data source (e.g., either the data store 226 or the database store 106) that is not related to query a. In some examples, the execution node 424 may need to communicate with a second execution node, but the security mechanisms described herein may not allow communication with a third execution node. Further, any such illegal communications may be recorded (e.g., in log 418 or other location). Furthermore, the information stored on a given execution node is limited to data related to the current query, and any other data is unusable by destruction or encryption in the event that the key is not available.

In some examples, the UDF server 406 and its components (e.g., web application engine 408 and user application 410) are implemented in a particular programming language (e.g., python, etc.). In some examples, web application browser runtime component 404 is implemented in a different programming language (e.g., C or c++) than UDF server 406, which can further improve the security of computing environment 400 by using different codebases (e.g., codebases that do not have the same or fewer potential security vulnerabilities).

The UDF server 406 receives communications from the Web application browser runtime component 404 via the global service process 444 of the data platform 102. Global services process 444 is responsible for receiving requests from Web application browser runtime component 404. The global service process 444 uses components of the computing service manager 104 to perform various authentication tasks, including using the access manager 202 of the computing service manager 104 to conduct a first level of authorization based on the security policies 232. The UDF server 406 performs tasks including assigning processing threads to execute user code of the user application 410 and returning results generated by the user application 410 to the Web application browser runtime component 404 via the global service process 444.

In some examples, the UDF server 406 executes within a sandboxed process 414, as described more fully below. In some examples, the UDF server 406 is implemented with Python interpreted by an interpreter process. In some examples, the UDF server 406 is implemented in another language (e.g., java) that is executed by a virtual machine (JVM). Since the UDF server 406 is advantageously executed in a separate process with respect to the browser 402, the risk of malicious manipulation of the user application 410 is low.

The results of performing the operations may be stored in log 418 for viewing and retrieval, among other types of information or messages. In some examples, log 418 may be stored locally in memory at execution node 424 or in a separate location such as database storage 106.

In some examples, security manager 416 may prevent completion of an operation from user application 410 by throwing an exception (e.g., if the operation is not permitted) or returning (e.g., do nothing) if the operation is permitted. In one implementation, security manager 416 is implemented as a security manager object that allows applications to implement security policies, such as security manager policy 420, and enables applications to determine what an operation is and whether the operation is being attempted in a security context that allows the operation to be performed before performing the operation that may be unsafe or sensitive. The security manager policy 420 may be implemented as a file with the privileges granted to the UDF server 406. Thus, the UDF server 406 may or may not allow this operation based at least in part on the security policy.

In some examples, sandboxed process 414 reduces the risk of security vulnerabilities by restricting the running environment of untrusted applications using security mechanisms such as namespaces and secure computing modes (e.g., using system call filters for executing processes and all their offspring, thereby reducing the attack surface on the kernel of a given operating system). Furthermore, in some examples, sandboxed process 414 is a lightweight process and is optimized (e.g., tightly coupled to the security mechanisms of a given operating system kernel) to process database queries or other service requests in a secure manner within the sandboxed environment.

In some examples, sandboxed process 414 may utilize a virtual network connection to communicate with other components within computing environment 400. A particular set of rules may be configured for virtual network connections for other components of computing environment 400. For example, such rules of virtual network connection may be configured for a particular UDF server 406 to limit the locations accessible to operations performed by the UDF server 406 (e.g., specific sites on the internet or components that the UDF server 406 may communicate with). Thus, in this example, the UDF server 406 may be denied access to a particular network location or site on the internet.

Sandboxed process 414 may be understood as providing a constrained computing environment to a process (or processes) within the sandbox, where the constrained processes may be controlled and restricted to restrict access to certain computing resources.

Examples of security mechanisms may include: an implementation of a namespace in which each respective group of processes executing in the sandboxed environment can access a respective computing resource (e.g., process ID, hostname, user ID, filename, name related to network access, and inter-process communication) that is inaccessible by another group of processes (a different group of resources that is inaccessible to a previous group of processes); other container implementations, etc. By having the sandboxed process 414 execute as a sub-process, the latency of processing a given database query may be significantly reduced in some examples compared to other techniques that may themselves utilize virtual machine solutions.

As further shown, sandboxed process 414 may utilize sandboxed policy 422 to implement a given security policy. Sandboxed policy 422 may be a file with information related to the configuration of sandboxed process 414 and details regarding restrictions (if any) and privileges on access and utilization of system resources. Example restrictions may include restrictions on network access or file system access (e.g., remapping the file system to place files in different locations that may not be accessible, other files may be installed in different locations, etc.). In some examples, sandboxed process 414 restricts the use of memory and processors (e.g., CPUs) of UDF server 406, ensuring that other operations on the same execution node can be performed without exhausting resources.

The Web application browser runtime component 404 provides a front end for the user application 410. The Web application browser runtime component 404 performs browser interactions with the data platform 102 of the user application 410. The components of computing environment 400 communicate using a web application protocol 412, the web application protocol 412 providing a set of commands for interaction between user application 410 and browser 402. The web application protocol 412 logically interacts with the user application 410 and physically traverses layers of the data platform 102 to ensure that security restrictions and policies are enforced on each layer. These may include permissions or runtime requirements from the computing service manager 104. The Web application browser runtime component 404 sends back a message that is processed by the execution platform 110 and responded to with a series of forwarding messages.

Web application engine 408 includes instructions that can be defined by a third party but run within execution platform 110 as an application. Web application engine 408 provides a programming framework that a user can build applications such as user application 410. In some examples, web application engine 408 is written in Python and is treated by execution platform 110 as a special Python storage procedure. In some examples, web application engine 408 is written in another language (e.g., without limitation, java) and is hosted by a virtual machine within execution platform 110. In some examples, third parties may build their own Web application engine.

The user applications 410 include applications written by end users and evaluated by the Web application engine 408. In some examples, the user application 410 includes a Python file that is evaluated by a proprietary Python interpreter.

The UDF server 406 is responsible for running UDFs in a controlled execution environment such as sandboxed process 414. In some examples, the UDF server 406 includes a Python UDF server. In some examples, the UDF server 406 utilizes other languages, such as Java.

In some examples, a Uniform Resource Locator (URL) identification assigned to the UDF server 406 is a unique value that is stable in replication of the UDF server 406. For example, the URL identification is a randomly generated string that is unique in the owner's account. The URL identification can be created by encoding it using UUID4 and Base64 to give it a more compact representation.

In some examples, schema objects of the data platform 102 are used to define components of Web applications such as, but not limited to, UDF server 406, web application engine 408, user applications 410, and Web application browser runtime component 404. The name, network endpoint, privileges, and policies are all based on the object. In some examples, the schema objects include the particular version of the Web application engine 408 to be used and any resource constraints.

In some examples, a version of the user code is specified and will be associated with a named version of the web application that refers to a place on the scratch pad that the data platform 102 uses to run the user code.

Fig. 4B, 4C, and 4D are interaction and data flow diagrams of a computing environment 400 for providing a Web application as a first type of database object, according to some examples.

The computing environment 400 utilizes a rowset operator (Row Set Operators, RSO) that runs as part of a program in the execution platform 110. RSOI is an instance of RSO that operates on a processing thread of execution platform 110. The RSOI extension function is the RSOI that runs the stored procedure. In some examples, the storage process is written in Python. In some examples, the stored procedures are written in Java.

The owner of the RSOI extension function 436 sets permissions for the RSOI extension function 436 itself, defines who can use it, and sets different roles for running it. Setting these permissions occurs when the user defines the RSOI extension function 436 and the implementation occurs in the Web application resource 442 when the browser accesses a URL associated with the Web application. Web application resource 442 will also initiate a job that sets its permission context. The RSOI extension function 436 operates in the permission/session context. In some examples, the owner sets permissions for each object to be instantiated, such as, but not limited to, UDF server 406, web application engine 408, and user application 410.

In operation 1, browser 402 hosted by client device 112 communicates with user application 410 hosted by data platform 102 using a Web socket connection to Web application resource 442. The access manager 202 of the computing service manager 104 of the data platform 102 grants access to the user application 410 based on a set of security policies 232 stored on the data storage device 206. When authorized, the data platform 102 provides the user application 410 to the user using the browser 402. The Web application browser runtime component 404 pulls the message from the Web socket and issues the appropriate command.

If there is no current session with an instance of Web application engine 408, web application browser runtime component 404 verifies that the request has permission to use the application using the security context defined for user application 410, and then requests UDF server 406 to start the job. The initial execution plan launches an instance of the Web application engine 408 for the job. Web application engine 408 will be instantiated based on security manager policies 420 and sandbox policies 422 implemented by security manager 416 and sandbox process 414, respectively, and the event is logged into log 418. After the session of the Web application engine 408 is started, the Web application engine 408 sends a command to the query coordinator 430.

In operation 2, the job has a query coordinator 430 associated with the job. From this point on, communication with the Web application engine 408 occurs by adding a query coordinator event of the "application interaction" type to the query coordinator 430. This will result in queuing of the running request. The query coordinator event also has a reference to a stream through which it can send a forward message to reach browser 402. In this way, query coordinator 430 can obtain response events and communicate them directly back to browser 402.

In operation 3, an application request queue 426 is provided. The application request queue 426 is an in-memory queue to which return messages are pushed. In some examples, the application request queue 426 is in memory to ensure that the connection at operation 4 always returns to the same global service instance as the query coordinator 430 is located. In some examples, in the event of a global service failure, the lost message is allowed and the Web application browser runtime component 404 is caused to reestablish state with the new running request.

In operation 4, the RSOI extension function 436 initiates a special memory procedure that runs for a long time. The stored procedure runs in a security context that is configured for objects to be instantiated on the execution node 424 based on the security manager policy 420 and the sandbox policy 422. The stored procedures create a UDF server 406, which UDF server 406 runs scripts securely in a locked environment of the execution node 424 of the execution platform 110. The RSOI extension function 436 uses RPC calls to launch the Web application engine 408 through the UDF server 406 based on stored procedures. The RSOI extension function 436 invokes an "execute procedure" with function information that will tell the stored procedure Web application engine 408 not to terminate. The Web application engine 408 is instantiated during the verification process based on security manager policies 420 and sandbox policies 422 implemented by the security manager 416 and sandbox process 414, respectively, and the event is logged into the log 418. The process of the Web application engine 408 connects to the streaming application request RPC endpoint on the UDF server 406 and issues an initialization application message. The message will be used to direct the Web application engine 408 with the appropriate policy and file information to run the user application 410. This information is passed as part of the execution plan for operation 1 that started the user application 410. The RSOI extension function 436 is connected to the Web application interaction channel 434 end point in the execution platform resource 432 and processes messages incoming through that channel. The UDF server 406 can then use the specially stored procedures to run the Web application engine 408 and the user application 410 to proxy communications from the browser in a low latency and efficient manner.

In some examples, the network endpoint is based on a URL based on an account locator, providing a domain for each owner's account to act as a browser security boundary. In other examples, the components of the URL identifier are unique and non-guessable numbers. URL identification is stable when renamed and copied to other accounts. The user of browser 402 may directly access the URL. To this end, they will be required to log onto the data platform 102, and they will need to have access privileges to the user application 410.

Messages from the execution platform resource 432 are user-driven interactions that are obtained through the use or editing of an application. The messages to the UDF server 406 are defined in a document defining the UDF application request. For application user requests, the RSOI extension function 436:1. the message requests are proxied back to the appropriate UDF server 406 and made to be processed by the Web application engine 408; 2. update file message request command RSOI extension function 436: a. searching files needing to be updated; b. sending an update file start command; c. following update file commands required to update the appropriate files used by Web application engine 408; and d, generating an update file ending message. Security manager 416 and sandboxed process 414 use security manager policy 420 and sandboxed policy 422, respectively, to verify all access by user application 410 to execution platform 110 using Web application engine 408, such as, but not limited to, data stored in database storage 106 and additional functions and processes performed by execution platform 110. This allows the execution platform 110 to provide services to the browser 402 through the user application 410 without requiring data to be moved with the execution platform 110 between a secure and an unsecure location, thereby enhancing extensibility and security. In some examples, for the HTTP channel of the "execute platform resource (execution platform resource)" command, the Protobuf protocol is used in both directions using ContentType = application/oct-stream. In some examples, the Protobuf protocol is used in both directions in an encoded manner, which would allow multiple messages to be pushed down the stream without having to close the TCP connection and reissue the request.

In operation 5, referring to fig. 4d, the udf server 406 manages the lifecycle of the Web application engine 408. The UDF server 406 initiates and then manages requests incoming by streaming applications requesting endpoints. Referring to fig. 4D, in some examples, there are two basic types of messages: application user request 440 and application control plane request 438. The application user request 440 is passed directly into the method of operation of the Web application engine 408. The application control plane request 438 is directed to the UDF server 406 for some system operations such as, but not limited to, updating files, initializing applications or closing things.

In operation 6, the Web application process includes an additional lifecycle function that is invoked. An example web application process is shown in part in the code segment:

in some examples, UDF server 406 knows which functions are associated with which operations by specifying in the stored procedure data persistence object and passing as part of launching Web application engine 408. In some examples, UDF server 406 knows which functions are associated with which operations because stored procedure DPO has a handler (handler) as the starting function, and the return type of the starting function returns a function table that specifies other functions. In some examples, UDF server 406 knows which functions are associated with which operations because stored procedure DPO has a handler as the starting function and provides an annotation that UDF server 406 can look for to find other functions. In some examples, the new attribute of the stored procedure marks the stored procedure as Web application engine 408. When the item is set, the handler calls a function that returns a function table that maps to the different application lifecycle events (e.g., run, file change, etc.) above.

In operation 7, a response from the UDF server 406 is returned through the execution platform resource. When the user application 410 adds a message to the application response queue 428, the UDF server 406 will take these responses and pass them back through the RPC endpoint to the RSOI extension function 436, which then the RSOI extension function 436 sends them along a long polling HTTP connection to a web application interaction-channel (web-app-interaction-channel) in the execution platform resource. The execution platform resource places the response in the application response queue 428 and notifies the query coordinator 430.

In operation 8, the query coordinator 430 sends a response back to the browser 402. Query coordinator 430 picks up the event and filters out any messages that violate the policy (e.g., unrestricted JS or HTML). Because the query coordinator 430 has been provided with a response channel when it obtained the query coordinator event, it uses the response channel to send back a response. In some examples, the execution platform resource send request itself when it is ensured that the web socket is in the same global service as query coordinator 430. In some examples, when it cannot be ensured that the web socket is in the same global service as query coordinator 430, query coordinator 430 performs the operation of sending back a response because there is already a function to find the correct global service instance for query coordinator 430.

FIG. 5 is a deployment diagram of a computing environment 500 of a data platform 102, the computing environment 500 providing a unified security context 502 for development and use of user applications 410, in accordance with some examples of the present disclosure. The computing environment 500 supports a unified security context 502 for components of the data platform 102, which provide a software development environment for developing source code, such as user application source code 512 of a user application (e.g., user application 410). As part of the unified security context 502, the computing environment 500 also supports a production environment for providing the user application 410 as part of a Web application that allows users to access resources of the data platform 102, such as database objects 510 stored in the database storage 106.

The access manager 202 grants access to the components and objects of the unified security context 502 based on privileges specified in the security policies 506, the security policies 506 including one or more security policies for the components and objects within the unified security context 502. Security policies 506 include, but are not limited to: security policies applied to user application source code 512 stored on the scratch pad of the data platform 102 and database objects 510 stored in the database storage 106, and security policies applied to the use and sharing of the user application 410. The security policies 506 also include a security manager policy 420 implemented by the security manager 416 and a sandbox policy 422 implemented by the sandboxed process 414, as described with reference to fig. 4A, 4B, 4C, and 4D.

The computing environment 500 includes a data explorer (data explorer) 228 used by a user to access database objects 510 stored in the database storage 106. The data resource manager 228 includes a visualizer 508, which can be used by a user to access and display data of database objects 510. The data resource manager 228 also includes an editor that a user may use to create, edit, and/or store database queries and software source code for accessing and modifying data of the database object 510, such as the user application source code 512 of the user application 410. The access manager 202 uses one or more of the security policies 506 to determine whether the user is authorized to use the data resource manager 228 to access components or database objects of the data platform 102 to which the unified security context 502 relates. These users include, but are not limited to: a user of the data platform 102 that is the owner of the user application 410 and/or database object 510, a user within the same account of the owner, a user of another account that is different from the owner account, an external system outside of the data platform 102, and so forth.

The computing environment 500 also includes an application and data manager 230, which application and data manager 230 allows a user to specify which other entities may share the use of the user application 410 and may access and/or modify the data of the database object 510. The access manager 202 uses one or more of the security policies 506 to determine whether the user is authorized to access the security policies 506 using the application and the data manager 230 in order to set security policies that allow another user to access components or database objects of the data platform 102 to which the unified security context 502 relates. These users include, but are not limited to: a user of the data platform 102 that is the owner of the user application 410 and/or database object 510, a user within the same account of the owner, a user of another account that is different from the owner account, an external system outside of the data platform 102, and so forth.

The sandboxed process 414, security manager 416, UDF server 406, and Web application engine 408 operate to provide a secure execution environment for the user application 410, as described herein with reference to fig. 4A, 4B, 4C, and 4D. Sandboxed process 414 and security manager 416 use their respective security policies included in security policies 506 to provide user access to user application 410 using browser 402, which browser 402 has Web application browser runtime component 404 and is hosted by client device 112, as described herein with reference to fig. 4A, 4B, 4C, and 4D.

In some examples, access manager 202 uses one or more of security policies 506 to determine whether to allow a user to access user application source code 512 using an editor provided by a Web application that provides an external editor (not shown). The external editor is provided according to the method described in fig. 4A, 4B, 4C and 4D. In some examples, the user application of the Web application includes an editor executed by the execution platform 110, with a UI of the editor provided by a Web application browser runtime component of a browser hosted by the client device. In additional examples, the user application of the Web application includes a proxy server executed by the execution platform 110, and the Web application browser runtime component of the browser of the client device includes an editor that accesses the user application source code 512 through the user application acting as a proxy server.

Fig. 6 is an activity diagram illustrating a method 600 of developing and deploying user applications 410 in a unified security context 502 by a data platform 102, according to some examples of the present disclosure.

In operation 602, the data platform 102 provides an editor 504 to a first user 614, the first user 614 using the editor 504 to create, edit, and/or store user application source code 512 of the user application 410 based on the security policy 506. Access to user application source code 512 by first user 614 using editor 504 is determined by access manager 202, and access manager 202 authorizes first user 614 to create, edit, and/or store user application source code 512 on database storage 106 of data platform 102 using the editor based on security policy 506.

In operation 604, the first user 614 uses the application and data manager 230 to set the sharing and usage privileges of the database object 510 and the user application 410 by setting the privileges stored in the security policy 506. Access to the security policies 506 by the user using the application and data manager 230 is determined by the access manager 202, and the access manager 202 authorizes the first user 614 to create, edit, and store sharing and usage privileges based on the security policies 506. These privileges allow additional users and systems, such as second user 616, to be authorized to access data of database object 510 and other components of data platform 102 using user application 410. The sharing and usage privileges are stored in security policy 506.

In operation 606, the data platform 102 deploys the user application 410, thereby making the user application 410 available to one or more users, such as the second user 616.

In operation 608, the data platform 102 receives a request from the second user 616 to access data of components and/or database objects located on the data platform 102. In response, the data platform 102 provides the user application 410 to the second user 616 based on the security policy 506. Providing the user application 410 to the second user 616 is determined by the access manager 202, and the access manager 202 authorizes the second user 616 to use the user application 410 to access the components of the data platform 102 and the database object 510 based on the security policy 506.

In operation 610, the user application 410 accesses the components of the data platform 102 and the data of the database object 510 based on the security policy 506. The interaction of the user application 410 with the components of the data platform 102 and the database object 510 is authorized in part by the security manager 416 based on the security manager policies 420 in the security policies 506. In addition, interactions of user application 410 with components of data platform 102 and database objects are authorized in part by sandboxed process 414 based on sandboxed policy 422 included in security policy 506.

In operation 612, the user application 410 provides the data of the database object 510 to the second user 616. The data providing database object 510 to second user 616 via user application 410 is determined by access manager 202, and access manager 202 authorizes second user 616 to access components of data platform 102 and database object 510 using user application 410 based on security policy 506.

In some examples, user application source code 512 is accessed and edited using an editor (not shown) provided by the Web application.

In some examples, the user application 410 allows external systems to access the data platform 102. For example, a user application of the data platform 102 acts as a proxy server, allowing external systems to access the components of the data platform and the data of the database object 510.

Fig. 7 shows a diagrammatic representation of machine 700 in the form of an example computer system within which a set of instructions, for causing the machine 700 to perform any one or more of the methodologies discussed herein, may be executed within the machine 700. In particular, FIG. 7 shows a diagrammatic representation of a machine 700 in the example form of a computer system within which instructions 702 (e.g., software, programs, applications, applets, apps, or other executable code) for causing the machine 700 to perform any one or more of the methods discussed herein may be executed. For example, the instructions 702 may cause the machine 700 to perform any one or more operations of any one or more of the methods described herein. In this manner, the instructions 702 transform a generic, un-programmed machine into a particular machine 700 (e.g., the computing service manager 104, the execution platform 110, and the data storage devices 1 through N of the database storage 106), the particular machine 700 being specifically configured to perform any of the functions described and illustrated in the manner described herein.

In alternative examples, machine 700 operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine 700 may operate in the capacity of a server machine or a client machine in server-client network environments, or as a peer machine in peer-to-peer (or distributed) network environments. Machine 700 may include, but is not limited to, a server computer, a client computer, a Personal Computer (PC), a tablet computer, a laptop, a netbook, a smart phone, a mobile device, a network router, a network switch, a network bridge, or any machine capable of executing instructions 702 sequentially or otherwise, the instructions 702 specifying actions to be taken by machine 700. Furthermore, while only a single machine 700 is illustrated, the term "machine" shall also be taken to include a collection of machines that individually or jointly execute instructions 702 to perform any one or more of the methodologies discussed herein.

Machine 700 includes a processor 704, a memory 706, and an I/O component 708 configured to communicate with each other, for example, via a bus 710. In some examples, the processor 704 (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, a plurality of processors as shown by processor 712 and processor 714 that may execute instructions 702. The term "processor" is intended to include a multi-core processor, which may include two or more separate processors (sometimes referred to as "cores") that may concurrently execute instructions 702. Although fig. 7 shows multiple processors 704, machine 700 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.

Memory 706 may include a main memory 732, a static memory 716, and a storage unit 718 including a machine storage medium 734, all of which may be accessed by processor 704, for example, via bus 710. Main memory 732, static memory 716, and storage unit 718 store instructions 702, the instructions 702 embodying any one or more of the methodologies or functions described herein. The instructions 702 may also reside, completely or partially, within the main memory 732, within the static memory 716, within the storage unit 718, within the at least one processor 704 (e.g., within a processor's cache memory), or within any suitable combination thereof, during execution thereof by the machine 700.

Input/output (I/O) component 708 includes components for receiving input, providing output, producing output, transmitting information, exchanging information, capturing measurements, and the like. The particular I/O components 708 included in a particular machine 700 will depend on the type of machine. For example, a portable machine such as a mobile phone would likely include a touch input device or other such input mechanism, while a headless server machine would likely not include such a touch input device. It will be appreciated that the I/O component 708 can comprise many other components not shown in FIG. 7. The grouping of the I/O components 708 by function is merely to simplify the discussion below, and is in no way limiting. In various examples, the I/O component 708 can include an output component 720 and an input component 722. The output component 720 may include visual components (e.g., a display such as a Plasma Display Panel (PDP), a Light Emitting Diode (LED) display, a Liquid Crystal Display (LCD), a projector, or a Cathode Ray Tube (CRT)), acoustic components (e.g., speakers), other signal generators, and so forth. The input components 722 may include an alphanumeric input component (e.g., a keyboard, a touch screen configured to receive alphanumeric input, an optoelectronic keyboard, or other alphanumeric input component), a point-based input component (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or another pointing instrument), a tactile input component (e.g., a physical button, a touch screen providing the location and/or force of a touch or touch gesture, or other tactile input component), an audio input component (e.g., a microphone), and so forth.

Communication may be accomplished using a variety of techniques. The I/O components 708 can include a communication component 724, the communication component 724 operable to couple the machine 700 to a network 736 or a device 726 via coupling 730 and coupling 728, respectively. For example, communication component 724 may include a network interface component or another suitable device that interfaces with network 736. In further examples, communication component 724 may include wired communication components, wireless communication components, cellular communication components, and other communication components that provide communication via other modalities. Device 726 may be another machine or any of a variety of peripheral devices (e.g., a peripheral device coupled via a Universal Serial Bus (USB)). For example, as described above, machine 700 may correspond to any of computing service manager 104, execution platform 110, and device 726 may include data storage device 226 or any other computing device described herein in communication with data platform 102 or database store 106.

The various memories (e.g., 706, 716, 732 and/or memories of processor 704 and/or storage unit 718) may store one or more sets of instructions 702 and data structures (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. These instructions 702, when executed by the processor 704, cause various operations to implement the disclosed examples.

As used herein, the terms "machine storage medium," "device storage medium," and "computer storage medium" mean the same and may be used interchangeably throughout this disclosure. These terms refer to single or multiple storage devices and/or media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the executable instructions and/or data. Accordingly, these terms should be considered to include, but are not limited to, solid-state memory including memory internal or external to the processor, as well as optical and magnetic media. Specific examples of machine, computer, and/or device storage media include nonvolatile 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 array (FPGA), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disk; CD-ROM and DVD-ROM discs. The terms "machine storage medium," "computer storage medium," and "device storage medium" specifically exclude carrier waves, modulated data signals, and other such medium (at least some of which are contained in the term "signal medium" discussed below).

In various examples, one or more portions of network 736 may be an ad hoc network (ad hoc network), an intranet, an extranet, a Virtual Private Network (VPN), a Local Area Network (LAN), a Wireless LAN (WLAN), a Wide Area Network (WAN), a Wireless WAN (WWAN), a Metropolitan Area Network (MAN), the internet, a portion of the Public Switched Telephone Network (PSTN), a Plain Old Telephone Service (POTS) networkNetwork, cellular telephone network, wireless network,A network, another type of network, or a combination of two or more such networks. For example, network 736 or a portion of network 736 may include a wireless or cellular network and coupling 730 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, the coupling 730 may implement any of a number of types of data transmission technologies, such as single carrier radio transmission technology (1 xRTT), evolution data optimized (EVDO) technology, general Packet Radio Service (GPRS) technology, enhanced data rates for GSM evolution (EDGE) technology, third generation partnership project (3 GPP) including 3G, fourth generation wireless (4G) networks, fifth generation wireless (5G) networks, universal Mobile Telecommunications System (UMTS), high Speed Packet Access (HSPA), worldwide Interoperability for Microwave Access (WiMAX), long Term Evolution (LTE) standards, other technologies defined by various standards setting organizations, other long range protocols, or other data transmission technologies. / >

The instructions 702 may be transmitted or received over the network 736 using a transmission medium via a network interface device (e.g., a network interface component included in the communication component 724) and utilizing any of a variety of well-known transmission protocols (e.g., hypertext transfer protocol (HTTP)). Similarly, instructions 702 may be transmitted to device 726 or received via coupling 728 (e.g., a peer-to-peer coupling) using a transmission medium. The terms "transmission medium" and "signal medium" are synonymous and may be used interchangeably throughout this disclosure. The terms "transmission medium" and "signal medium" should be understood to include any intangible medium capable of storing, encoding or carrying instructions 702 for execution by the machine 700, and include digital or analog communications signals or other intangible medium to facilitate communication of such software. The terms "transmission medium" and "signal medium" should therefore be understood to include any form of modulated data signal, carrier wave, etc. The term "modulated data signal" means a signal that: having one or more of its characteristics set or changed in such a manner as to encode information in the signal.

Various operations of the example methods described herein may be performed, at least in part, by one or more processors that are temporarily configured (e.g., via software) or permanently configured to perform the relevant operations. Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some operations of the methods disclosed herein may be performed by one or more processors. The performance of certain operations may be distributed among one or more processors, residing not only within a single machine, but also across multiple machines. In some examples, one or more processors may be located in a single location (e.g., within a home environment, an office environment, or a server farm), while in other examples, processors may be distributed across multiple locations.

Although examples of the present disclosure have been described with reference to specific examples, it will be evident that various modifications and changes may be made to these examples without departing from the broader scope of the inventive subject matter. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show, by way of illustration and not of limitation, specific examples in which the subject matter may be practiced. The examples shown are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other examples and examples derived therefrom may be used such that structural or logical substitutions and changes may be made without departing from the scope of this disclosure. This detailed description is, therefore, not to be taken in a limiting sense, and the scope of various examples is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, irrespective of any other instances or usages of "at least one" or "one or more". In this document, the term "or" is used to refer to a non-exclusive or, unless otherwise indicated, and thus "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 the plain-english equivalents of the respective terms "comprising" and "in which". Furthermore, in the appended claims, the terms "including" and "comprising" are open-ended; that is, a system, device, article, or process that comprises elements other than those listed after such term in a claim is nonetheless considered to fall within the scope of that claim.

Such examples of inventive subject matter may be referred to herein, individually and/or collectively, by the term "example" merely for convenience and without intending to voluntarily limit the scope of this application to any single application or inventive concept if more than one is in fact disclosed. Thus, although specific examples are illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific examples shown. This disclosure is intended to cover any and all adaptations or variations of various examples. Combinations of the above examples, and other examples not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Claims (3)

1. A data platform, comprising:

one or more processors; and

at least one memory storing instructions that, when executed by the one or more processors, cause the data platform to perform operations comprising:

authorizing a first user to use an editor to access source code of a user application based on a security policy of a security context;

authorizing the first user to use an application and a data manager based on the security policy of the security context to set a use privilege for a second user to use the user application; and

Providing the user application to the second user based on the security policy of the security context by performing operations comprising:

instantiating a user-defined function server within the security context;

instantiating an application engine of the user-defined function server within the security context;

instantiating the user application within the security context as an application of the application engine; and

the security policy based on the security context authorizes access to data by the user application.

2. A computer-implemented method, comprising:

authorizing, by the one or more processors, the first user to access source code of the user application using the editor based on a security policy of the security context;

authorizing, by the one or more processors, the first user to use an application and a data manager based on the security policy of the security context to set a use privilege for a second user to use the user application; and

providing, by the one or more processors, the user application to the second user based on the security policy of the security context by performing operations comprising:

Instantiating a user-defined function server within the security context;

instantiating an application engine of the user-defined function server within the security context;

instantiating the user application within the security context as an application of the application engine; and

the security policy based on the security context authorizes access to data by the user application.

3. A computer storage medium comprising instructions that, when executed by one or more processors of a machine, configure the machine to perform operations comprising:

authorizing a first user to access source code of a user application using an editor based on a security policy of a security context;

authorizing the first user to use an application and a data manager based on the security policy of the security context to set a use privilege for a second user to use the user application; and

providing the user application to the second user based on the security policy of the security context by performing operations comprising:

instantiating a user-defined function server within the security context;

instantiating an application engine of the user-defined function server within the security context;

Instantiating the user application within the security context as an application of the application engine; and

the security policy based on the security context authorizes access to data by the user application.