Patent Grant
11645423
Most applications today use access control rules to allow different users with different privileges, different access to the applications and their resources. Typically, the access controls are coded within an application's code base, which makes it very difficult to modify these controls statically, and impossible to modify them dynamically while the application is running.
Some embodiments provide API (Application Programming Interface) authorization platform that allows API-authorization policy stacks to be created and enforced. Policy stacks (called “stacks”) define API-authorization policies across different sets of managed resources in a workspace. Examples of a workspace in some embodiments include a software defined datacenter (SDDC), or several sets of resources deployed by an organization (entity) in one or more private and/or public cloud datacenters. Examples of managed resources sets in some embodiments include different Kubernetes clusters, different applications executing on one or more clusters, different distributed data storages, etc. Each set of managed resources is also referred to below as a managed system.
A stack in some embodiments defines a uniform set of one or more API-authorization policies for multiple different sets of resources so that the set of policies do not have to be specified independently for each set of resources. By instituting common policies across multiple managed resource sets (called managed systems below), stacks can be used to guarantee uniform baseline policies for the workspace. A stack is typically applied to several managed resources that share a common trait (e.g., share a particular type). The API-authorization platform of some embodiments allows an administrator to define the traits of the managed resources through labels (e.g., key value pairs) that are associated with the stacks and the managed systems. This platform in some embodiments also allows a stack to specify an exception for a managed system based on one or more features of the system that are expressed in a rich feature data structure of the system.
An administrator of a managed system in some embodiments can also specify API-authorization policies for the system. Such policies are referred to below as system level policies, or system policies. The system policies for a managed system implements specific logic for the system. However, in some embodiments, the system policies are subservient to the stack policies in order to ensure that the common policies specified by stacks are enforced for all applicable managed systems uniformly. In other words, assigning stacks with higher priority than system policies allows stacks to implement organizational supervision and enforcement. Stack and system policies in some embodiments have separate source control mechanisms to allow them to be stored in desired repositories (e.g., Git repositories) independently.
Workspace administrators can specify two or more policy stacks that might produce conflicting responses for an API call. In some embodiments, the API-authorization platform provides conflict resolution schemes for resolving such conflicts. For instance, in some embodiments, the platform allows stack policies to be specified with a priority level, such as low, medium or high. When two stack policies produce conflicting decisions for an API call (e.g., one specifies that the call should be rejected, while the other specifies that the call should be allowed), the stack policy with the higher priority wins. The conflict resolution process in some embodiments is performed by policy enforcing agents that execute in the same failure domain as the software resource to which the API call is directed.
The preceding Summary is intended to serve as a brief introduction to some embodiments of the invention. It is not meant to be an introduction or overview of all inventive subject matter disclosed in this document. The Detailed Description that follows and the Drawings that are referred to in the Detailed Description will further describe the embodiments described in the Summary as well as other embodiments. Accordingly, to understand all the embodiments described by this document, a full review of the Summary, Detailed Description, the Drawings and the Claims is needed. Moreover, the claimed subject matters are not to be limited by the illustrative details in the Summary, Detailed Description and the Drawings.
The novel features of the invention are set forth in the appended claims. However, for purposes of explanation, several embodiments of the invention are set forth in the following figures.
In the following detailed description of the invention, numerous details, examples, and embodiments of the invention are set forth and described. However, it will be clear and apparent to one skilled in the art that the invention is not limited to the embodiments set forth and that the invention may be practiced without some of the specific details and examples discussed.
Some embodiments provide API (Application Programming Interface) authorization platform that allows API-authorization policy stacks to be created and enforced. Policy stacks (called “stacks”) define API-authorization policies across different sets of managed resources in a workspace. The API-authorizing platform of some embodiments defines, distributes and enforces policy stacks for authorizing API calls to software resources executing on one or more sets of associated machines (e.g., virtual machines, containers, computers, etc.) in a workspace.
Examples of a workspace in some embodiments include a software defined datacenter (SDDC), or several sets of resources deployed by an organization (entity) in one or more private and/or public cloud datacenters. Examples of managed resources sets in some embodiments include different Kubernetes clusters, different applications executing on one or more clusters, different distributed data storages, etc. Each set of managed resources is also referred to below as a managed system. API authorization is distinct from API authentication in some embodiments. API authentication authenticates the identity of the API-call's source (e.g., validates the access credentials associated with the API call). API authorization, on the other hand, determines whether the API call is authorized (i.e., whether the operation associated with the API call should be performed).
A stack in some embodiments defines a uniform set of API-authorization policies for multiple different sets of resources so that the set of policies do not have to be specified independently for each set of resources. An API-authorization policy stack includes one or more API-authorization policies, with each policy including one or more rules.
By instituting common policies across multiple managed resource sets (called managed systems below), stacks can be used to guarantee uniform baseline policies for the workspace. A stack is typically applied to several managed resources that share a common trait (e.g., share a particular type). The API-authorization platform of some embodiments allows an administrator to define the traits of the managed resources through labels (e.g., key value pairs) that are associated with the stacks and the managed systems. This platform in some embodiments also allows a stack to specify an exception for a managed system based on one or more features of the system that are expressed in a rich feature data structure of the system.
Administrators of managed systems in some embodiments can also specify API-authorization policies for their respective systems. Such policies are referred to below as system level policies, or system policies. The system policies for a managed system implements specific logic for the system. However, in some embodiments, the system policies are subservient to the stack policies in order to ensure that the common policies specified by stacks are enforced for all applicable managed systems uniformly.
This example also shows each system governed by one, two or three sets of system policies, with one system policy 220 for the system 206, two system policies 222 for the system 202, and three system policies 224 for the system 204. As illustrated by
The following example illustrates how some embodiments utilize stacks. Consider a company (Ace) that maintains a collection of applications deployed on Kubernetes clusters in two regions: the US and the EU. Each region is subject to its own governmental regulations so even if an application is nominally the same in the US and the EU, it must be deployed with controls specific to the corresponding region. Irrespective of region, the company also implements PCI DSS in order to safeguard its financial transactions and user data. In addition, it defines a number of its own business rules with similar goals but supplemental guarantees important to the company.
Each cluster hosts many applications, and each application is deployed in phases to specific environments: dev, test, and prod. Each of these environments comes with slightly different business requirements. For example, the dev environment can only be accessed from within a shared private network while the prod environment provides selective access points for the public Internet so that the company's customers can reach their services. Finally, the individual Kubernetes clusters require authorization logic and other safeguards specific to their domains.
Considering the above, “stacks” can be established to fulfill most of these requirements so that individual Kubernetes clusters, operating environments, and applications do not need to repeatedly specify them. In addition, these requirements can be enforced across the Ace's organization with less risk of accidental (or even intentional) misconfiguration.
Each stack is responsible for a specific area of enforcement. Although a stack might take responsibility for multiple areas, it's conceptually simpler for each distinct area to be handled separately. Ace can implement policies for the following areas with each policy defined in a separate stack:
When the policies defined by stacks are combined with those defined by the individual clusters, many different rule sets are applicable to the EU and US Kubernetes clusters. These rule sets are:
From an associated software resource 315, a local agent 310 receives API-authorization requests to determine whether API calls received by the resource are authorized. In response to such a request, the local agent uses one or more parameters associated with the API call to identify a policy stored in its local policy storage to evaluate whether the API call should be authorized. To evaluate this policy, the agent might also retrieve one or more parameters from the local policy storage.
The local agent 310 then uses the received or retrieved parameters to evaluate the retrieved API-authorization policy in order to determine whether the API call should be approved or rejected. Based on this evaluation, the local agent then sends a reply to the application that sent the API-authorization request, to specify whether the API call should be approved or rejected. In some embodiments, the applications send the API-authorization requests as RPC (Remote Procedure Call) messages, and the local agents send their replies to these requests as RPC reply messages. In other embodiments, the applications send their API-authorization requests to the local agents through other mechanisms (such as other IPC (inter-process communication) messages) that initiate above the network stack.
A more specific example of the API-authorizing platform 300 of some embodiments is described in U.S. patent application Ser. No. 16/050,123, now issued as U.S. Pat. No. 11,496,517, which is incorporated herein by reference. This incorporated application describes a server set that distributes API policies and operands in a namespace. It also described augmenting the API operands (e.g., the parameters needed to process the specified policies) locally on the host computers and/or clusters that execute the applications that receive the API calls.
The two applications 400 and 500 are part of two different application clusters 420 and 425 that are managed by two different sets of administrative domains 430 and 435. The administrator domain 430 includes one or more administrators for the first cluster 420 that specify two sets of system API-authorization policies 450 and 452 for the applications in the first cluster 420, while the administrator domain 435 includes one or more administrators for the second cluster 425 that specify three sets of system API-authorization policies 554, 556 and 558 for the applications in the second cluster 425. Also, a set of one or more workspace administrators 415 specifies two policy stacks 460 and 562, both of which apply to the applications (such as application 500) of the second cluster 425, while only policy stack 460 applies to the applications (such as application 400) of the first cluster 420.
As shown, each application 400 or 500 directs its local agent 405 or 505 to determine whether the requested API call is authorized. Before using the local agents 405 and 505, the application 400 and 500 of some embodiments direct API-authentication agents (not shown) to authenticate the identities of the sources of the API calls (e.g., to validate the access credentials associated with the API calls). Only after the API-authentication agents authenticate the identities of the sources of the API calls, the applications 400 and 500 in some embodiments direct the local agents 405 and 505 to determine whether the API calls are authorized (i.e., whether the operation associated with the API call should be performed).
Each API-authorization agent 405 or 505 in some embodiments uses the system and stack policies associated with the application to evaluate whether application should process the API call as it is authorized. Specifically, in some embodiments, the agent 405 use the policy stack 460 and the system policy sets 450 and 452 to make its evaluation, while the agent 505 uses the policy stacks 460 and 562 and the system policy sets 554, 556 and 558 to make its evaluation. In
API authorization conflicts can arise when two policy stacks that are applicable to an API call produce conflicting results (e.g., authorized versus rejected), when a policy stack and a system policy that are applicable to the API call produce conflicting results, or when two applicable system policies produce conflicting results. In some embodiments, the local agents 405 and 505 identify all system and stack policies applicable to an API call, analyze each identified applicable system/stack policy, and then determine whether the policy is authorized or not based on this analysis.
When the analysis of two or more identified policies produces conflicting results, the local agent 405 or 505 uses a conflict resolver 470 or 570 that uses a set of conflict resolution rules to resolve the conflicting results. The conflict resolvers in some embodiments are part of the local agents even though they are shown as separate modules for purposes of the illustrations in
To address the case when two or more policy stacks (e.g., stacks 460 and 562) produce conflicting responses for an API call to a software resource (e.g., application 500) that is part of a managed set of resources (e.g., the application cluster 425) to which the stacks apply, the conflict resolution scheme of the API-authorization platform in some embodiments relies on priority levels that can be assigned to specific policies. Specifically, in some embodiments, the platform allows stack policies to be specified with a priority level, such as low, medium or high. When two stack policies produce conflicting decisions for an API call (e.g., one specifies that the call should be rejected, while the other specifies that the call should be allowed), the stack policy with the higher priority wins. Handling conflicts will be further described below.
As shown, the UI 700 has a sidebar that has includes a managed system section 705 and a stack section 710. It further shows the user selecting a stack addition control 720 through a cursor click operation. This selection directs the UI 700 to display a window 725 through which the user can name the stack. In this case, the user has named the stack Production. Also, the stack in this example has a type Kubernetes, which specifies that the stack generally relates to Kubernetes clusters. The stacks applicability to specific Kubernetes clusters is controlled by managed system labels and features, as further described below.
After naming the stack, the workspace administrator defines (at 610) one or more policies for the stack with each policy specified by reference to one or more rules. The specified policies will control whether a local agent evaluating the policy stack will reject or approve an API call. The features of the managed systems can be used (at 610) to define exceptions to one or more policies of a specified stack.
The Admission control 815, on the other hand, is for specifying the policies and rules of the stack. In
As mentioned above, and further discussed below, the acceptable features of a managed system in some embodiments have to be approved by a workspace administrator. In some such embodiments, a managed system administrator can request certain one or more features to be associated with the managed system, and the workspace administrator has to approve such a request. The features for a managed system are specified by a rich data structure that allows the system to be described at a very granular level, so that system and stack policies can be defined as being applicable or not applicable to the system by reference to these features.
After defining (at 610) one or more policies for the stack, the workspace administrator associates (at 615) the stack with one or more labels. In some embodiments, each label is specified by a key value pair. As mentioned above, the API-authorization platform of some embodiments allows a workspace administrator to define the traits of the managed systems through labels (e.g., key value pairs) that are also associated with the stacks. Hence, at 615, the process specifies one or more labels that are associated with the stack that is being defined. As described above, and further described below by reference to
The AAPP UI in some embodiments provides the selector controls 810 to allow the workspace administrator to specify one or more labels associated with the stack. In some embodiments, any managed system to which the stack applies needs to be associated with at least one label that is specified for the stack through the selector control 810. In other embodiments, any managed system to which the stack applies needs to be associated with all the labels that are specified for the stack through the selector control 810.
As shown in this example, the AAPI UI also provide exclusionary label section 1010, through which the workspace administrator can specify labels that are not applicable to the specified stack. When a managed system is associated with an excluded label, the stack is deemed not to apply to the managed system even if the system is associated with other inclusionary labels. In this example, no exclusionary labels have been specified for the Production stack.
Once a stack's selectors have been defined, managed systems can be associated with the stack by associating the systems with the matching label(s). Labels codify a system's functions (e.g., production), contracts (e.g., pci-compliant), lifecycle (e.g., release), and other characteristics so that related subsets of systems can be selected and managed together. By default, ever-managed system in some embodiments has a system-type label (e.g., “system-type”: “kubernetes”).
In some embodiments, the simplest selector is just a label (i.e., a key-value pair such as “environment”: {“production”}). Some embodiments, however, allows selectors to have additional expressivity. Each selector key in some embodiments corresponds to a list of values rather than a single string. Hence, more than one value can be matched per key (e.g., “environment” can be matched to “live” and “production”). Also, for a Boolean key, a value in some embodiments is not needed for the match since the mere presence of the key can be interpreted as True (e.g., “pci-compliant”: new set( )).
The policy-managing platform in some embodiments also allows values to be glob-matched. For instance, some embodiments allow the use of special glob characters (such as “?” or any another single character) and * (zero or more characters) to match substrings between separator characters (.,_, and -).
The selection of the label control 1110 directs the AAPI UI to display a label window 1100 that displays one or more label sections 1105. Each label section allows the workspace administrator to specify a label for the system. In Figure ii, two labels are associated with the buffalo system, and these two labels are:
After the stack has been defined, its policies and labels have been specified, the workspace administrator then publishes (at 620) the stack to the API authorization policy platform. This publication in turn directs the distribution modules of the server set 305 to distribute the stack to the local agents 310. In some embodiments, the server set 305 distributes all the stacks to all the local agents.
In other embodiments, the server set distributes to each local agent only the stacks that are relevant to that local agent. For these embodiments, the server set performs the process 1200 of
The server set then adds (at 1215) the stack to the distribution list of stacks to distribute to each local agent for each managed system that it identified as a system to which the stack applies. Next, at 1220, the server set determines whether it has examined all the stacks that it needs to distribute. If so, it distributes (at 1225) to each local agent the stacks on the distribution list of that local agent, and then ends. Otherwise, the server set returns to 1205 to identify another stack that it needs to distribute, and to perform the other operations 1210-1215 for this stack.
Next, at 1310, the process 1300 identifies one or more policy stacks and system policies that are applicable to the API call. In some embodiments, the process 1300 identifies the applicable stack and system policies by using one of our parameters associated with API call and/or the application that received API call. These parameters include the metadata associated with the application (e.g., the Kubernetes cluster associated with the application, the application type, etc.), the metadata associated with the API call (e.g., the type of request being made by the API call), and other dynamic data, such as a time of day for the API call.
One example of identifying potentially applicable stack and system policies for an API call is as follows. Assume that an application that is associated with a Kubernetes production cluster receives an API call. For such a call, the process 1300 identifies the stack policy specified for production Kubernetes clusters and any other system policies specified for such clusters in some embodiments.
After identifying the applicable stack and system policies, the process next processes (at 1315) these identified stack and system policies to determine whether any of the identified policies specify a particular resolution for the API call (i.e., specify whether the API call is authorized or not). Next, at 1320, the process determines whether multiple stack and system policies provided conflicting resolutions for the API call. If not, the process returns (at 1330) its resolution for the API call to the application (i.e., informs the application whether the API call is authorized or not) and then ends.
On the other hand, when the process determines (at 1320) that multiple stack and system policies provided conflicting resolutions for the API call, it uses (at 1325) its conflict resolver to identify the highest priority policy that specified a resolution for the API call, and to select the resolution provided by the identified highest priority policy as the resolution for the API call. From 1325, the process then transitions to 1330, where it returns its resolution for the API call to the application (i.e., informs the application whether the API call is authorized or not), and then ends.
To address conflicts arising from multiple different sets of policies provided by multiple different groups of administrators, some embodiments define decisions as structured objects so that they include the decision itself (e.g., allowed or not) along with metadata about the decision (e.g., a message explaining the rationale behind the decision), rather than just defining the decision as a reason string. For example, a rule implementation before stacks might look like this:
Instead of this approach, some embodiments define the rule:
enforce[decision] {
The outcomes of both rules in this example are the same, but the structured-object, second rule definition provides more information about the decision semantics. This additional information can be used to enhance the decision capabilities. For example, the decision's behavior can be altered to explicitly allow a condition (e.g., allowing all requests from a list of trusted superusers.)
When conflicts arise between decisions, the conflict resolvers (e.g., 470 or 570) of some embodiments use this metadata to choose the decision with the highest priority. The closer a decision is to the top of the following list, the higher its precedence.
1. Stack:
2. System:
In this example, stack decisions are higher priority than system decisions. Maximum priority decisions (decisions with priority==maximum) take precedence over decisions with no priority. Also, when two decisions are otherwise equal, deny beats allow in the above described conflict-resolution scheme.
As mentioned above, stack policies in some embodiments can provide exceptions for a specific system through the system's features module. This module allows a system administrator to define rich data that a stack can use in its policy implementations. For example, a Features module might include the following definition:
To use this in a stack rule, a system's features can be looked up using data.context.system_id as follows:
As mentioned above, some embodiments do not allow anyone to define labels and features in order to ensure that stacks serve as a reliable policy-enforcement mechanism. For instance, in some embodiments, the policy-managing platform only provide an administrator of the TENANT.ACMEpolicymanagingco.com the right to modify the Labels and Features modules. A system owner can have full control over the system but cannot modify any labels or features. A workspace administrator in some embodiments can add an owner to a system by adding the user's credentials (e.g., e-mail address) to the selected system.
Workspace modules include all stack modules and all the system features and labels modules. In some embodiments, system policy modules and workspace modules can be source controlled using Git. However, in some embodiments, the workspace source control is configured independently than system policy modules in order to maintain the separation of responsibility between stacks and systems.
The Git source control for the workspace can be set up by selecting the workspace and entering the Git credentials and other particulars in the Git Repository under Settings. For instance, the following sequence of operations are used in some embodiments to define the Git source control for the workspace:
1. Select the workspace from the inventory sidebar.
2. Click Settings.
3. Click Git Repository.
4. Enter your Git credentials and other particulars.
5. Click the Save changes button.
To implement stacks, the API-policy management platform of some embodiments provides the following resource types. A stack is a collection of settings and rules comparable to a system, but without a concrete target (e.g., a Kubernetes cluster) and intended to be applied across multiple systems that share a specific target type (e.g., Kubernetes) and function (e.g., production) or contract (e.g., PCI compliance). Stacks define a uniform set of rules that dependent systems follow so that these rules do not need to be specified repeatedly one system at a time. Also, in some embodiments, stacks make decisions with higher priority than their dependent systems so they can be used to implement organizational supervision and enforcement.
A selectors policy is a policy that allows a stack to discover its dependent systems (and exclude others) based on system labels. Each selector has a scope that is limited to one stack. One example of a selector policy is as follows:
A metadata policy is a workspace policy logically coupled to a system that describes the system so that it can be discovered and differentiated by stacks. There are two types of metadata policy in some embodiments: (1) labels, which codifies a system's functions (e.g., production) as well as its contracts (e.g., PCI compliance), and (2) features, which enumerates various kinds of exceptions that should be made when stacks apply rules to their dependent systems.
API metadata has a scope that is defined per system or stack. An example of an API metadata is as follows:
package metadata[“fd11aecfa3574794a490c68275373d2a”].api
type=“kubernetes”
A label has a scope of one system. An example of a label is as follows:
package metadata[“fd11aecfa3574794a490c68275373d2a”].labels
labels= {
}
A feature has a scope of one system. An example of a feature is as follows:
package metadata[“fd11aecfa3574794a490c68275373d2”].features
approved_proxies= {
}
ignore_missing_labels=true
A system owner is an authorization role giving users control over a system instance and its encapsulated policies. A system owner is distinct from a workspace administrator, which gives users control over an entire workspace, including stacks, systems, and metadata policies.
A workspace Git-Save is an API service that associates workspace resources (such as system metadata policies) with a remote Git repository for version control purposes. This API in some embodiments is congruent with the system feature of the same name.
A structured decision is a collection of well-defined key-value pairs intended to replace existing reason strings as the explanation for, and documentation of factors contributing to, a decision. This data is the basis for conflict resolution, logging, timeseries, and other fine-grained decision analysis. An example of a structured decision is as follows:
decision:= {
}
A default decision policy is a built-in policy statically provisioned for each enforced system policy. The default decision policy is responsible for connecting the selected system to its intended stacks, composing the stacks' decisions with the system's own decisions, resolving decision conflicts, and ultimately producing a single target-appropriate result. The default decision policy in some embodiments ensures that evaluation is performed relative to the target data namespace so that, for example, import statements and other references function as expected. In some embodiments, a default decision policy is provisioned once per system per enforced policy. An example of a default decision policy
A default decision mask policy is a built-in policy statically provisioned for each decision mask policy. The default decision mask policy is responsible for connecting the selected system to its intended stacks and combining the stacks' masked JSON paths with the system's own to produce a complete list of data that should be omitted from logged decisions. The default decision mask policy has a scope of one per system type.
}
A result integration policy is system/policy-specific (e.g., kubernetes.admission_control vs custom.rules) module used by the default decision policy to provide system/policy-appropriate conflict resolution, fail semantics, and result formatting. A result integration policy has a scope of one per system or policy type. An example of a result integration policy for Kubernetes admission control is as follows:
The following example of a default decision evaluation illustrates how the above-described resources are used conjunctively to enforce desired outcomes. Some embodiments use the procedure described below to compose policies from a selected system with zero or more policies from corresponding stacks to produce a final decision and a target-appropriate result object.
1. Evaluate: The complete set of evaluated rules is determined by:
2. Explain: Each rule must be a so-called partial set definition (not a complete definition), with hit (as opposed to missed) rules contributing to the resulting set a structured decision as follows:
3. Resolve: All passing rules are reconciled using either a conflict resolution algorithm described below or a custom algorithm defined by the selected system's corresponding result integration policy in order to produce an intermediate outcome object.
4. Interpolate: The selected system's corresponding result integration policy (based on system type) generates a target-appropriate result object from outcome, including a final allowed decision based on the target's desired fail semantics. The result must include an outcome key so that policy-managing platform's decision factors will be preserved in OPA's decisions log. It may be subsequently processed by an OPA plugin (e.g., Istio) to ensure a fully target-compatible response (e.g., by stripping the outcome key).
Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.
In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the invention. In some embodiments, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.
The bus 1405 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 1400. For instance, the bus 1405 communicatively connects the processing unit(s) 1410 with the read-only memory (ROM) 1430, the system memory 1425, and the permanent storage device 1435. From these various memory units, the processing unit(s) 1410 retrieve instructions to execute and data to process in order to execute the processes of the invention. The processing unit(s) may be a single processor or a multi-core processor in different embodiments.
The ROM 1430 stores static data and instructions that are needed by the processing unit(s) 1410 and other modules of the electronic system. The permanent storage device 1435, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 1400 is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 1435.
Other embodiments use a removable storage device (such as a floppy disk, flash drive, etc.) as the permanent storage device. Like the permanent storage device 1435, the system memory 1425 is a read-and-write memory device. However, unlike storage device 1435, the system memory is a volatile read-and-write memory, such a random access memory. The system memory stores some of the instructions and data that the processor needs at runtime. In some embodiments, the invention's processes are stored in the system memory 1425, the permanent storage device 1435, and/or the read-only memory 1430. From these various memory units, the processing unit(s) 1410 retrieve instructions to execute and data to process in order to execute the processes of some embodiments.
The bus 1405 also connects to the input and output devices 1440 and 1445. The input devices enable the user to communicate information and select commands to the electronic system. The input devices 1440 include alphanumeric keyboards and pointing devices (also called “cursor control devices”). The output devices 1445 display images generated by the electronic system. The output devices include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some embodiments include devices such as a touchscreen that function as both input and output devices.
Finally, as shown in
Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media may store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.
While the above discussion primarily refers to microprocessor or multi-core processors that execute software, some embodiments are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself.
As used in this specification, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification, the terms “computer readable medium,” “computer readable media,” and “machine readable medium” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral or transitory signals.
While the invention has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the invention can be embodied in other specific forms without departing from the spirit of the invention. For instance, a number of the figures conceptually illustrate processes. The specific operations of these processes may not be performed in the exact order shown and described. The specific operations may not be performed in one continuous series of operations, and different specific operations may be performed in different embodiments. Furthermore, the process could be implemented using several sub-processes, or as part of a larger macro process.
Also, several of the above-described embodiments have the local agents evaluate the policies based on the operands to determine whether to allow or reject API calls. In other embodiments, the local agents are implemented within the applications. For instance, some or all of the local agent functionality is embedded in a plugin that is installed in the API-processing application. In this manner, some or all of the above-described operations of the local agents are performed by plugins installed in the API-processing applications in some embodiments. In other embodiments, instead of implementing these operations with plugins, some embodiments have the local agent and/or server set update API rule configuration file of an API-processing application whenever the local namespace associated with the application is modified and this modification affects the application's processing of one or more API calls. Therefore, one of ordinary skill in the art would understand that the invention is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5974549 | Golan | Oct 1999 | A |
| 6985953 | Sandhu et al. | Jan 2006 | B1 |
| 7124192 | High, Jr. et al. | Oct 2006 | B2 |
| 7752661 | Hemsath et al. | Jul 2010 | B2 |
| 8266694 | Roy | Sep 2012 | B1 |
| 8613070 | Borzycki et al. | Dec 2013 | B1 |
| 8683560 | Brooker et al. | Mar 2014 | B1 |
| 8789138 | Reierson et al. | Jul 2014 | B2 |
| 9246986 | Ward, Jr. | Jan 2016 | B1 |
| 9397990 | Taly et al. | Jul 2016 | B1 |
| 9530020 | Brandwine | Dec 2016 | B2 |
| 9648040 | Morkel et al. | May 2017 | B1 |
| 10122757 | Kruse et al. | Nov 2018 | B1 |
| 10127393 | Ferraiolo | Nov 2018 | B2 |
| 10257184 | Mehta et al. | Apr 2019 | B1 |
| 10353726 | Duan | Jul 2019 | B2 |
| 10454975 | Mehr | Oct 2019 | B1 |
| 10469314 | Ennis, Jr. et al. | Nov 2019 | B2 |
| 10592302 | Hinrichs et al. | Mar 2020 | B1 |
| 10715514 | Threlkeld | Jul 2020 | B1 |
| 10719373 | Koponen et al. | Jul 2020 | B1 |
| 10789220 | Mayer et al. | Sep 2020 | B2 |
| 10984133 | Hinrichs et al. | Apr 2021 | B1 |
| 10986131 | Kruse et al. | Apr 2021 | B1 |
| 10990702 | Hinrichs et al. | Apr 2021 | B1 |
| 11023292 | Hinrichs et al. | Jun 2021 | B1 |
| 11080410 | Sandall et al. | Aug 2021 | B1 |
| 11108827 | Beckman et al. | Aug 2021 | B2 |
| 11108828 | Curtis et al. | Aug 2021 | B1 |
| 11170099 | Sandall et al. | Nov 2021 | B1 |
| 11245728 | Curtis et al. | Feb 2022 | B1 |
| 11258824 | Hinrichs et al. | Feb 2022 | B1 |
| 11327815 | Koponen et al. | May 2022 | B1 |
| 20040083367 | Garg et al. | Apr 2004 | A1 |
| 20070156670 | Lim | Jul 2007 | A1 |
| 20090063665 | Bagepalli et al. | Mar 2009 | A1 |
| 20090077618 | Pearce et al. | Mar 2009 | A1 |
| 20100333079 | Sverdlov et al. | Dec 2010 | A1 |
| 20110113484 | Zeuthen | May 2011 | A1 |
| 20120030354 | Razzaq et al. | Feb 2012 | A1 |
| 20120311672 | Connor et al. | Dec 2012 | A1 |
| 20120331539 | Matsugashita | Dec 2012 | A1 |
| 20130226970 | Weber et al. | Aug 2013 | A1 |
| 20140032691 | Barton et al. | Jan 2014 | A1 |
| 20140032759 | Barton et al. | Jan 2014 | A1 |
| 20140033267 | Aciicmez | Jan 2014 | A1 |
| 20140237594 | Thakadu et al. | Aug 2014 | A1 |
| 20150089575 | Vepa et al. | Mar 2015 | A1 |
| 20160057107 | Call et al. | Feb 2016 | A1 |
| 20170161120 | Sasaki et al. | Jun 2017 | A1 |
| 20170220370 | Klompje et al. | Aug 2017 | A1 |
| 20170237729 | Uppalapati | Aug 2017 | A1 |
| 20170346807 | Blasi | Nov 2017 | A1 |
| 20170364702 | Goldfarb et al. | Dec 2017 | A1 |
| 20180067790 | Chheda et al. | Mar 2018 | A1 |
| 20180082053 | Brown et al. | Mar 2018 | A1 |
| 20180109538 | Kumar et al. | Apr 2018 | A1 |
| 20180309746 | Blasi | Oct 2018 | A1 |
| 20190007418 | Cook et al. | Jan 2019 | A1 |
| 20190007443 | Cook et al. | Jan 2019 | A1 |
| 20190230130 | Beckman et al. | Jul 2019 | A1 |
| 20190245862 | Kruse et al. | Aug 2019 | A1 |
| 20190386973 | Patwardhan et al. | Dec 2019 | A1 |
| 20200007580 | Liderman et al. | Jan 2020 | A1 |
| 20210029029 | Mehmedagic et al. | Jan 2021 | A1 |
| 20210240550 | Hinrichs et al. | Aug 2021 | A1 |
| 20210248017 | Hinrichs et al. | Aug 2021 | A1 |
| 20210365571 | Sandall et al. | Nov 2021 | A1 |
| Entry |
|---|
| Non-Published commonly Owned U.S. Appl. No. 16/050,119, filed Jul. 31, 2018, 55 pages, Styra, Inc. |
| Non-Published commonly Owned U.S. Appl. No. 16/050,123, filed Jul. 31, 2018, 56 pages, Styra, Inc. |
| Non-Published commonly Owned U.S. Appl. No. 16/050,143, filed Jul. 31, 2018, 56 pages, Styra, Inc. |
| Non-Published commonly Owned U.S. Appl. No. 16/914,239 with similar specification, filed Jun. 26, 2020, 47 pages, Styra, Inc. |
| Non-Published commonly Owned U.S. Appl. No. 16/914,244 with similar specification, filed Jun. 26, 2020, 47 pages, Styra, Inc. |
| Author Unknown, “API Best Practices Managing the API Lifecycle: Design, Delivery, and Everything in Between,” Dec. 2016, 37 pages, Apigee, retrieved from https://pages.apigee.com/rs/351-WXY-166/images/API-Best-Practices-ebook-2016-12.pdf. |
| Costa, Jeff, “Improve API Performance with Caching,” API Gateway, May 3, 2018, 18 pages, Akamai Developer, retrieved from https://developer.akamai.com/blog/2018/05/31/improve-api-performance-caching. |
| Win, Thu Yein, et al., “Virtualization Security Combining Mandatory Access Control and Virtual Machine Introspection,” 2014 IEEE/ACM 7th International Conference on Utility and Cloud Computing, Dec. 8-11, 2014, IEEE, London, UK. |
| Moffett, Jonathan D., et al., “Policy Hierarchies for Distributed Systems Management,” IEEE Journal on Selected Areas in Communications, Dec. 1993, 11 pages, vol. 11, IEEE, USA. |
| Number | Date | Country | |
|---|---|---|---|
| 63036991 | Jun 2020 | US | |
| 62984291 | Mar 2020 | US |
