US11799859B2 - Automated authorization policy creation for interrelated services - Google Patents
Automated authorization policy creation for interrelated services Download PDFInfo
- Publication number
- US11799859B2 US11799859B2 US17/023,658 US202017023658A US11799859B2 US 11799859 B2 US11799859 B2 US 11799859B2 US 202017023658 A US202017023658 A US 202017023658A US 11799859 B2 US11799859 B2 US 11799859B2
- Authority
- US
- United States
- Prior art keywords
- service
- services
- request
- subset
- authorization policy
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active, expires
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
Definitions
- Interrelated services such as services in a service mesh
- an authorization management system that utilizes authorization polices to ensure that use of a service is authorized.
- authorization policies may limit which service can send a request to another service.
- the examples disclosed herein implement automated authorization policy creation for interrelated services.
- the examples eliminate a need for an in-depth understanding of the communications between interrelated services prior to establishing secure authorization policies, and eliminate the time-consuming and error-prone manual entry of potentially hundreds of authorization policies.
- a method in one example includes obtaining, by a computing device, a plurality of request records, each request record corresponding to a request sent from a sending service of a plurality of services to a receiving service of the plurality of services, and each request record identifying the sending service and the receiving service, wherein the plurality of services comprises a plurality of interrelated services.
- the method further includes determining a first subset of the request records wherein a service of the plurality of services sent a request to a first service.
- the method further includes determining a first subset of services based on the first subset of request records.
- the method further includes causing the generation of an authorization policy that permits requests to the first service from only those services in the first subset of services.
- a computing device in another example, includes a memory and a processor device coupled to the memory.
- the processor device is to obtain a plurality of request records, each request record corresponding to a request sent from a sending service of a plurality of services to a receiving service of the plurality of services, and each request record identifying the sending service and the receiving service, wherein the plurality of services comprises a plurality of interrelated services.
- the processor device is further to determine a first subset of the request records wherein a service of the plurality of services sent a request to a first service.
- the processor device is further to determine a first subset of services based on the first subset of request records.
- the processor device is further to cause the generation of an authorization policy that permits requests to the first service from only those services in the first subset of services.
- a non-transitory computer-readable storage medium includes executable instructions to cause a processor device to obtain a plurality of request records, each request record corresponding to a request sent from a sending service of a plurality of services to a receiving service of the plurality of services, and each request record identifying the sending service and the receiving service, wherein the plurality of services comprises a plurality of interrelated services.
- the instructions further cause the processor device to determine a first subset of the request records wherein a service of the plurality of services sent a request to a first service.
- the instructions further cause the processor device to determine a first subset of services based on the first subset of request records.
- the instructions further cause the processor device to cause the generation of an authorization policy that permits requests to the first service from only those services in the first subset of services.
- FIG. 1 is a block diagram of an environment in which examples of automated authorization policy creation for interrelated services may be practiced
- FIG. 2 is a flowchart of a method for automated authorization policy creation for interrelated services according to one example
- FIG. 3 is a block diagram of the environment illustrated in FIG. 1 after a new service has been added to the interrelated services;
- FIG. 4 is a simplified block diagram of the environment illustrated in FIG. 1 according to one example.
- FIG. 5 is a block diagram of a computing device suitable for implementing examples according to one example.
- Interrelated services such as services in a service mesh
- an authorization management system that utilizes authorization polices to ensure that use of a service is authorized.
- authorization policies may limit which service can send a request to another service. If a first service is not authorized to send a request to a second service, the authorization management system rejects the request.
- a complex application such as, by way of non-limiting example, a retailer's website, may comprise tens or even hundreds of interrelated services. Establishing the appropriate authorization policies for tens or hundreds of interrelated services requires knowledge of which services send requests to which other services, and requires establishment of corresponding authorization polices. This requires not only in-depth knowledge of the application, but can be very time-consuming, and, when the authorization polices are manually created, fraught with the potential for an inadvertent error that results in the complex application not operating correctly.
- New service mesh infrastructures such as, by way of non-limiting example, Istio (www.istio.io), offer many benefits for the development and operation of complex applications, which include, for example, enhanced security, enhanced visibility into communications between different parts of the application, automated load balancing, and increased network traffic statistics.
- Istio www.istio.io
- new service mesh architectures offer many benefits for the development and operation of complex applications, which include, for example, enhanced security, enhanced visibility into communications between different parts of the application, automated load balancing, and increased network traffic statistics.
- conventional complex applications are re-engineered into a plurality of interrelated services to take advantage of such new service mesh architectures, the need to generate authorization policies for a relatively large number of interrelated services increases.
- the examples disclosed herein implement automated authorization policy creation for interrelated services.
- the examples establish a trust period wherein interrelated services are permitted to send requests to other services.
- the requests are recorded in request records that identify that a request has been sent from a sending service to a receiving service. After the trust period ends, the request records generated during the trust period are analyzed to determine which services made requests of which other services.
- Authorization policies are automatically created based on the request records. An operator may analyze the authorization policies to revise, delete, or supplement them. After the authorization policies are generated, subsequent requests are rejected or accepted in accordance with the authorization policies.
- the examples eliminate a need for an in-depth understanding of the communications between interrelated services prior to establishing secure authorization policies, and eliminate the time-consuming and error-prone manual entry of potentially hundreds of authorization policies.
- FIG. 1 is a block diagram of an environment 10 in which examples of automated authorization policy creation for interrelated services may be practiced.
- the environment 10 includes a plurality of interrelated services 12 - 1 - 12 - 5 (generally, services 12 ) that implement a desired application, such as, by way of non-limiting example, an online retail store.
- the interrelated services 12 are, in this example, implemented in a service mesh 14 .
- the service mesh 14 is implemented via a service mesh infrastructure that may be used to provide certain infrastructure services to any service mesh, irrespective of the function of the service mesh.
- Istio www.istio.io
- the service mesh infrastructure includes components, referred to herein as service mesh functions (SMFs) that implement standardized network communications among each of the services 12 - 1 - 12 - 5 .
- each of services 12 - 1 - 12 - 5 includes an SMF 16 that handles network communications for the respective service 12 - 1 - 12 - 5 .
- the SMF 16 may be referred to as a “sidecar proxy container,” which is implemented via an Envoy proxy (www.envoyproxy.io).
- Each service 12 may receive messages from one or more other services 12 via the corresponding sidecar proxy container (e.g., SMF 16 ), and each service 12 may send messages to one or more other services 12 via the corresponding sidecar proxy container (e.g., SMF 16 ).
- the services 12 - 1 - 12 - 5 may be containers, and the service mesh infrastructure may automatically inject the SMF 16 into each of the services 12 - 1 - 12 - 5 .
- each of the services 12 - 1 - 12 - 5 may be implemented as a Kubernetes pod (kubernetes.io), and the service mesh infrastructure may automatically inject the SMF 16 into the Kubernetes pod as a separate container.
- the service mesh 14 may also include a telemetry system 18 that generates records that store traffic statistics and other information regarding communications between the services 12 .
- the records include a plurality of request records 20 - 1 - 20 - 6 , each of which corresponds to a request sent from a sending service 12 to a receiving service 12 .
- sending service 12 is used to refer to a service 12 that sends a request, sometimes referred to as a workload, to another service 12 .
- receiving service 12 refers to a service 12 that receives a request from a sending service 12 .
- Some or all of the services 12 may be both sending services 12 for some requests, and receiving services 12 for other requests.
- the telemetry system 18 While solely for purposes of illustration the telemetry system 18 is illustrated as a single component, in practice, the telemetry system 18 may be implemented as a distributed system, with telemetry components included in each SMF 16 . Moreover, while only request records 20 are illustrated, the telemetry system 18 may gather any number of different statistics relating to the service mesh 14 .
- the service mesh 14 also includes an authorization management system 22 that implements a security mechanism for the service mesh 14 .
- the authorization management system 22 may have a plurality of authorization policies 24 that govern communications between the services 12 .
- the authorization management system 22 may be implemented as a distributed system, with authorization management system 22 components included in each SMF 16 .
- the services 12 - 1 - 12 - 5 execute on computing devices that include a processor device and a memory.
- the services 12 - 1 - 12 - 5 may execute on separate computing devices, or some or all of the services 12 - 1 - 12 - 5 may execute on a same computing device.
- the service mesh 14 is implemented in a cloud computing environment.
- the communication of requests among the services 12 may be by any desired message-passing mechanism, including, by way of non-limiting example, the transmission of one or more packets from one service 12 to another service 12 , the transfer of information from one service 12 to another service 12 via variables, or any other inter-process communication mechanisms that facilitate the communication of information from one process to another process.
- the interrelated services 12 are typically not exposed to any services, including applications or processes, outside of the service mesh 14 .
- applications and processes outside of the service mesh 14 may only be aware of a gateway service 12 -G, which serves as a gateway into the service mesh 14 , and otherwise have no ability to communicate directly with any other service 12 .
- the environment 10 also includes a computing device 28 , which includes a hardware processor device 30 , a memory 32 , and a display device 34 .
- the memory 32 includes an authorization policy generator 36 which is configured to generate authorization policies 24 , as discussed in greater detail below.
- the memory 32 may also include configuration information 38 , which may be used by the authorization policy generator 36 to generate the authorization policies 24 . While solely for purposes of illustration the authorization policy generator 36 is illustrated as being separate from the authorization management system 22 , in some implementations the authorization policy generator 36 may be a component of, or otherwise integrated into, the authorization management system 22 .
- a trust stage begins.
- the authorization management system 22 does not inhibit any communications between the services 12 .
- the trust stage may have a duration for a period of time such as 1 minute, 5 minutes, 1 hour, 1 day, or the like.
- a timer may automatically be maintained by the authorization management system 22 , the authorization policy generator 36 , or may be manually maintained by an operator 40 .
- the services 12 operate during the trust stage and communicate with one another. In particular, some services 12 send requests to other services 12 . Each such request is recorded by the telemetry system 18 as a request record 20 .
- the operator 40 may control the duration of the trust stage.
- the authorization policy generator 36 accesses the request records 20 that were generated during the trust stage.
- the request records 20 may include a number of fields, such as a unique identifier (ID) field 42 - 1 that identifies a unique request record ID, a sending service field 42 - 2 that identifies a sending service 12 associated with a request, a receiving service field 42 - 3 that identifies a receiving service 12 associated with a request, a port number field 42 - 4 that identifies a port number of the receiving service 12 to which the sending service 12 sent the request, and a timestamp field 42 - 5 that identifies a timestamp of the time of the request.
- ID unique identifier
- the request records 20 comprise request records 20 - 1 - 20 - 6 .
- the authorization policy generator 36 accesses the request records 20 - 1 - 20 - 6 and, based on the timestamp field 42 - 5 , determines that the request records 20 - 1 - 20 - 6 were generated during the trust stage. For each of the services 12 , the authorization policy generator 36 determines the subset of request records 20 - 1 - 20 - 6 in which the service 12 is a receiving service 12 . The authorization policy generator 36 then determines the subset of services 12 of all the services 12 that are identified as sending services 12 in the subset of request records 20 - 1 - 20 - 6 .
- the authorization policy generator 36 then generates an authorization policy 24 that permits requests to the service 12 from only those services 12 identified as sending services 12 in the subset of request records 20 - 1 - 20 - 6 .
- the authorization policy 24 may be implemented via the generation of one or more authorization policy records 44 .
- the authorization policy generator 36 may analyze the request records 20 to determine if the service 12 - 1 is a receiving service for any requests.
- the authorization policy generator 36 identifies the request record 20 - 1 as the only request record 20 in which the service 12 - 1 is a receiving service.
- the authorization policy generator 36 determines, based on the sending service field 42 - 2 of the request record 20 - 1 , that the gateway service 12 -G was the sending service.
- the authorization policy generator 36 determines that the gateway service 12 -G sent the request to the service 12 - 1 addressed to a port P 1 of the service 12 - 1 .
- the authorization policy generator 36 accesses the configuration information 38 and determines that there are no particular restrictions identified for the service 12 - 1 .
- the authorization policy generator 36 generates an authorization policy 24 for the service 12 - 1 in the form of an authorization policy record 44 - 1 .
- each authorization policy record 44 - 1 - 44 - 6 includes three fields.
- a sending service field 46 - 1 identifies a sending service;
- a receiving service field 46 - 2 identifies a receiving service;
- a port number field 46 - 3 identifies a port number.
- the authorization policy record 44 - 1 thus authorizes requests to the service 12 - 1 only from the gateway service 12 -G, and only to port P 1 of the service 12 - 1 . Any requests sent to the service 12 - 1 from any service 12 other than the gateway service 12 -G will be rejected, and any request sent from the gateway service 12 -G to the service 12 - 1 to any port other than port P 1 will be rejected.
- the authorization policy generator 36 analyzes the request records 20 to determine if the service 12 - 2 is a receiving service for any requests. Based on the request record 20 - 2 , the authorization policy generator 36 generates an authorization policy 24 for the service 12 - 2 in the form of the authorization policy record 44 - 2 .
- the authorization policy record 44 - 2 authorizes requests to the service 12 - 2 only from the service 12 - 1 , and only to port P 1 of the service 12 - 2 . Any requests sent to the service 12 - 2 from any service 12 other than the service 12 - 1 will be rejected, and any request sent from the service 12 - 1 to the service 12 - 2 to any port other than port P 1 will be rejected.
- the authorization policy generator 36 analyzes the request records 20 to determine if the service 12 - 3 is a receiving service for any requests.
- the authorization policy generator 36 identifies the request records 20 - 3 and 20 - 6 as request records 20 in which the service 12 - 3 is a receiving service.
- the authorization policy generator 36 accesses the configuration information 38 and determines that there are no particular restrictions identified for the service 12 - 3 .
- the authorization policy generator 36 Based on the request records 20 - 3 and 20 - 6 , the authorization policy generator 36 generates an authorization policy 24 for the service 12 - 3 in the form of authorization policy records 44 - 3 and 44 - 4 .
- the authorization policy record 44 - 3 authorizes requests to the service 12 - 3 from the service 12 - 2 , and only to port P 1 of the service 12 - 3 .
- the authorization policy record 44 - 4 authorizes requests to the service 12 - 3 from the service 12 - 4 , and only to port P 2 of the service 12 - 3 . Any requests sent to the service 12 - 3 from any service 12 other than the services 12 - 2 and 12 - 4 will be rejected. Any request sent from the service 12 - 2 to the service 12 - 3 to any port other than port P 1 will be rejected, and any request sent from the service 12 - 4 to the service 12 - 3 to any port other than port P 2 will be rejected.
- the authorization policy generator 36 analyzes the request records 20 to determine if the service 12 - 4 is a receiving service for any requests, and generates an authorization policy 24 for the service 12 - 4 in the form of an authorization policy record 44 - 5 .
- the authorization policy generator 36 analyzes the request records 20 to determine if the service 12 - 5 is a receiving service for any requests.
- the authorization policy generator 36 identifies the request record 20 - 4 as a request record 20 in which the service 12 - 5 is a receiving service.
- the authorization policy generator 36 accesses the configuration information 38 and determines that there is a particular restriction identified for the service 12 - 5 .
- the configuration information 38 indicates that only requests to port P 2 of the service 12 - 5 from the service 12 - 3 are authorized.
- the authorization policy generator 36 Based on the configuration information 38 , the authorization policy generator 36 generates an authorization policy 24 for the service 12 - 5 in the form of an authorization policy record 44 - 6 .
- the authorization policy record 44 - 6 authorizes requests to the service 12 - 5 from the service 12 - 3 , but only to port P 2 of the service 12 - 5 . Any requests sent to the service 12 - 5 from any service 12 other than the service 12 - 3 will be rejected, and any subsequent request sent from the service 12 - 3 to the service 12 - 5 to any port other than port P 2 will be rejected.
- authorization policy generator 36 is a component of the computing device 28 , functionality implemented by the authorization policy generator 36 may be attributed to the computing device 28 generally. Moreover, in examples where the authorization policy generator 36 comprises software instructions that program the processor device 30 to carry out functionality discussed herein, functionality implemented by the authorization policy generator 36 may be attributed herein to the processor device 30 .
- the authorization management system 22 may use other attributes for authorization.
- the telemetry system 18 may be capable of capturing additional data relating to requests, such as a particular function of a receiving service 12 that a sending service 12 invokes.
- the authorization management system 22 may include in the authorization policies 24 a particular function that may be invoked by a sending service 12 , such that sending services 12 may only invoke the identified function of the receiving service 12 . Attempts to invoke any other function will result in a rejection by the authorization management system 22 .
- the telemetry system 18 may capture which particular HTTP request method (e.g., function) is invoked by a sending service 12 , such as an HTTP GET method, an HTTP PUT method, an HTTP HEAD method, an HTTP POST method, or the like.
- the authorization management system 22 may include in the authorization policies 24 the particular HTTP request method that may be invoked by a sending service 12 , such that sending services 12 may only invoke the identified particular HTTP request method of the receiving service 12 .
- FIG. 2 is a flowchart of a method for automated authorization policy creation for interrelated services according to one example.
- FIG. 2 will be discussed in conjunction with FIG. 1 .
- the computing device 28 obtains the plurality of request records 20 .
- Each request record 20 corresponds to a request sent from a sending service 12 of the plurality of services 12 to a receiving service 12 of the plurality of services 12 , and identifies the sending service 12 and the receiving service 12 .
- the plurality of services 12 comprises a plurality of interrelated services 12 ( FIG. 2 , block 1000 ).
- the computing device 28 determines a subset of the request records 20 wherein the service 12 - 1 sent a request to the service 12 - 2 ( FIG. 2 , block 1002 ).
- the subset of request records 20 comprises the request record 20 - 2 .
- the computing device 28 determines a subset of services 12 based on the subset of request records 20 ( FIG. 2 , block 1004 ).
- the subset of services 12 is the service 12 - 1 .
- the computing device 28 causes the generation of an authorization policy 24 that permits requests to the service 12 - 2 from only the service 12 - 1 in the subset of services 12 ( FIG. 2 , block 1006 ).
- the authorization policy 24 is in the form of the authorization policy record 44 - 2 .
- the term “causes” in this context refers to the computing device 28 directly generating an authorization policy 24 , or performing the necessary actions, such as communicating with the authorization management system 22 , to cause the authorization management system 22 to generate the authorization policy 24 .
- the computing device 28 determines a corresponding subset of the request records 20 wherein a service 12 sent a request to the respective service 12 . For each respective service 12 , the computing device 28 determines a subset of services 12 based on the corresponding subset of the request records 20 . The computing device 28 causes, for each respective service 12 , the generation of a corresponding authorization policy 24 that permits requests to the respective service 12 from only those services 12 in the corresponding subset of services 12 .
- FIG. 3 is a block diagram of the environment 10 after a new service 12 - 6 has been added to the interrelated services 12 .
- the authorization management system 22 and/or the authorization policy generator 36 may automatically recognize the addition of the new service 12 - 6 , or the operator 40 may interact with the authorization management system 22 and the authorization policy generator 36 to inform the authorization management system 22 and the authorization policy generator 36 that the new service 12 - 6 has been added to the interrelated services 12 .
- the authorization management system 22 begins a trust stage. The trust stage may be for all the services 12 , or only for the new service 12 - 6 . Thus, the authorization management system 22 may still enforce security except for communications with the service 12 - 6 .
- the trust stage may have a duration for a period of time such as 1 minute, 5 minutes, 1 hour, 1 day, or the like.
- a timer may automatically be maintained by the authorization management system 22 , the authorization policy generator 36 , or may be manually maintained by the operator 40 .
- the services 12 operate during the trust stage and communicate with one another, including the new service 12 - 6 . Each request is recorded by the telemetry system 18 as a request record 20 .
- the authorization policy generator 36 accesses the request records 20 that were generated during the trust stage.
- the request records 20 - 7 - 20 -N were generated.
- the authorization policy generator 36 accesses the request records 20 - 7 - 20 -N, and determines that a request record 20 - 8 is the subset of request records 20 wherein the service 12 - 6 received a request, and that the service 12 - 1 is the subset of services 12 that sent a request to the service 12 - 6 .
- the authorization policy generator 36 then generates an authorization policy 24 in the form of an authorization policy record 44 - 7 that permits requests to the service 12 - 6 from only the service 12 - 1 .
- the authorization policy generator 36 also analyzes the request records 20 - 7 - 20 -N to determine if any of the existing services 12 - 1 - 12 - 5 received a request from the new service 12 - 6 .
- the authorization policy generator 36 determines that the service 12 - 2 received a request from the new service 12 - 6 .
- the authorization policy generator 36 supplements the authorization policy 24 for the service 12 - 2 in the form of an authorization policy record 44 - 8 that permits requests to the service 12 - 2 from the service 12 - 6 .
- the authorization policy generator 36 may present, on the display device 34 , information to the operator 40 identifying the generation of the authorization policy records 44 - 7 and 44 - 8 .
- FIG. 4 is a simplified block diagram of the environment 10 according to one example.
- FIG. 4 includes the computing device 28 , which in turn includes the memory 32 and the processor device 30 coupled to the memory 32 .
- the processor device 30 is to obtain the plurality of request records 20 , each request record 20 corresponding to a request sent from a sending service 12 of the plurality of services 12 to a receiving service 12 of the plurality of services 12 .
- Each request record 20 identifies the sending service 12 and the receiving service 12 , and the plurality of services 12 comprises a plurality of interrelated services 12 .
- the processor device 30 is to determine a subset of the request records 20 wherein a service 12 of the plurality of services 12 sent a request to a first service 12 .
- the processor device 30 is to determine a subset of services 12 based on the subset of request records 20 .
- the processor device 30 is to cause the generation of an authorization policy 24 that permits requests to the first service 12 from only those services 12 in the subset of services 12 .
- FIG. 5 is a block diagram of the computing device 28 suitable for implementing examples according to one example.
- the computing device 28 may comprise any computing or electronic device capable of including firmware, hardware, and/or executing software instructions to implement the functionality described herein, such as a computer server, a desktop computing device, a laptop computing device, or the like.
- the computing device 28 includes the processor device 30 , the memory 32 , and a system bus 48 .
- the system bus 48 provides an interface for system components including, but not limited to, the memory 32 and the processor device 30 .
- the processor device 30 can be any commercially available or proprietary hardware processor device, such, by way of non-limiting example, an Intel®, AMD®, or IBM® hardware processor device.
- the system bus 48 may be any of several types of bus structures that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and/or a local bus using any of a variety of commercially available bus architectures.
- the memory 32 may include non-volatile memory 50 (e.g., read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.), and volatile memory 52 (e.g., random-access memory (RAM)).
- a basic input/output system (BIOS) 54 may be stored in the non-volatile memory 50 and can include the basic routines that help to transfer information between elements within the computing device 28 .
- the volatile memory 52 may also include a high-speed RAM, such as static RAM, for caching data.
- the computing device 28 may further include or be coupled to a non-transitory computer-readable storage medium such as a storage device 56 , which may comprise, for example, an internal or external hard disk drive (HDD) (e.g., enhanced integrated drive electronics (EIDE) or serial advanced technology attachment (SATA)), HDD (e.g., EIDE or SATA) for storage, flash memory, or the like.
- HDD enhanced integrated drive electronics
- SATA serial advanced technology attachment
- the storage device 56 and other drives associated with computer-readable media and computer-usable media may provide non-volatile storage of data, data structures, computer-executable instructions, and the like.
- a number of modules can be stored in the storage device 56 and in the volatile memory 52 , including an operating system and one or more program modules, such as the authorization policy generator 36 , which may implement the functionality described herein in whole or in part.
- All or a portion of the examples may be implemented as a computer program product 58 stored on a transitory or non-transitory computer-usable or computer-readable storage medium, such as the storage device 56 , which includes complex programming instructions, such as complex computer-readable program code, to cause the processor device 30 to carry out the steps described herein.
- the computer-readable program code can comprise software instructions for implementing the functionality of the examples described herein when executed on the processor device 30 .
- the processor device 30 in conjunction with the authorization policy generator 36 in the volatile memory 52 , may serve as a controller, or control system, for the computing device 28 that is to implement the functionality described herein.
- the operator 40 may also be able to enter one or more configuration commands through a keyboard, a pointing device such as a mouse (not illustrated), or a touch-sensitive surface such as a display device.
- Such input devices may be connected to the processor device 30 through an input device interface 60 that is coupled to the system bus 48 but can be connected by other interfaces such as a parallel port, an Institute of Electrical and Electronic Engineers (IEEE) 1394 serial port, a Universal Serial Bus (USB) port, an IR interface, and the like.
- the computing device 28 may also include a communications interface 62 , such as an Ethernet transceiver, or the like, suitable for communicating with other devices, as appropriate or desired.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Description
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/023,658 US11799859B2 (en) | 2020-09-17 | 2020-09-17 | Automated authorization policy creation for interrelated services |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/023,658 US11799859B2 (en) | 2020-09-17 | 2020-09-17 | Automated authorization policy creation for interrelated services |
Publications (2)
Publication Number | Publication Date |
---|---|
US20220086157A1 US20220086157A1 (en) | 2022-03-17 |
US11799859B2 true US11799859B2 (en) | 2023-10-24 |
Family
ID=80628080
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/023,658 Active 2041-01-30 US11799859B2 (en) | 2020-09-17 | 2020-09-17 | Automated authorization policy creation for interrelated services |
Country Status (1)
Country | Link |
---|---|
US (1) | US11799859B2 (en) |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070280107A1 (en) * | 2004-07-23 | 2007-12-06 | Reiner Ludwig | Data Unit Sender Control Method |
US20130031161A1 (en) * | 2011-07-26 | 2013-01-31 | Htc Corporation | Apparatuses and methods for unified virtual experience (uve) session control |
US9411955B2 (en) * | 2012-08-09 | 2016-08-09 | Qualcomm Incorporated | Server-side malware detection and classification |
US20170329957A1 (en) | 2016-05-11 | 2017-11-16 | Oracle International Corporation | Identity cloud service authorization model with dynamic roles and scopes |
US10075442B2 (en) | 2015-06-30 | 2018-09-11 | Vmware, Inc. | Methods and apparatus to grant access to cloud computing resources |
WO2019169405A1 (en) | 2018-03-02 | 2019-09-06 | Syntegrity Networks Inc. | Microservice architecture for identity and access management |
CN110554856A (en) | 2019-09-06 | 2019-12-10 | 航天科工广信智能技术有限公司 | Micro-service treatment system |
US10623390B1 (en) | 2017-08-24 | 2020-04-14 | Pivotal Software, Inc. | Sidecar-backed services for cloud computing platform |
US20200267155A1 (en) * | 2019-02-20 | 2020-08-20 | Twistlock Ltd. | System and method for securing application behavior in serverless computing |
US20210019194A1 (en) * | 2019-07-16 | 2021-01-21 | Cisco Technology, Inc. | Multi-cloud service mesh orchestration platform |
-
2020
- 2020-09-17 US US17/023,658 patent/US11799859B2/en active Active
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070280107A1 (en) * | 2004-07-23 | 2007-12-06 | Reiner Ludwig | Data Unit Sender Control Method |
US20130031161A1 (en) * | 2011-07-26 | 2013-01-31 | Htc Corporation | Apparatuses and methods for unified virtual experience (uve) session control |
US9411955B2 (en) * | 2012-08-09 | 2016-08-09 | Qualcomm Incorporated | Server-side malware detection and classification |
US10075442B2 (en) | 2015-06-30 | 2018-09-11 | Vmware, Inc. | Methods and apparatus to grant access to cloud computing resources |
US20170329957A1 (en) | 2016-05-11 | 2017-11-16 | Oracle International Corporation | Identity cloud service authorization model with dynamic roles and scopes |
US10623390B1 (en) | 2017-08-24 | 2020-04-14 | Pivotal Software, Inc. | Sidecar-backed services for cloud computing platform |
WO2019169405A1 (en) | 2018-03-02 | 2019-09-06 | Syntegrity Networks Inc. | Microservice architecture for identity and access management |
US20200267155A1 (en) * | 2019-02-20 | 2020-08-20 | Twistlock Ltd. | System and method for securing application behavior in serverless computing |
US20210019194A1 (en) * | 2019-07-16 | 2021-01-21 | Cisco Technology, Inc. | Multi-cloud service mesh orchestration platform |
CN110554856A (en) | 2019-09-06 | 2019-12-10 | 航天科工广信智能技术有限公司 | Micro-service treatment system |
Non-Patent Citations (3)
Title |
---|
Chugtu, Manish, "Demystifying Istio's Sidecar Injection Model," https://istio.io/latest/blog/2019/data-plane-setup/, Jan. 31, 2019, 10 pages. |
Hussain, Fatima, et al., "Intelligent Service Mesh Framework for API Security and Management," 2019 IEEE 10th Annual Information Technology, Electronics and Mobile Communication Conference (IEMCON), 2019, 8 pages. |
Vincken, Pieter, "ISTIO Service Mesh: Service to Service Communication," https://ordina-jworks github.io/cloud/2019/05/03/istio-service-mesh-s2s.html, May 3, 2019, 11 pages. |
Also Published As
Publication number | Publication date |
---|---|
US20220086157A1 (en) | 2022-03-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220174097A1 (en) | Autonomous monitoring of applications in a cloud environment | |
US10735429B2 (en) | Controlling user creation of data resources on a data processing platform | |
US9824196B2 (en) | Authenticating users requesting access to computing resources | |
EP3660717B1 (en) | Dynamic authorization of requested actions using adaptive context-based matching | |
US9111086B2 (en) | Secure management of user rights during accessing of external systems | |
EP3063648B1 (en) | Extensible framework for communicating over a fire wall with a software application regarding a user account | |
US10079832B1 (en) | Controlling user creation of data resources on a data processing platform | |
CN108351807B (en) | Event management to maintain control of restricted data in a cloud computing environment | |
US10601839B1 (en) | Security management application providing proxy for administrative privileges | |
US20220300587A1 (en) | Establishing access sessions | |
US20200387821A1 (en) | Authentication based on a change in a state of a qubit | |
US9237156B2 (en) | Systems and methods for administrating access in an on-demand computing environment | |
CN110162994A (en) | Authority control method, system, electronic equipment and computer readable storage medium | |
US10192262B2 (en) | System for periodically updating backings for resource requests | |
US9537893B2 (en) | Abstract evaluation of access control policies for efficient evaluation of constraints | |
CN113111339A (en) | Access control method, device, equipment and medium for application service | |
US20230262045A1 (en) | Secure management of a robotic process automation environment | |
US9027155B2 (en) | System for governing the disclosure of restricted data | |
US20240007458A1 (en) | Computer user credentialing and verification system | |
US20160344743A1 (en) | User Interface Driven Translation, Comparison, Unification, and Deployment of Device Neutral Network Security Policies | |
US11799859B2 (en) | Automated authorization policy creation for interrelated services | |
CN116170234B (en) | Single sign-on method and system based on virtual account authentication | |
CN112637129A (en) | Multi-node communication method, electronic device, storage medium and system in network isolation environment | |
US11032321B2 (en) | Secure performance monitoring of remote application servers | |
EP4364352A1 (en) | Virtual machine provisioning and directory service management |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: RED HAT, INC., NORTH CAROLINA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MASJUAN, XAVIER C.;REEL/FRAME:053801/0174 Effective date: 20200917 |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |