Role-based permission delegation in provider network

Abstract

Techniques for role-based permission delegation in a provider network. The techniques include an undertaking service in the provider network sending a request for a temporary credential service in the provider network to undertake a delegate role. The undertaking service, when playing the delegate role, sends a request for a temporary credential service to undertake the customer role according to a range reduction policy. The undertaking service performs an action in a subset of strict actions on a customer resource while playing the customer role. The techniques improve operation of the provider network by allowing permission granted by a customer to a delegated service in the provider network to perform an action on the customer resource to be delegated to the undertaking service while complying with minimum privileged access control principles.

Description

Technical Field

[0001] The present disclosure generally relates to systems and methods for managing identities and access to services and resources in a provider network. More specifically, the present disclosure relates to systems and methods for role-based permission delegation in a provider network. Background Art

[0002] Due to the development of computer technology and its increasing popularity, many individuals, companies, organizations, and other users increasingly use on-demand cloud computing platforms (equivalent to "provider networks") to build and host their computing applications and workloads. For example, public and private Internet network applications typically use provider network infrastructure to build and host. Currently, popular provider networks cover millions of servers globally that support hundreds of products and services, and users use these products and services to build and deploy their computing applications and workloads.

[0003] The services provided by provider networks to users are diverse. For example, services provided by a popular provider network include virtualization services (equivalent to "elastic computing services"), relational database services, data storage services, on-demand code execution services (equivalent to "serverless code execution services"), content delivery network (CDN) services, machine learning services, and other services. From the perspective of the provider network, users of the provider network are sometimes referred to as "customers".

[0004] Since provider networks support multiple customers on the same or shared infrastructure, identity and access management (IAM) is crucial. IAM uses centrally managed fine-grained permissions to control which users or which content can access services and resources in the provider network. IAM in provider networks typically works according to the principle of least privilege. According to this principle, an access entity should only be granted those permissions necessary to perform its intended function and should not be granted more (stronger) permissions. According to this principle, services in the provider network are not granted any permissions by default, or are only granted very limited permissions to access resources provisioned to customers in the provider network. Generally, a customer must grant a service permission to access a resource, and then the service can perform useful actions on the resource on behalf of the customer. Brief Description of the Drawings

[0005] Various examples in accordance with the present disclosure will be described with reference to the accompanying drawings, in which:

[0006] Figure 1 Illustrates an example of a system for role-based permission delegation in a provider network.

[0007] Figure 2 Illustrates an example of role linking.

[0008] Figure 3 The figure shows an example of a trust policy for a delegated role.

[0009] Figure 4 The figure shows an example of a permission policy for a delegated role.

[0010] Figure 5 The figure shows an example of a narrowing policy

[0011] Figure 6 The figure shows examples of trust and permission policies for a customer role.

[0012] Figure 7 The figure shows an example of a method for role - based permission delegation in a provider network.

[0013] Figure 8 The figure shows a provider network environment that can implement the techniques disclosed herein.

[0014] Figure 9 The figure shows an electronic device that can be used to implement the techniques disclosed herein.

[0015] It should be understood that, for simplicity or clarity of illustration, the elements shown in the figures are not necessarily drawn to scale. For example, for clarity, the dimensions of an element may be exaggerated relative to another element. Additionally, where considered appropriate, reference numerals have been repeated in the figures to indicate corresponding or similar elements. Detailed Description

[0016] The following description is not intended to limit the invention to the described examples, but to enable any person skilled in the art to make and use the invention.

[0017] 1. Overview

[0018] Aspects of the present disclosure provide systems and methods for role - based permission delegation in a provider network.

[0019] As Figure 1As shown, one aspect provides a system 100 for role-based permission delegation in a provider network 102. The system 100 includes the provider network 102 and, optionally, an intermediate network 148 and a remote electronic device 140. The provider network 102 includes a delegation service 104, an assume service 106, resources 108 supplied to customers (equivalent to "customer resources 108"), and an identity and access service 110 (equivalent to "IAM service 110"). The IAM service 110 includes customer accounts, delegation service accounts 116, assume service accounts 118, delegation roles 120, customer roles 128, and a scope-down policy 136. The delegation role 120 includes a trust policy 122 and a permission policy 124. The customer role 128 also includes its own trust policy 130 and permission policy 132. The permission policy 132 of the customer role 128 allows a set of actions 134 to be performed on the customer resources 108. The permission policy 124 of the delegation role 120 specifies conditions 126 regarding assuming the customer role 128. The conditions 126 regarding assuming the customer role 128 require compliance with the scope-down policy 136. The scope-down policy 136 limits the actions that are allowed to be performed on the customer resources 108 to a strict subset 138 of the set of actions 134 allowed by the permission policy 132 of the customer role 128. The optional remote electronic device 140 includes one or more of a command line interface (CLI) 142, a graphical user interface (GUI) 144, or a software development kit (SDK) 146.

[0020] Additionally, Figure 1 The system 100 depicted in and any of its components may include any other suitable components.

[0021] As Figure 1 As shown by the circles labeled S1, S2, and S3 in, one aspect provides a method for role-based permission delegation in a provider network 102. The method includes, at step S1, the assume service 106 sending a request to assume the delegation role 120 to a temporary credential service 112. The method further includes, at step S2, the assume service 106, acting as the delegation role 120, sending a request to assume the customer role 114 to the temporary credential service 112 according to the scope-down policy 136. The method further includes, at step S3, the assume service 106, acting as the customer role 114, performing actions in the strict action subset 138 on the customer resources 108.

[0022] The method may be executed in the system 100 or in any other suitable system.

[0023] The system and method improve the operation of the provider network 102 by allowing a permission granted by a customer to the delegated service 104 to perform an action on the customer resource 108 to be delegated to the assuming service 106, where the assuming service 106 can perform the action more efficiently (e.g., with lower latency, higher throughput, using fewer CPU or GPU clock cycles, or using less data storage device space), can perform the action with lower administrative or organizational costs (e.g., by reducing or avoiding software development costs), or can perform the action with higher security (e.g., by avoiding sharing authentication credentials or encryption keys). This delegation can be done while adhering to the principle of least privilege. Specifically, the system and method provide a mechanism to provide the benefits of improving the operation of the provider network 102, which allows the permission to perform a strict subset 138 of actions on the customer resource 108 to be delegated to the assuming service 106 without the assuming service 106 obtaining permission to perform all of the actions in the set of actions 134 on the customer resource 108, thus adhering to the principle of least privilege. Since the system and method can be used to ensure that the assuming service 106 receives permission to perform only the actions required to perform the tasks delegated to it, the system and method improve the operation of the provider network by reducing or eliminating actions that the assuming service 106 performs accidentally or deliberately that the assuming service 106 does not need to perform to perform the delegated tasks.

[0024] Additional aspects, applications, and advantages will become apparent from the following description and the related drawings.

[0025] 2. System

[0026] As Figure 1As shown, in one aspect, a system 100 for role - based permission delegation in a provider network 102 is provided. The system 100 includes the provider network 102 and optionally includes an intermediate network 148 and remote electronic devices 140. The provider network 102 includes a delegation service 104, an assumption service 106, resources 108 supplied to customers (equivalent to "customer resources 108"), and an identity and access service 110 (equivalent to "IAM service 110"). The IAM service 110 includes customer accounts, delegation service accounts 116, assumption service accounts 118, delegation roles 120, customer roles 128, and a scope - narrowing policy 136. The delegation role 120 contains a trust policy 122 and a permission policy 124. The customer role 128 also contains its own trust policy 130 and permission policy 132. The permission policy 132 of the customer role 128 allows a set of actions 134 to be performed on the customer resources 108. The permission policy 124 of the delegation role 120 specifies conditions 126 regarding assuming the customer role 128. The conditions 126 regarding assuming the customer role 128 require compliance with the scope - narrowing policy 136. The scope - narrowing policy 136 limits the actions that can be performed on the customer resources 108 to a strict subset 138 of the set of actions 134 allowed by the permission policy 132 of the customer role 128. The optional remote electronic devices 140 include one or more of a command - line interface (CLI) 142, a graphical user interface (GUI) 144, or a software development kit (SDK) 146.

[0027] In addition, Figure 1 The system 100 depicted in and any of its components can include any other suitable components.

[0028] The system 100 includes a provider network 102 that provides a computing environment enabling the techniques disclosed herein. The provider network 102 can be programmed or configured to comply with a cloud - computing model. The model enables ubiquitous, convenient, on - demand network access to a shared pool of configurable resources such as virtual machines, containers, networks, servers, storage, applications, services, or any other configurable resources of the provider network 102. Resources can be rapidly provisioned and released with minimal management effort or service - provider interaction.

[0029] Users of provider network 102 (sometimes referred to herein as "customers" of provider network 102) can automatically provision resources in provider network 102, such as virtual machines, containers, server time, network storage, or any other resources, with minimal or no human interaction with the service provider. The resources of provider network 102 can be obtained through an intermediate network 148 (e.g., the Internet) and accessed through standard mechanisms that facilitate the use of heterogeneous remote electronic devices (e.g., remote device 140), such as thin or fat client platforms or any other type of computing platform, such as desktop computers, mobile phones, tablet computers, laptop computers, workstation computers, smart appliances, Internet of Things (IoT) devices, or any other type of electronic device.

[0030] Resources in provider network 102, such as computing, storage, processing, memory, and network resources, are pooled to serve multiple customers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated according to customer needs. There is a sense of location independence because customers typically cannot control or know the exact location of the resources provided, but can specify a location at a higher level of abstraction (such as, for example, at the level of a country, state, data center, or any other location granularity). Provider network 102 can automatically control and optimize resource usage by leveraging metering capabilities (e.g., based on pay-per-use, based on usage charges, based on subscriptions, or any other fee basis) at an appropriate level of abstraction for the service type (such as computing, storage, processing, memory, network bandwidth, active customer accounts) or any other suitable level of abstraction. Monitor, control, and report resource usage in provider network 102 to provide transparency for both the providers and customers of the services being utilized.

[0031] Provider network 102 can offer its capabilities to customers according to a variety of different service models, including software as a service (SaaS), platform as a service (PaaS), infrastructure as a service (IaaS), or any other service model.

[0032] For SaaS, the provider network 102's software applications running on the infrastructure of the provider network 102 can be used to provide capabilities to customers. The application may be accessible from various remote electronic devices (e.g., remote device 140) through a thin client interface such as a command line interface (CLI) 142, a graphical user interface (GUI) 144 (e.g., via a web browser or a mobile or web application), a software development kit (SDK) 146, or any other interface. The infrastructure of the provider network 102 can include hardware resources such as servers, storage, and network resources, and software deployed on the hardware infrastructure to support the provided services. Generally, according to the SaaS model, except for limited customer-specific application configuration settings, the customer does not manage or control the underlying infrastructure, including the network, servers, operating systems, storage, or individual application capabilities.

[0033] For PaaS, customers are provided with the ability to deploy applications created or acquired by the customers onto the hardware and software infrastructure of the provider network 102 using programming languages, libraries, services, and tools supported by the provider network 102 or other sources. Generally, according to the PaaS model, the customer does not manage or control the underlying hardware and software infrastructure including the network, servers, operating systems, or storage, but can control the deployed applications and may control the configuration settings of the application hosting environment.

[0034] For IaaS, customers are provided with the ability to provision processing, storage, network, and other basic computing resources in which the customers can deploy and run any software, which can include operating systems and applications. The customer generally does not manage or control the underlying hardware and software infrastructure, but can control the operating systems, storage, and deployed applications, and may have limited control over the selection of network components (such as, for example, a host firewall).

[0035] The provider network 102 can provide its capabilities to customers according to various different deployment models, which include as a private cloud, as a community cloud, as a public cloud, as a hybrid cloud, or any other deployment model.

[0036] In a private cloud, the hardware and software infrastructure of the provider network 102 is provisioned for the exclusive use of a single organization that can include multiple customers. The private cloud is owned, managed, and operated by the organization, a third party, or some combination of them, and it can exist on-premises or off-premises.

[0037] In a community cloud, the hardware and software infrastructure of the provider network 102 is provisioned for the exclusive use of a specific community of customers in organizations that have common concerns (such as mission security requirements, policies, and compliance considerations). The community cloud can be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it can exist on-premises or off-premises.

[0038] In a public cloud, the infrastructure is provided for public use. The public cloud is owned, managed, and operated by a commercial, academic, or government organization, or some combination thereof. The public cloud can exist within the premises of a public cloud provider.

[0039] In a hybrid cloud, the infrastructure is a composition of two or more different cloud infrastructures (private, community, public, or any other cloud infrastructure) that remain as distinct entities but are bound together by standardized or proprietary technologies that enable data and application portability, such as, for example, cloud bursting for load balancing between clouds.

[0040] For the purposes of providing a clear example, Figure 1 FIG. depicts provider network 102 as including one delegated service, one assumed service, and one customer resource. However, provider network 102 in an actual implementation may include multiple delegated services, multiple assumed services, or multiple customer resources. Similarly, for the purposes of providing a clear example, Figure 1 FIG. depicts IAM service 110 as including only one delegated role, one customer role, one scope-down policy, one customer account, one delegated service account, and one assumed service account. However, IAM service 110 in an actual implementation may include multiple different components of any or all of these components. Similarly, system 100 may include multiple remote electronic devices, or multiple intermediate networks that connect the remote electronic devices to provider network 102. Thus, Figure 1

[0041] Delegated service 104 is a service in provider network 102 to which the customer grants permission to perform the set of actions 134 on customer resources 108, where the techniques disclosed herein are used to delegate permission to perform a strict subset 138 of those actions 134 on customer resources 108 to a assuming service 106. Here, the strict subset 138 is less than all of the actions 134 such that the assuming service 106 is not authorized to perform at least one of the actions 134 on customer resources 108, while the delegated service 104 is authorized to perform the actions on customer resources 108 based on the authorization of customer role 128. Through the role-based permission delegation disclosed herein, permission to perform a strict subset 138 of actions on customer resources 108 is delegated to the assuming service 106 in a way that does not require the customer to change the permission the customer granted to the delegated service 104 or to grant the assuming service 106 permission to perform the strict subset 138 of actions on resources 108. In fact, the customer may not be aware that the delegation is taking place. This provides greater flexibility to provider network 102 when delegating role-based permissions across services in provider network 102 and enables provider network 102 to perform tasks on behalf of its customers more efficiently, including providing any or all of the following benefits while adhering to the principle of least privilege: increased savings of the limited computing resources of provider network 102, where the assuming service 106 can perform actions on customer resources 108 more efficiently than the delegated service 104; reduced error rates of provider network 102 performing tasks on behalf of customers, where the assuming service 106 can perform actions on customer resources 108 more reliably than the delegated service 104; reduced development and maintenance costs for the operators of provider network 102, where the assuming service 106 has a pre-existing capability to perform actions on customer resources 106 while the delegated service 104 does not have such a capability or the capability has been deprecated, or any other realized benefit or technical effect.

[0042] Provider network 102 is constructed according to a service-oriented, network service, or microservices architecture. The architecture integrates distributed, separately maintained, and deployed services. A service is a discrete unit of software or hardware functionality provided by provider network 102 that can be accessed remotely (e.g., from a remote device 130 or from another service in provider network 102) and acts and updates independently of other services. For example, a service can have any or all of the following characteristics: logically represents a repeatable function with a specified result, self-contained, a "black box" from the perspective of a customer of provider network 102 in that the customer does not need to understand the implementation details of the service to obtain utility from the service, and is composed of other services in provider network 102.

[0043] A service - providing application programming interface (API) in the provider network 102, which allows remote access to the functions of a service in the following ways: (1) through other services in the provider network 102, where the services are connected to the service through an intermediate network in the provider network 102 (not shown in Figure 1 ), or (2) through a remote device (e.g., 130) connected to the provider network 102 by an intermediate network 148. The API contains a set of one or more data definitions and one or more network communication protocols for building and integrating services or devices. The API is a contract that represents an agreement between services or devices. According to this agreement, if one service or device sends a remote request to another service or device through an intermediate network constructed in a specific way, the other service or device will perform one or more specific actions and respond through the intermediate network in a specific way. For example, the API can be designed based on web standards, such as using the Hyper - Text Transfer Protocol (HTTP) or other suitable protocols to define the request message and provide the response message structure. The response message can be in the form of a machine - readable data format, such as Extensible Markup Language (XML), JavaScript Object Notation (JSON), or any other suitable machine - readable data format. Protocol specifications, such as Simple Object Access Protocol (SOAP), Representational State Transfer (REST), GraphQL, or any other suitable protocol specification, can be used to standardize the information exchange through the API. The API can contain webhooks (equivalent to "reverse APIs" or "push APIs"), which are HTTP - based callback functions that allow lightweight, event - driven communication between two APIs. Webhooks place the responsibility for communication on the service rather than the client. With webhooks, instead of the client sending an HTTP request to retrieve data, the server immediately sends a single HTTP POST request to the client when the data is available.

[0044] The above API standards and protocols are only examples of some possible standards and protocols that can be used to implement the API of the services in the provider network 102. Other standards or protocols can be used according to the requirements of the current specific service. The service API in the provider network 102 does not require any specific standard or protocol.

[0045] The provider network 102 provides various services to customers. Some possible services that the provider network 102 can offer include virtualization services, relational database services, data storage services, on - demand code - execution services, content delivery network (CDN) services, machine - learning services, and other possible services. The foregoing list of services is only an example of a set of services that the provider network 102 can offer. The provider network 102 can offer different services. There is no requirement for any specific service or set of services.

[0046] The function of the virtualization service is to allow customers to rent virtual computers to run their own computer applications. The virtualization service includes a network service through which customers can launch and configure virtual machines (equivalent to "instances") that contain and are configured with the required software. Using the network service, customers can create, start, or terminate instances as needed and pay for the active instances. This ability to create, start, and terminate instances as needed is sometimes referred to as "elastic" computing.

[0047] The relational database service is a distributed database service. The relational database service includes a network service whose function is to simplify the tasks of setting up, operating, and scaling a relational database for use by customer applications. For example, the relational database service can facilitate administrative processes such as patching database software, backing up the database, enabling point-in-time recovery, or any other appropriate relational database management tasks.

[0048] The data storage service provides data object storage through a network service interface. The data storage service can store any type of data object and manages the data using an object storage architecture that provides scalability, high availability, low-latency access, and high durability. The basic storage unit is an object organized into "buckets". Each object can be identified by a unique key and has a predetermined maximum size (e.g., five terabytes). Buckets can be remotely managed using a command-line interface (e.g., CLI142), a graphical user interface (e.g., 144), or a software development kit (e.g., SDK 146) (e.g., from a remote device 140).

[0049] On-demand code execution service is an event-driven serverless computing platform. The service executes software code in response to events and automatically manages the computing resources required for code execution. For example, the software code can be programmed in NODE.JS, PYTHON, JAVA, GO, RUBY, C#, or other suitable computer programming languages. The service executes the code as a temporary instance. For example, each temporary instance can be an operating system container (equivalent to "zone", "virtual private service", "partition", "virtual environment", "virtual kernel", or "jail"). Each instance can access a limited amount of random access memory (RAM) (e.g., RAM between 1,128MB and 10,240MB). Each instance is provided with a limited amount of temporary data storage (e.g., between 512MB and 10GB), which is only available during the instance's duration and whose data content will be discarded after the instance terminates. Each instance has a limited execution time (e.g., between 1 second and 900 seconds). During operation, a code package containing the code to be executed and the maximum compression size is created or uploaded in a data storage service. For example, the maximum compression size of the code package can be 50MB. The on-demand code execution service is instructed (through an API provided by the on-demand code execution service) to download the package from the data storage service and run the contained code in response to events. The on-demand code execution service can locally cache frequently run packages or code to avoid having to download them from the data storage service every time. Each instance runs in a new environment, such that there is no or only limited access to the execution context of previous and subsequent executions of the code. Therefore, each instance is stateless in nature, and the input data and output data are stored together with other services. For example, the input data or output data of an instance can be stored together with a data storage service or a relational database service.

[0050] Content Delivery Network (CDN) services provide a globally distributed network of proxy servers that cache content such as images, graphics, video, or audio data more locally to remote electronic devices of customers and users, thereby reducing the latency in accessing (downloading) the content.

[0051] The function of machine learning services is to enable users to create, train, and deploy machine learning models. Machine learning services operate at different levels of complexity when training and deploying machine learning models. For example, machine learning services can provide pre-trained machine learning models that can be deployed as-is, provide built-in machine learning algorithms that customers can use to train machine learning models, and provide managed instances of machine learning frameworks (e.g., TENSORFLOW or APACHE MXNET) that customers can use to create customer machine learning models.

[0052] The above services are only examples of the possible services that provider network 102 can offer. Provider network 102 can offer different services or offer similar services with different functions or different implementations. There is no requirement for a specific service, service function, or service implementation.

[0053] Delegated service 104 is a service in provider network 102. In the example discussed here, delegated service 104 is an event bus service. An event bus service is an event bus whose function is to allow client applications implemented in provider network 102 to receive, filter, transform, route, and deliver events. In operation, the event bus service receives events. For example, an event can indicate a change in the environment of provider network 102 and can be represented as a JSON object or the like. An event has a set of fields. For example, an event can have one or more fields, such as any of the following fields: "id", "detail-type", "source", "account", "time", "region", "resources", "detail", or any other suitable event field. The value of the "id" field provides a unique identifier for the event. The value of the "detail" field indicates the event type. The value of the "source" field identifies the service in provider network 102 that generated the event. The value of the "account" field identifies the customer account held by provider network 102 that is associated with the event. The value of the "time" field includes the timestamp (date and time) of the event (e.g., the time when the event occurred or was generated). The value of the "region" field identifies the geographical region of provider network 102 where the event occurred. The value of the "resources" field identifies one or more resources (e.g., virtual machine instances) in provider network 102 that the event pertains to. The value of the "detail" field contains a nested JSON object or the like that contains information about the event that is specific to the event type indicated by the value of the "detail-type" field or the value of the "source" field.

[0054] The above are just some examples of possible event fields. The events received by the event bus service can contain different fields. There is no requirement for any specific event or set of event fields.

[0055] After receiving an event, the event bus service applies rules to route the event to a target for further processing. For example, the definition of the rules and the selection of the target can be configured by the customer using the API of the event bus service. The target is a resource in the provider network 102, and when the event matches the rule, the event bus service sends the event to the resource. The rule defines the event structure and the fields for rule matching. For example, the rule can be a regular expression that matches or does not match one or more field names of the event or one or more values of one or more fields of the event (e.g., the value or values of the "source", "detail-type", or "detail" fields of the event). For example, when the event bus service receives an event indicating that a virtual machine instance changes from a pending state to a running state, the rule of the event bus service can send the event to an on-demand code execution service instance for further processing. In addition to or as an alternative to rules based on event patterns, the rules are based on a schedule that performs an action periodically. For example, the rule can trigger the execution of an on-demand code execution service instance periodically according to a schedule (e.g., according to a cron expression or a rate expression).

[0056] Although in the examples discussed herein, the delegation service 104 is an event bus service, the delegation service 104 and the present invention are generally not limited thereto. For example, the delegation service 104 can be a different type of service in the provider network 102 (e.g., a virtualization service, an on-demand code execution service, a relational database service, or other services in the provider network 102). The example of providing an event bus service is to provide a clear example, but the present invention is not intended to be limited to an implementation where the delegation service 104 is an event bus service. Depending on the requirements of the current specific implementation, the delegation service 104 can be a different type of service in the provider network 102.

[0057] Through the permission policy 132 of the customer persona 128 created by the customer, the delegation service 104 is granted permission by the customer to perform the set of actions 134 on the customer resources 108. For example, the customer resources 108 can be a message queue provisioned to the customer in the provider network 102. In this case, the permission policy 132 of the customer persona 128 can grant the delegation service 104 permission to perform certain actions on the customer resources 108, such as, for example, receiving and deleting messages from the message queue. This is only one example of the set of actions 134 that the permission policy 132 of the customer persona 128 can grant the delegation service 104 to perform on the customer resources 108. Permissions to perform different sets of actions are possible. No specific permissions or actions are required.

[0058] The permission to perform an action on the customer resource 108 granted in the permission policy 132 of the customer role 128 inherently includes the permission to perform any lesser action on the customer resource 108. For example, in the case where the customer resource 108 is a message queue, the permission to read a message from the message queue may inherently include the permission to poll the message queue for new messages. As another example, in the case where the customer resource 108 is a database table, the permission to write data to the database table may inherently include the permission to read data from the database table. In such a case, the granting of the permission to perform an action on the customer resource 108 in the permission policy 132 of the customer role 128 inherently includes the permission to perform any lesser action on the customer resource 108. What actions are considered lesser actions will vary depending on the action for which the permission is explicitly granted.

[0059] Alternatively, the permission to perform an action on the customer resource 108 that is granted does not inherently include the permission to perform lesser actions on the customer resource 108. In such a case, the permission policy 132 of the customer role 128 must grant the permission to perform any lesser actions. For example, in the case where the customer resource 108 is a message queue, the permission policy 132 of the customer role 128 may grant the delegate service 104 the permission to receive messages from the message queue, delete messages from the message queue, and poll the message queue for new messages.

[0060] Utilizing the permission from the customer to perform the set of actions 134 on the customer resource 108 via the permission policy 132 of the customer role 128, the delegate service 104 can perform those actions on the customer resource 108 on behalf of the customer. For example, in the case where the delegate service 104 is an event bus service, the delegate service 108 can poll the message queue for new messages, read messages from the queue, and delete messages from the queue.

[0061] However, one or more of the group actions 134 that the delegated service 104 has permission from the customer to perform on the customer resource 108 can be performed more efficiently by the assuming service 106. For example, an on-demand code execution service can perform the action of polling a message queue more efficiently than an event bus service due to its "serverless" nature. In such a case, it may be necessary to use the scheduling rules of the event bus service to periodically start an on-demand code execution service instance that polls the message queue for any available new messages. The output of the on-demand code execution service instance can indicate whether there are new messages available in the message queue based on the most recent poll. If there are new messages available, the event bus service can receive the output of the on-demand code execution service instance as an event. The event pattern rules of the event bus service can be used to match the event indicating that there are new messages available in the message queue. When such an event is matched, the event bus service can read the new messages from the message queue. With this separation of operations, the event bus service is relieved of the task of polling the message queue for new messages, which is performed more efficiently by the on-demand code execution service due to its serverless nature.

[0062] The above example of polling a message queue is only one example of a scenario where the delegated service 104 is granted permission by the customer to perform the group actions 134 on the customer resource 108, where one or more of the group actions 134 are performed more efficiently by the assuming service 106. Permission to perform other group actions can be granted by the customer to the delegated service 104, and different actions can be performed more efficiently by the assuming service 106 without a specific set of actions, delegated actions, or resources.

[0063] Computational efficiency is one reason for delegating the permission to perform an action to the assuming service 106. However, there can be other reasons in addition to or as an alternative to improving computational efficiency. For example, permission can be delegated for administrative or organizational reasons. For example, software developers on a team responsible for maintaining an on-demand code execution service may have developed code for polling a message queue to be executed as an on-demand code execution service instance, and there is currently no such equivalent functionality for the event bus service. In this example, delegating the permission to perform the action of polling the message queue to the on-demand code execution service may be more efficient (e.g., more cost-effective) administratively or organizationally because the programmed functionality already exists, while adding the polling functionality to the event bus service would require additional software development time and effort. Security is another reason for delegation. For example, the assuming service 106 can access the customer's encryption key required to perform a certain action on the customer resource 108. In such a case, the action can be delegated to the assuming service 106 instead of providing the delegated service 104 with additional access to the encryption key.

[0064] The above are just some examples of the reasons for delegating the permission to perform an action on the resource 108 to the assumed service 106. In addition to or in place of the above reasons, there may be other reasons for doing so. No special reason is required.

[0065] Services in the provider network 102 have identifiers (equivalent to "identities") that are referred to herein as "service principals". The service principals of services such as the delegated service 104 or the assumed service 106 take forms suitable for distinguishing one service in the provider network 102 from another. For example, a service principal can belong to a hierarchical namespace of service principals, which is similar to the hierarchical format of domain names in the domain name service. For example, the service principal of a service in the provider network 102 can have the following general format: " <service-name>.examplepn.com", where "examplepn.com" is an example of the top-level domain service domain name of the provider network 102 and <service-name> is a placeholder for the service name. For example, if the delegated service 104 is an event bus service, the service principal of the delegated service 104 can be "evtbussvc.examplepn.com", where "evtbussvc" is the name given to the event bus service. As another example, if the assumed service 106 is an on-demand code execution service, the service principal of the assumed service 106 can be "codeexecsvc.examplepn.com", where "codeexecsvc" is the name given to the on-demand code execution service.

[0066] The service principal of a service is alternatively or additionally a shortened name or alias that omits the common top-level part. For example, in the case where a group of services in the provider network 102 share the common top-level part of their respective service principals (such as "examplepn.com" in the previous examples), the effective service principal of a service can consist only of its service name (e.g., "evtbussvc" or "code execsvc") without having to use its fully qualified service principal (e.g., "evtbussvc.examplepn.com" or "codeexecsvc.examplepn.com"), where the common top-level part is implicit or explicit.

[0067] Hierarchical service principals allow for more fine-grained (akin to "nested") service principals. For example, a sub-service, component, or resource of a service can have a nested service principal that is nested within the service principal of the service. For example, a resource of an event bus service might have the service principal "pipes.evtbussvc.examplepn.com" or just "pipes.evtbussvc", which is nested within the service principal "evtbussvc.examplepn.com" or just "evtbussvc", which is the service principal of the event bus service. Nested service principals can be used to identify specific sub-services, components, or resources of a service, which are typically different from the service. This can be useful for, for example, granting permissions to perform actions on a resource only to specific sub-services, components, or resources of a service without having to grant permissions to the entire service.

[0068] The assumed service 106 is a service in the provider network 102 that obtains permission for a strict subset 138 of the set of actions 134 to be performed on the customer resource 108. The assumed service 106 uses role-based permissions to obtain permission to perform a strict subset of actions 134 on the customer resource 108.

[0069] An IAM role (or just "role") is an IAM identity (or just "identity") that exists within the IAM service 110, is associated with a customer account, and has specific permissions. In other words, a role is an identity that contains a permission policy that determines what the identity can and cannot do with the resources provisioned to the customer in the provider network 102. The customer role 128 and the delegated role 120 are two examples of roles.

[0070] A role can be assumed by a service in the provider network 102 that needs the role. For example, a service can assume a role to perform an action on a resource (e.g., resource 108) in the provider network 102 on behalf of a customer. A role does not have standard long-term credentials, such as a password or access key associated with it. Instead, when a service assumes a role, the temporary credential service 112 provides the service with temporary security credentials. A service assuming a role to perform an action on a resource provisioned to a customer in the provider network 102 is sometimes referred to in this document as a "service" role. A service role includes the permissions required for the service to access the resources needed to perform tasks on behalf of the customer in the provider network 102. For example, the customer role 128 can grant the delegated service 104 permission to perform the set of actions 134 on the customer resource 108. For example, in a case where the delegated service 104 is an event bus service and the customer resource 108 is a message queue provisioned to the customer, the permission policy 132 of the customer role 128 can grant the delegated service 104 permission to perform actions such as receiving messages from the message queue, deleting messages from the message queue, and polling the message queue for new messages.

[0071] A role has an identity that is referred to in this document as the "role" principal. The role principal uniquely identifies the role in string data format. The role principal of a role can be used to identify the role in a permission policy. For example, the role principal can take the data form of a Uniform Resource Name (URN), a Universally Unique Identifier (UUID), etc. However, the role principal does not require a specific data format. For example, the role principal can have the following general resource naming format:

[0072] "rn: <partition> : <service> : <region> : <account-id> : <resource-type> / <resource-id>”.

[0073] Here, "rn" stands for "resource name" and indicates that the following is the component resource name that identifies a resource in the provider network 102. <partition>A component refers to a partition of the provider network 102 where the resources are located. <service>Identify the service in provider network 102 to which the component belongs. Optional <region>Identify the geographical region of the provider network 102 where the resources are located. <account-id>A component is an identifier for a customer account that has a resource or to which a resource is provisioned. <resource-type>The type of component recognition resources. <resource-id>A component is an identifier of a resource.

[0074] For example, the role principal of customer role 128 can be the following resource name:

[0075] "rn:examplepn:iamsvc::111122223333:role / customer-role-1”.

[0076] In this example, <partition>is "examplepn", which refers to the provider network 102. <service>is "iamsvc", which refers to the IAM service 110 in the provider network 102. The region is not specified, and this indicated role principal can be used to identify the role in all regions of the provider network 102. Example <account-id>"111122223333” identifies the customer account 114 held by the provider network 102 through its account identifier. The customer account 114 has the customer role 128. <resource-type>is "role" and <resource-id>It is "customer-role-1".

[0077] The above role principal string data format is just one example of the possible string data formats that can be used to identify roles within the provider network 102. Additionally or alternatively, other string data formats can be used, including formats based on web standards such as the Uniform Resource Name (URN) standard (Request for Comments (RFC) 8141) or the Universally Unique Identifier (UUID) standard (RFC4122). No specific string data format is required and any string data format suitable for identifying roles managed by the IAM service 110 can be used.

[0078] A role has a trust policy. For example, both the customer role 128 and the delegated role 120 have trust policies 130 and 122 respectively. The trust policy of a role defines the principals that are trusted to assume the role. The trusted principals can be service principals. For example, the trust policy 130 of the customer role 128 can define that the delegated service 104 is trusted to assume the customer role 128. Examples of the trust policy 130 are provided herein. As another example, the trust policy 122 of the delegated role 120 can define that the assume service 106 is trusted to assume the delegated role 120. Examples of the trust policy 122 are provided herein.

[0079] A role has a permission policy. For example, both the customer role 128 and the delegated role 120 have permission policies 132 and 124 respectively. The permission policy of a role defines the actions and resources that the role can use. For example, the permission policy 132 of the customer role 128 can define that the customer role 128 is authorized to perform the set of actions 134 on the customer resource 108. For example, if the customer resource 108 is a message queue, the set of authorized actions can include reading new messages from the message queue, deleting messages from the message queue, and polling the message queue for new messages. Examples of the permission policy 132 of the customer role 128 are provided herein.

[0080] As another example, the permission policy 124 of the delegated role 120 can define that the delegated role 120 is authorized to perform a set of actions on any resource under a certain condition 126. The condition 126 actually requires the delegated role 120 to assume the customer role 114 with permission to perform a strict subset 138 of the set of actions defined by the scope narrowing policy 136. Examples of the permission policy 124 of the delegated role 120 are provided herein, including examples of the condition 126. Additionally, examples of the scope narrowing policy 136 are provided herein.

[0081] The assuming service 106 obtains permission to perform the actions (equivalent to "delegated actions") delegated to it through a role-linking process. Specifically, the delegated role 120 is used by the assuming service 106 to assume the customer role 114, but with a narrowed permission enforced by the condition 126 and the scope narrowing policy 136. The narrowed permission limits the actions or set of actions that the assuming service 106 acting as the customer role 128 can perform to a strict subset 138 of the group of actions 134. For example, the delegated role 120 may have permission to assume the customer role 114 subject to the condition 126. In this case, the assuming service 106 can first assume the delegated role 120. Then, using the temporary credentials of the delegated role 120, the assuming service 106 can assume the customer role 114 subject to the condition 126.

[0082] Figure 2 is an interaction diagram illustrating role-linking. At operation 240, the assuming service 106 sends a request to assume the delegated role 120 to the temporary credentials service 112. At operation 242, the temporary credentials service 112 returns the temporary security credentials of the delegated role 120 to the assuming service 106 in response to the assume role request of operation 240. Using the temporary security credentials of the delegated role 120, the assuming service 106 can act as the delegated role 120 (with its identity). At operation 244, the assuming service 106 uses the temporary security credentials of the delegated role 120 to make a request to the temporary credentials service 112 to assume the customer role 114 subject to the condition 126. To comply with the condition 126, when making the assume role request at operation 244, the assuming service 106 must request permission to perform only the actions or set of actions (equivalent to "delegated actions") permitted by the condition 126, where the permitted actions are those in the strict subset 138 of the group of actions 134 defined by the scope narrowing policy 136. At operation 246, the temporary credentials service 112 returns the temporary security credentials of the customer role 114 with the narrowed permission to the assuming service 106 in response to the assume role request of operation 244. Using the temporary security credentials of the customer role 114 with the narrowed permission, the assuming service 106 can act as the customer role 114 (with its identity), but with permission to perform only the strict subset 138 of actions on the customer resources 108 and not all actions 134 on the customer resources 108. At operation 248, the assuming service 106 performs the delegated actions in the strict subset 138 on the resources 108.

[0083] As a specific example, assume that customer resource 108 is a message queue. The permission policy 132 of customer role 128 can grant the delegated service 104 the permission to perform read, delete, and poll actions on the message queue. The trust policy 122 of delegated role 120 can grant the assuming service 106 the permission to assume delegated role 120. The permission policy 124 including the condition 126 of delegated role 120 can authorize delegated role 120 to assume customer role 114, but only has the right to perform poll actions on the message queue and has no right to perform read or delete operations on the message queue. In this case, after successfully assuming delegated role 120 at operation 242 and thus receiving the temporary security credentials, the assuming service 106 acting as delegated role 120 can assume customer role 114 only if the assume role request at operation 244 requests the permission to perform poll actions on the message queue and does not request the permission to perform read or delete actions on the message queue.

[0084] Although in the examples discussed herein, the assuming service 106 is an on-demand code execution service, the assuming service 106 and the present invention are generally not limited thereto. For example, the assuming service 106 can be different types of services in the provider network 102 (e.g., virtualization services, relational database services, etc.). The example of providing an on-demand code execution service is to provide a clear example, but the present invention is not intended to be limited to the implementation where the assuming service 106 is an on-demand code execution service. Depending on the requirements of the current specific implementation, the assuming service 106 can be different types of services in the provider network 102.

[0085] Customer resource 108 is an object existing in the services of provider network 102. For example, customer resource 108 can be a message queue existing in the message queuing service of provider network 102. However, customer resource 108 is not limited to any specific resource or any specific type of resource. The service containing customer resource 108 defines the possible actions that can be performed on customer resource 108. For example, the message queuing service can support any or all of the following actions on the message queue: creating a message queue, deleting a message from the message queue, polling the message queue for new messages, receiving a message from the message queue, delivering (sending) a message to the message queue, or any other suitable message queue actions. However, the service does not need to support any specific action or set of actions on the resource. And the action or actions on the resource supported by the service can vary between different resource types and different services.

[0086] Customer resource 108 can be an object that can be protected by the IAM service 110 within the service. In order to be protected by the IAM service 110, the customer resource 108 has an identity that is referred to herein as the "resource" principal. Similar to the service principal and role principal discussed above, the resource principal is a string data type that uniquely identifies a resource in the provider network 102. For example, the resource can take the form of data such as a Uniform Resource Name (URN), a Universally Unique Identifier (UUID), etc. However, the resource principal does not require a specific data format.

[0087] For example, the resource principal can have the following general resource naming format:

[0088] "rn: <partition> : <service> : <region> : <account-id> : <resource-type> / <resource-id>".

[0089] The above general resource name format is discussed in more detail in the previous discussion about the role subject.

[0090] For example, the resource body of customer resource 108 can be:

[0091] "rn:examplepn:qsvc:us-west-1:111122223333:queue / some-queue-1".

[0092] In this example, <partition>is "examplepn", which refers to provider network 102. <service>is "qsvc", which refers to the message queuing service in the provider network 102. The region is "us-west-1", which indicates that the resource 108 is located in the northern California geographical region of the western United States of the provider network 102. Example <account-id>"111122223333” identifies customer account 114 held by provider network 102 through its account identifier. Resource 108 is supplied to that customer account 114. <resource-type>is "queue" and <resource-id>It is "some-queue-1".

[0093] The above resource principal string data format is just one example of the possible string data formats that can be used to identify resources in the provider network 102. Additionally or alternatively, other string data formats can be used, including formats based on web standards such as the Uniform Resource Name (URN) standard (Request for Comments (RFC) 8141) or the Universally Unique Identifier (UUID) standard (RFC4122). No specific string data format is required, and any string data format suitable for identifying resources in the provider network 102 can be used.

[0094] Although in the examples discussed herein, the customer resource 108 is a message queue of the message queuing service in the provider network 102, the customer resource 108 and the present invention are generally not limited thereto. For example, the customer resource 108 can be different types of resources belonging to different services in the provider network 102. For example, the customer resource 108 can be a database table of the database management service in the provider network 102. As other examples, the customer resource 108 can be a virtual machine instance of the virtualization service in the provider network 102, or the customer resource 108 can be a data object stored by the data storage service in the provider network 102. The example of providing a message queue is for providing a clear example, but this does not mean that the present invention is limited to the implementation where the customer resource 108 is a message queue. And, depending on the requirements of the current specific implementation, the customer resource 108 can be different types of resources in the provider network 102.

[0095] The function of the IAM service 110 is to securely control access to resources in the provider network 102 by authorizing the "request" principal to perform actions on the resources in the provider network 102. The request principal can include, but is not limited to, role principals. When a "request" service (e.g., the commitment service 106) in the provider network 102 sends a request (e.g., an HTTP or HTTP request) to perform an action on a resource (e.g., resource 108) to a "target" service (e.g., a service that provides access to the customer resource 108) in the provider network 102, the IAM service 110 evaluates and authorizes the request based on the request context of the request. The request context can contain data specifying any one or all of the following: the request operation to be performed, the requested resource, the request principal (e.g., role principal), environmental data (e.g., information about the network address, user agent, SSL enabled status, or the current date / time associated with the request service that sends the request), resource data (e.g., data related to the requested resource, such as the database table name or the identifier of the virtual machine instance), or any other suitable request context data.

[0096] If the requesting service has successfully assumed a role (e.g., delegated role 120), the requesting service obtains temporary security credentials for the assumed role from the IAM service 110. For example, the temporary security credentials can include an access key identifier that identifies the temporary security credentials, an expiration of the date / time when the temporary security credentials expire, a secret access key that can be used to cryptographically sign requests as the role principal, and a session token that the requesting service passes to the target service to use the temporary security credentials. The request context of the request of the requesting service can include the session token of the temporary security credentials. Additionally or alternatively, the request or request context is cryptographically signed using the secret access key of the temporary security credentials.

[0097] For authorization, the IAM service 110 uses values from the request context to check any policies applicable to the request. Then, the IAM service 110 uses the applicable policies to determine whether to allow or deny the request. The policies are stored with the IAM service 110 in a machine-readable format. For example, the machine-readable format can be JavaScript Object Notation (JSON), Extensible Markup Language (XML), etc. According to the principle of least privilege, the IAM service 110 generally defaults to denying requests, and an allow permission in a policy can override the default denial. If multiple policies apply to a request and one policy denies the request while another policy allows the request, the denial will override the allow and the request will be denied by the IAM service 110. The trust policy 130, permission policy 134, trust policy 122, and permission policy 124 are examples of policies and are discussed in more detail below.

[0098] 2.6 Temporary Credential Service

[0099] The temporary credential service 112 of the IAM service 110 provides an API that allows services in the provider network 102 (e.g., the assuming service 106) to assume roles. To assume a role, the assuming service 106 makes an assume role request to the temporary credential service 112. If the assume role request is successful, the temporary credential service 112 returns the temporary security credentials for the assumed role.

[0100] The assume role request accepts many request parameters, including the "role session duration" parameter, the "role identifier" parameter, and other possible parameters. The role session duration parameter specifies the duration (e.g., in seconds) of the validity of the temporary security credentials returned by the temporary credentials service 112 for the assumed role. If no value is provided for the role session duration parameter in the assume role request, the temporary credentials service 112 uses a default duration (e.g., 3600 seconds) when generating the temporary security credentials to return to the requesting service. The shortest allowed duration (e.g., 900 seconds) and the longest allowed duration (e.g., 432000 seconds) limit the possible values of the role session duration parameter. After the validity period has passed, the requesting service can no longer use the temporary security credentials to perform actions for the assumed role. The requesting service must make a new assume role request to the temporary credentials service 112 to obtain a new set of temporary security credentials for the assumed role with an updated validity period. The role identifier parameter specifies the role principal of the role to be assumed.

[0101] When the assume service 106 makes an assume role request, the assume service 106 can specify a set of session tags. Session tags are key-value pairs. In addition, when the assume service 106 makes an assume role request, the assume service 106 encrypts and signs the request using a secret encryption key representing the identity of the assume service 106. For example, the assume service 106 can sign the assume role request using the secret key associated with the assume service account 118. By doing so, the temporary credentials service 112 verifies the assume role request and determines that the assume role request was made by the assume service account 118.

[0102] The assume role request signed by the assume service 106 includes one or more session tags. The temporary credentials service 112 evaluates the policy based on the session tags in the assume role request. When the assume service 106 makes an assume role request for assuming the delegated role 120, the assume service 106 specifies at least two session tags in the assume role request. One session tag has a key named "AssumableCutomterRoleRn". Another tag has a key named "SourceRn". These key names are only examples of possible session tag names, and other names can be used.

[0103] The value of the "AssumableCustomerRoleRn" session tag must be the role principal that assumes the role that Service 106 requests to assume. For example, the value of "AssumableCustomerRoleRn" can be the role principal of Customer Role 128. The purpose of this session tag is to enable the Temporary Credential Service 112 to enforce the following objective: Service 106 assumes Delegated Role 120 solely for the purpose of assuming Customer Role 128 and not for any other role.

[0104] The value of the "SourceRn" session tag must be the resource principal of the resource of the resource type for which Service 106 is facilitating work. For example, the value of the "SourceRn" session tag can be the resource principal of the resource of Delegation Service 104. The purpose of requiring this session tag is to mitigate confused deputy. A confused deputy is a security problem where an entity without the right to perform an action can force a more privileged entity to perform the said action.

[0105] Figure 3 is an example of the trust policy 122 of Delegation 120. When Service 106 acting as the Assuming Service Account 118 makes a request to the Temporary Credential Service 112 to assume Delegated Role 120, the Temporary Credential Service 112 evaluates the trust policy 112. The trust policy 122 is defined in JSON format, but other machine-readable formats (e.g., XML) can also be used. Line numbers (e.g., "07") are used for reference in Figure 1 but are not part of the trust policy 122. Overall, the trust policy 122 grants (allows) Service 106 (lines 02 to 04) permission (line 01) to perform a set of actions (lines 05 to 08) under certain conditions (lines 09 to 16). In this example, Service 106 is an on-demand code execution service. The service principal of the on-demand code execution service is used at line 03 to specify the service (e.g., Service 106) to which the permission is granted by the trust policy 122. The set of actions at lines 05 to 08 includes permission to perform assume role actions and permission to perform label session actions. The label session action permission allows Service 106 to specify session tags in an assume role request, such as the "AssumableCustomerRoleRn" session tag and the "SourceRn" session tag.

[0106] The conditions at lines 09 to 16 define two sub - conditions. According to the implicit logical AND operator for the two sub - conditions, both sub - conditions must be satisfied for the overall condition to be satisfied. The first sub - condition at lines 10 to 12 requires that the assuming service 106 specify a value for the "AssumableCustomerRoleRn" session label, where the value matches the string expression pattern specified in the first sub - condition (where the asterisk character ('*') is used as a wildcard match). Specifically, when assuming the delegated role 120, the first sub - condition requires that the assuming service 106 provide, in the role - assuming request, a value for the "AssumableCustomerRoleRn" session label that matches the role - principal pattern. This serves only the goal of the assuming service 106 assuming the delegated role 120, that is, assuming the role identified by the value of the "AssumableCustomerRoleRn" session label (e.g., customer role 128), and not assuming other roles. The second sub - condition at lines 13 to 15 requires that the assuming service 106 specify a value for the "SourceRn" session label, where the value matches the string expression (with the asterisk character ('*') used as a wildcard match) specified in the second sub - condition. Specifically, when assuming the delegated role 120, the second sub - condition requires that the assuming service 106 provide, in the role - assuming request, a value that matches the pattern of the resource principal of the resource type for which the assuming service 106 is facilitating work. The purpose of requiring this session label is to mitigate confusion agents. A confusion agent is a security issue where an entity without the right to perform an action can force a more privileged entity to perform the action. In Figure 3 In the example trust policy 122 of

[0107] The assume service 106 initially acts in the identity of the assume service account 118. Then, the assume service 106 requests the temporary credential service 112 to assume the delegated role 120. In doing so, the assume service 106 specifies the values of the "AssumableCustomerRoleRn” session label and the "Source Rn” session label. For example, the value of the "AssumableCustomerRoleRn” session label can be the role principal of the customer role 128, and the value of the "SourceRn” session label can be the resource principal of the resource of the delegation service 104. Upon receiving the assume role request, the temporary credential service 112 verifies whether the values of the "AssumableCustomerRoleRn” and "SourceRn” session labels meet the conditions of the trust policy 122 of the delegated role 120. If they are met, the temporary credential service 112 returns a temporary security credential that allows the assume service 106 to assume the delegated role 120. For example, the temporary security credential can allow the assume service 106 to perform assume role and label session actions when assuming the delegated role 120 (with its identity). Note that if the assume service 106 does not specify valid values for the "AssumableCustomerRole Rn” and "SourceRn” session labels when requesting to assume the delegated role 120, the conditions of the trust policy 122 of the delegated role 120 are not met, and the temporary credential service 112 will not return a valid temporary security credential to the assume service 106 for assuming the delegated role 120.

[0108] Next, if the assume service 106 has successfully assumed the delegated role 120, the assume service 106 can continue to assume the customer role 128 according to the conditions 126 of the permission policy 124 of the delegated role 120. Figure 4 Is an example of the permission 124 of the delegated role 120 evaluated by the temporary credential service 112 when the assume service 106 acting in the identity of the delegated role 120 requests to assume the customer role 128. Generally speaking, the permission policy 124 allows (line 01) a set of actions (lines 02 to 05) to be performed on any resource (line 06) under the conditions 126 (lines 07 to 18). In this example, the set of actions at lines 02 to 05 includes the permission to perform the assume role action and the permission to perform the label session action. The permission to perform the assume role action allows the assume service 106 acting in the delegated role to make an assume role request to the temporary credential service 112 to assume the customer role 128. The permission to perform the label session action allows the assume service 106 to specify one or more session labels when making a request to assume the customer role 128.

[0109] Condition 126 is actually the condition for the assuming service 106, while playing the delegated role 120, to assume the customer role 128. Condition 126 has sub - conditions that are joined together by the logical "AND" to form the overall condition 126. In other words, all sub - conditions must be satisfied for condition 126 to be satisfied.

[0110] The first sub - condition, at lines 08 to 10, allows the assuming role 106, while playing the delegated role 120, to assume only the role specified by the value of the session label such as "AssumableCustomerRoleRn" when making a request to assume the delegated role 120. For example, the first sub - condition allows the assuming role 106, while playing the delegated role 120, to assume only the customer role 128.

[0111] When the temporary credential service 112 evaluates a policy such as the permission policy 124 of the delegated role 120 against a request for an assuming role (such as a request by the assuming service 106, while playing the delegated role 120, to assume the customer role 128), certain session labels can be automatically set in the request context of the request made by the IAM service 110. These automatically set session keys are sometimes referred to as "conditional" session keys. In addition to or as an alternative to the session keys provided by the requesting service (e.g., the assuming service 106), the temporary credential service 112 can evaluate the conditions of the policy (e.g., condition 126) in terms of the conditional session keys.

[0112] The "ResourceRn" session key referenced by the first sub-condition of condition 126 (line 09) is an example of a conditional session key. The value of the "ResourceRn" conditional session key is set by the IAM service 110 to the resource principal of the resource being requested. For example, when the assuming service 106 assuming the delegated role 120 requests to assume the customer role 128, the resource being requested is the customer role 128, and the value of the "ResourceRn" conditional session key is the set of role principals of the customer role 128. Thus, the first sub-condition checks whether the role that the assuming service 106 requests to assume while assuming the delegated role 120 is the same as the role declared when the assuming service 106 requests to assume the delegated role 120. For example, if the assuming service 106 assuming the assuming service account 118 designates the role principal of the customer role 128 as the value of the "AssumableCustomerRole" session key when requesting to assume the delegated role 120, the first sub-condition of condition 126 checks whether the assuming service 106 requests to assume the customer role 128 when making a role assumption request in the delegated role 120. When the assuming service 106 assuming the delegated role 120 requests to assume a role, the temporary credential service 112 checks the first sub-condition. If the first sub-condition is not met, then condition 126 is not met. The first sub-condition of condition 126 serves the goal of ensuring that the assuming service 106 assumes the delegated role 120 for the purpose of assuming the customer role 128 without assuming other roles.

[0113] The second sub - condition (lines 11 to 14) serves the goal of ensuring that the assumed service 106 does not elevate privileges. Both the "ResourceServiceName" and "Resource Account" session tags are conditional session tags. The "ResourceServiceName" conditional session tag is set by the IAM service 110 to a set of one or more service principals of a set of one or more services that own the assumed role. For example, when the assumed service 106 that is playing the delegated role 120 requests to assume the customer role 128, the "ResourceServiceName" is not set to the service principal of the delegating service 104 because the delegating service 104 does not own the customer role 128. The second sub - condition verifies that the assumed role does not belong to the delegating service 104 or other services listed in the second sub - condition. Specifically, lines 11 and 12 test whether each value in the set of one or more values of the "ResourceServiceName" conditional session key does not match any value in the list of one or more values listed in the condition at line 12. The "ResourceAccount" conditional session tag is set by the IAM service 110 to a set of one or more account identifiers of a set of one or more accounts that own the assumed role. For example, when the assumed service 106 that is playing the delegated role 120 requests to assume the customer role 128, the account identifier of the delegating service account 116 is not set for "ResourceAccount" because the delegating service account 116 does not own the customer role 128. The second sub - condition verifies that the assumed role does not belong to the delegating service account 116 or other accounts listed in the second sub - condition. Specifically, lines 11 and 13 test whether each value in the set of one or more values of the "ResourceAccount" conditional session key does not match any value in the list of one or more values listed in the condition at line 13. Overall, the second sub - condition ensures that when the assumed service 106 that is playing the delegated role 120 requests to assume a role, the role does not belong to an unauthorized service or account. For example, the assumed service 106 that is playing the delegated role 120 is not authorized to assume a role that belongs to the delegating service 104 or the delegating service account 116.

[0114] Although the second sub - condition can include evaluating both the "ResourceServiceName" conditional session tag and the "ResourceAccount" conditional session tag, as Figure 4 depicted, the second sub - condition can include evaluating only one of those conditional session keys. For example, the second sub - condition can include evaluating only the "ResourceServiceName" conditional session tag or only the "ResourceAccount" conditional session tag.

[0115] The third sub - condition (lines 15 to 17) requires that the assume service 106 specify the scoping policy 136 according to the resource name of the policy 136 when assuming the delegated role 120 and when requesting to assume the client role 128. Alternatively, the assume service 106 can specify the scoping policy 136 inline in the assume claim (e.g., as a JSON object containing the text of the policy 136, etc.) instead of specifying the policy 136 by reference or by pointer. After receiving the assume role request, the temporary credential service 112 limits the permissions granted to the assume service 106 to the permissions specified in the scoping policy 136. Specifically, the permissions are limited to a strict subset of actions 138 on the client resource 108. For example, Figure 5 An example of the scoping policy 136 is shown. In this example, the permissions granted to the assume service 106 are limited to performing the "GetQueueAttributes" action on the client resource 108. For example, when the client resource 108 is a message queue, the assume service 106 can perform the "GetQueueAttributes" action on the message queue. This action may allow the assume service 106 to determine whether there are new messages in the message queue, but not to read or delete the new messages.

[0116] Figure 6 An example of the client role 128 is illustrated. The trust policy 130 allows (line 01) the delegating service 104 (here the event bus service) to assume the client role 128. The permission policy 132 allows (line 01) the client role 128 to perform the set of actions 134 (lines 02 to 06) on the client resource 108 (line 07). In this example, the client resource 108 is a message queue, and the set of actions 134 includes reading messages from the message queue, deleting messages from the message queue, and getting the attributes of the message queue. Note that the client role 128 does not grant any permissions to the assume service 106.

[0117] 3. Method

[0118] As Figure 1 shown by the circles labeled S1, S2, and S3 in, one aspect provides a method for role - based permission delegation in a provider network 102. The method includes, at step S1, the assume service 106 sending a request to assume the delegated role 120 to the temporary credential service 112. The method further includes, at step S2, the assume service 106 assuming the delegated role 120 sending a request to assume the client role 114 to the temporary credential service 112 according to the scoping policy 136. The method further includes, at step S3, the assume service 106 assuming the client role 114 performing an action in the strict subset of actions 138 on the client resource 108.

[0119] The method described above may be performed in system 100 or in any other suitable system.

[0120] Go to Figure 7 , which illustrates a method for role-based permission delegation in a provider network. Initially, the assuming service 106 runs in the identity of the assuming service account 118. At step S752, the assuming service 106 acting in the identity of the assuming service account 118 sends a request to assume the delegated role 120 to the temporary credential service 112. In doing so, the request specifies the value of the "AssumableCustomerRoleRn” session key. Specifically, the assuming service 106 designates the role principal of the customer role 128 as the value of "AssumableCustomerRoleRn”. The request also specifies the identity of the assuming service account 118, which is the service principal identifying the assuming service 106.

[0121] After receiving the request to assume the delegated role 120 from the assuming service 106, the temporary credential service 112 evaluates the trust policy 122 of the delegation 120 to determine whether the assuming service 106 has the right to assume the delegated role 120. This evaluation includes verifying that the identity of the assuming service account 118 is an identity authorized to assume the delegation 120 according to the trust policy 122 of the delegated role 120 (e.g., as shown in line 03 of the example trust policy 122 as Figure 3 ). The evaluation also includes the temporary credential service 112 verifying that the value of "AssumableCustomerRoleRn” specified by the assuming service 106 in the request matches the pattern of the role principal (e.g., as shown in lines 10 to 12 of Figure 3 ). The evaluation also includes the temporary credential service 112 verifying that the value of the "SourceRn” conditional session key associated with the request to assume the delegated role 120 matches the pattern of the resource type for which the assuming service 106 is working (e.g., as shown in lines 13 to 15 of Figure 3 ).

[0122] If the identity of the assuming service 106 is an identity allowed by the trust policy 122 to assume the delegation 120 and if the conditions of the trust policy 122 are met for the "AssumableCustomerRoleRn” session key and the "SourceRn” conditional session key, then the temporary credential service 112 issues a temporary security credential to the assuming service 106. If issued, the issued temporary security credential grants the assuming service 106 the permission to assume the role and mark the session. These permissions are encoded in the session token of the temporary security credential issued to the assuming service 106.

[0123] At step S754, the claiming service 106 acting as the delegated role 120 sends a request to assume the customer role 128 to the temporary credential service 112. The request includes a session token or other data from the temporary security credential that represents the permission granted to the claiming service 106 by successfully assuming the delegated role 120 in step 752. Upon receiving the request to assume the customer role 128, the temporary credential service 112 evaluates the request according to the permission policy 124 of the delegated role 120. This evaluation includes evaluating the condition 126 against the request to assume the customer role 128. The evaluation can achieve many objectives. The first objective is to ensure that the claiming service 106 assumes the delegated role 120 for the purpose of assuming the customer role. The second objective is to ensure that the claiming service 106 assumes the delegated role 120 to facilitate the work of the resource type desired by the delegating service 104 (e.g., mitigate confusion of agents). The third objective is to ensure that the claiming service 106 assumes only one role and cannot elevate privileges within the delegating service 104 by assuming roles in any account in the service principal of the delegating service 104. The fourth objective is to ensure that the delegating service 104 narrows the scope of actions that the claiming service 104 can perform in the customer account 114. In Figure 3 In the example trust policy 122 of the delegated role 120 of Figure 4 , the first objective is supported by the first sub-condition at lines 10 to 12 at the trust policy side, while the second objective is supported by the second sub-condition at lines 13 to 15. In

[0124] The temporary credential service 112 evaluates the request to assume the customer role 128 in view of the condition 126. The claiming service 106 cannot assume the customer role 128 unless the condition 126 is satisfied. If the condition 126 is not satisfied, the claiming service 106 cannot assume the customer role 128. Even if the condition 126 is satisfied, the permission granted to the claiming service 106 is limited to the permission granted in the scope narrowing policy 136, which is a strict subset 138 of the group actions 134 for which the permission policy 132 of the customer role 128 grants the delegated role 120. The temporary security credential returned by the temporary credential service 112 in response to the request to assume the customer role 128 encodes the scope-narrowed permission (e.g., in the session token).

[0125] At step S756, the assuming service 106 requests the "target" service to perform a "target" action on the customer resource 108. The target action is an action within the strict subset 138 of action 134. When the assuming service 106 assumes the customer role 128 with a narrowed-down permission at step S754, the request may include a session token or other data from the temporary security credentials returned by the temporary credentials service 112. When the assuming service 106 assumes the customer role 128 with a narrowed-down permission at step S754, the request for the target service encodes the narrowed-down permission granted to the assuming service 106. The IAM service 110 evaluates the request for the target service in terms of the narrowed-down permission. Specifically, unless the target action is one of the actions within the strict subset 138 of action 134 as defined by the narrowed-down policy 136, the IAM service 110 does not authorize the request for the target service. If the target action is not within the strict subset 138, the request for the target service is rejected. If the target operation is within the strict subset 138 of the permitted actions encoded in the request for the target service (e.g., via the session token), the IAM service 110 may permit the request for the target service.

[0126] 4. Variations

[0127] In one variation, the assuming service 106 uses a single assume-role request of the temporary credentials service 112 to assume the customer role 128 with a narrowed-down permission, rather than requiring two assume-role requests as described above. The design emphasizes server-side delegation representation to minimize the duplication of state managed by the delegation service 104. The design also allows the assuming service 106 to be able to make a single assume-role request for the customer role 128. This is achieved through a new IAM service 110 entity called "DelegationRelationship".

[0128] DelegationRelationship is a combination of the delegation service 104 service principal, the assuming service 106 service principal, the narrowed-down policy 136 listing the delegated permissions, and the common resource type for which the delegation is targeted. A pair of the delegation service 104 and the assuming service 106 can have multiple DelegationRelationships for different delegation scenarios (e.g., with different narrowed-down policies or common resource types for which the delegation is targeted).

[0129] When Service 106 requests to assume the customer role 128 from the Temporary Credential Service 112, it references the DelegationRelationship. The Temporary Credential Service 112 verifies that the DelegationRelationship is applicable to the calling service and the customer role trust relationship, that the target role account is not in either of the service principals of the Delegating Service 104 or the Assuming Service 106, and that the "SourceRn" conditional session key matches the resource type of the DelegationRelationship. Then, the Temporary Credential Service 112 applies the identity of the Delegating Service 104 and uses the scope policy 136 to assume the customer role 128. Note that by assuming the customer role 128 via the DelegationRelationship, the first objective discussed above is still implicitly met. The first and fourth objectives are met through server-side verification. The third objective is met through the applied scope policy 136.

[0130] In an extension of the above variant, the concept of "AuthenticationCode" is added to the "DelegationRelationship" method. When the Delegating Service 104 wants to delegate work within an untrusted environment scope to only a single customer role 128, it creates an AuthenticationCode. An AuthenticationCode is created that takes the customer role 128 and the DelegationRelationship (and an expiration time as appropriate), and it returns an encrypted and signed representation of the parameters. The DelegationRelationship itself has a new property that indicates whether an AuthenticationCode is required to use it. The Delegating Service 104 passes the created AuthenticationCode, along with the customer role 128 and the DelegationRelationship, to the Assuming Service 106. The Assuming Service 106 provides all three to the Temporary Credential Service 112. The Temporary Credential Service 112 verifies the signature, decrypts the AuthenticationCode, verifies that the content matches the parameters, checks for expiration, and completes the assumption of the customer role 128. The fully encrypted representation of the AuthenticationCode does not require additional state in the Temporary Credential Service 112. Expiration can be optional, and revocation is expected to be a rare operational event. Therefore, the revocation list can be modeled as a property of the DelegationRelationship entity itself.

[0131] Figure 8 The figure shows a provider network environment 800 in which the techniques disclosed herein may be implemented. Environment 800 includes a provider network 810 and optionally includes an intermediate network 830 and a customer network 840. Although Figure 8 the intermediate network 830 and the customer network 840 are depicted outside the provider network 810 in the figures, the intermediate network 830 and the customer network 840 may alternatively be within (inside) the provider network 810. The provider network 810 provides resource virtualization to customers of the provider network 810 via a virtualization service 818. The virtualization service 818 allows customers to purchase, lease, subscribe to, or otherwise obtain the use of one or more resources (e.g., resource 812).

[0132] Resource 812 may be a computing, storage, or network resource. Resource 812 may be implemented by an electronic device in a data center within the provider network 810. A data center may be a physical facility or building that houses computing, storage, and network infrastructure. The provider network 810 may include many resources implemented by many electronic devices distributed across a set of data centers located in different geographical regions or locations. Examples of electronic devices are the devices 900 described below with respect to Figure 9 description.

[0133] Resource 812 may be a virtual machine (VM) or a container. A virtual machine is a computing resource that uses software rather than a physical computer to run programs and deploy applications. A virtual machine (sometimes referred to as a "guest machine") may run on a single physical machine (sometimes referred to as a "host machine"). A virtual machine may execute its own operating system (e.g., UNIX, WINDOWS, LINUX, etc.) and may run at least partially separately from other virtual machines, including virtual machines on the same host machine. A virtual machine may replace a physical machine. The physical resources of the host machine may be shared among multiple virtual machines, each running a copy of its own operating system. Access to and use of the physical resources of the host machine (e.g., hardware processors and physical memory resources) by multiple virtual machines may be coordinated by a virtual machine monitor (sometimes referred to as a "hypervisor"). The hypervisor itself may run on the bare hardware of the host machine or as a process of an operating system running on the bare hardware.

[0134] In terms of running a separate application on a single platform, a container is like a virtual machine. However, a container typically packages a single application or a group of one or more related applications together with runtime dependencies and libraries, while a virtual machine virtualizes the hardware to create a "computer". Another difference is that a container system typically provides services of the operating system core running on the bare hardware of the underlying host to containers such as container system coordination that share the core services. The container system itself runs on the host by means of the operating system core and isolates containers from each other to a certain extent. Although containers can be used independently of virtual machines, containers and virtual machines can also be used together. For example, a container can run on an operating system that runs on a virtual machine running on a host.

[0135] Within a provider network 810, a local Internet Protocol (IP) address 814 can be associated with a resource 812. The local IP address 814 includes an internal or private network address within the provider network 810. For example, the local IP address 814 can be an IPv4 or IPv6 address. For example, the local IP address 814 can be an address reserved by Internet Engineering Task Force (IETF) Request for Comments (RFC) 1918, or have an address format specified by IETF RFC 4193, and can be variable within the provider network 810.

[0136] Network traffic destined from a network entity 820 coupled to an intermediate network 830 or a customer device 842 in a customer network 840 to a resource 812 in a provider network 810 typically is not directly routed to the local IP address 814. Instead, the network traffic is addressed to a public IP address 816. The public IP address 816 can be mapped to the local IP address 814 within the provider network 810 using network address translation (NAT) or a similar technique.

[0137] Using a customer device 842 in a customer network 840, a customer uses, controls, operates, or benefits from virtualization services 818, resources 812, local IP address 814, and public IP address 816 to implement a customer-specific application and provide the application to one or more network entities (e.g., network entity 820) on an intermediate network 830. The network entity 820 can generate network traffic destined to the application by addressing network traffic to the public IP address 816. The traffic can be routed via the intermediate network 830 to a data center of the provider network 810 that houses electronic devices implementing the resources 812. Within the data center, the traffic can be routed to the local IP address 814, at which address the resources 812 receive and process the traffic. Response network traffic from the resources 812 can be routed back onto the intermediate network 830 and routed to the network entity 820.

[0138] Figure 9 FIG. shows an electronic device 900 that can be used in the implementations disclosed herein. The device 900 includes a set of one or more processors 902-1, 902-2, ……, 902-N, which are coupled to a system memory 906 via an input / output (I / O) interface 904. The device 900 may also include a network interface 916 coupled to the I / O interface 904.

[0139] The device 900 can be a single-processor system including one processor, or can be a multi-processor system including multiple processors. Each of the processors 902-1, 902-2, ……, 902-N can be any suitable processor capable of executing instructions. For example, each of the processors 902-1, 902-2, ……, 902-N can be a general-purpose processor or an embedded processor implementing any of various instruction set architectures (ISAs) such as X86, ARM, POWERPC, SPARC, or MIPS ISA or any other suitable ISA.

[0140] The system memory 906 stores instructions and data accessible by the processors 902-1, 902-2, ……, 902-N. The system memory 906 is implemented using any suitable memory technology, such as random access memory (RAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM), non-volatile or flash-type memory, or any other type of memory. Program instructions 908 and data 910 that implement the desired functions (such as the methods, procedures, actions, or operations of the technologies disclosed herein) are stored in the system memory 906 as code 908 (e.g., executable to implement in whole or in part the methods, procedures, actions, or operations performed by the bearer service 106 or the provisional credential service 112) and data 910.

[0141] The I / O interface 904 is configured to coordinate the I / O traffic between the processors 902-1, 902-2, ……, 902-N, the system memory 906, and any peripheral devices in the device 900, which may include the network interface 916 or other peripheral interfaces (not shown) as appropriate. The I / O interface 904 performs any necessary protocol, timing, or other data transformation to convert the data signals from one component (e.g., the system memory 906) into a format suitable for use by another component (e.g., the processors 902-1, 902-2, ……, 902-N).

[0142] The I / O interface 904 may include support for devices attached via various types of peripheral buses, such as variants of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard (e.g., a bus implementing a certain version of the Peripheral Component Interconnect Express (PCI-E) standard, or another interconnect such as QuickPath Interconnect (QPI) or UltraPath Interconnect (UPI)). For example, the functionality of the I / O interface 904 may be split into two or more separate components, such as a north bridge and a south bridge. Additionally, some of the functionality of the I / O interface 904 (such as the interface to the system memory 906) may be integrated directly into the processors 902-1, 902-2, …, 902-N.

[0143] The optional network interface 916 is configured to permit the exchange of data between the device 900 and another electronic device 920 attached to the device 900 via a network 918. The network interface 916 supports communication via any suitable wired or wireless network (such as, for example, a certain type of wired or wireless Ethernet network). Additionally, the network interface 916 may support communication via a telecommunications or telephone network (such as an analog voice network or a digital fiber-optic communication network), via a storage area network (SAN) (such as a Fibre Channel SAN), or via any other suitable type of network or protocol.

[0144] The device 900 optionally includes an offload card 912, which includes a processor 914 and may include a network interface (not depicted) connected using the I / O interface 904. For example, the device 900 may act as a host electronic device hosting computing resources such as computing instances (e.g., operating as part of a hardware virtualization service), and the offload card 912 may execute a virtualization manager that can manage the computing instances executing on the host electronic device 900. As an example, the offload card 912 may perform computing instance management operations such as pausing or unpausing a computing instance, starting or terminating a computing instance, performing memory transfer / copy operations, etc. These management operations may be performed by the offload card in cooperation with a hypervisor (e.g., in response to a request from the hypervisor) executed by the processors 902-1, 902-2, …, 902-N of the device 900. However, the virtualization manager implemented by the offload card 912 may accommodate requests from other entities (e.g., from the computing instance itself).

[0145] The system memory 906 includes one or more computer-accessible media, which are configured to store program instructions 908 and data 910. However, the program instructions 908 or the data 910 may be received, sent, or stored on different types of computer-accessible media. Computer-accessible media include non-transitory computer-accessible media and computer-accessible transmission media. Examples of non-transitory computer-accessible media include volatile or non-volatile computer-accessible media. Volatile computer-accessible media include, for example, most general-purpose random access memories (RAMs), including dynamic RAM (DRAM) and static RAM (SRAM). Non-volatile computer-accessible media include, for example, semiconductor memory chips capable of storing instructions or data in floating-gate memory cells composed of floating-gate metal-oxide semiconductor field-effect transistors (MOSFETs), including flash memories, such as NAND flash memories, and solid-state drives (SSDs). Other examples of non-volatile computer-accessible media include read-only memories (ROMs), erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), ferroelectric RAMs, and other computer data storage devices (e.g., disk storage, hard disk drives, optical disks, floppy disks, and magnetic tapes).

[0146] In the foregoing description and the appended claims, ordinal numbers such as first, second, etc. may be used to describe various elements, features, acts, or operations. Unless the context clearly indicates otherwise, such elements, features, acts, or operations are not limited by these terms. These terms are only used to distinguish one element, feature, act, or operation from another. For example, a first device may be referred to as a second device. The first device and the second device are both devices, but they are not the same device.

[0147] As used in the foregoing description and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an", and "the" are also intended to include the plural forms.

[0148] As used in the foregoing description and the appended claims, unless the context clearly indicates otherwise, the terms "comprising", "including", "having", "based on", "covering", and other similar terms are used in an open-ended manner in the foregoing description and the appended claims and do not exclude additional elements, features, acts, or operations.

[0149] As for "based on", in some cases in the foregoing description and the appended claims, the term is used to identify a causal relationship between the described steps, acts, or operations. Unless the context clearly indicates otherwise, in these cases, "A based on B" means that the execution of step, act, or operation B causes the execution of step, act, or operation A. The causal relationship can be direct (without going through intermediate steps, acts, or operations) or indirect (through the execution of one or more intermediate steps, acts, or operations). However, unless the context clearly indicates otherwise, the term "A based on B" is not intended to require that the execution of B is necessary for the execution of A in all cases, and in some cases, the execution of A may not be caused by the execution of B. However, in these cases, A is not based on B, even though in other cases, A is based on B. In addition, unless the context clearly indicates otherwise, the term "A based on B" is not intended to require that the execution of B itself is sufficient for the execution of A in all cases, and in some cases, one or more other steps, acts, or operations in addition to B may be executable to cause the execution of A. In such a situation, even if multiple steps, acts, or operations including B are executed to cause A, A can still be based on B.

[0150] Unless the context clearly indicates otherwise, the term "or" is used in the foregoing description and the appended claims in its inclusive sense (rather than in its exclusive sense), such that when used, for example, to connect a series of elements, features, acts, or operations, the term "or" means one, some, or all of the elements, features, acts, or operations in the series.

[0151] Unless the context clearly indicates otherwise, conjunctive language such as the phrase "at least one of X, Y, and Z" in the foregoing description and the appended claims should be understood to convey that an article, item, etc. can be X, Y, or Z, or a combination thereof. Thus, such conjunctive language does not require the separate presence of at least one X, at least one Y, and at least one Z.

[0152] At least some embodiments of the disclosed technology can be described in view of the following clauses:

[0153] 1. A method for role - based permission delegation in a provider network, the method comprising:

[0154] Sending a request to assume a delegated role to a temporary credential service in the provider network through an on - behalf - of service in the provider network, the delegated role including a permission policy that allows assuming a customer role under certain conditions, the permission policy of the customer role allowing a set of actions on customer resources, and the conditions requiring assuming the customer role with permission to execute a strict subset of the set of actions on the customer resources;

[0155] Sending, by the assuming service acting as the delegated role, a request to assume the customer role to the temporary credential service, the request requesting permission to perform the strict action subset on the customer resource; and

[0156] Performing, by the assuming service acting as the customer role with permission to perform the strict subset on the customer resource, a specific action in the strict subset.

[0157] 2. The method according to clause 1, further comprising:

[0158] Receiving, by the temporary credential service, the request to assume the delegated role;

[0159] Evaluating, by the temporary credential service, the trust policy of the delegated role against the request to assume the delegated role;

[0160] Sending, by the temporary credential service, a temporary security credential to act as the delegated role;

[0161] Receiving, by the temporary credential service, the request to assume the customer role;

[0162] Evaluating, by the temporary credential service, the conditions against the request to assume the customer role; and

[0163] Sending, by the temporary credential service, a temporary security credential to act as the customer role with permission to perform the strict subset of the group action on the customer resource.

[0164] 3. The method according to clause 1, wherein performing the action on the customer resource by the assuming service acting as the customer role includes sending, by the assuming service acting as the customer role with permission to perform the strict subset of the group action on the customer resource, a request to a service in the provider network to perform the specific action on the customer resource.

[0165] 4. A method for role - based permission delegation in a provider network, the method comprising:

[0166] Sending, by a first entity in the provider network, a request to assume a first role, the first role including a first permission policy, the first permission policy of the first role allowing assumption of a second role under certain conditions, the second role including a second permission policy, the second permission policy of the second role allowing a set of actions on a resource, the conditions requiring assumption of the second role with permission to perform the strict subset of the set of actions on the resource;

[0167] Sending, by the first entity acting as the first role, a request to assume the second role, the request requesting permission to perform an action of the strict subset on the resource; and

[0168] Performing, by the first entity acting as the second role with permission to perform a strict subset of the group of actions on the resource, a specific action within the strict subset on the resource.

[0169] 5. The method according to clause 4, further comprising:

[0170] Receiving the request to assume the first role;

[0171] Evaluating a trust policy for the first role against the request to assume the first role;

[0172] Sending a temporary security credential to act as the first role;

[0173] Receiving the request to assume the second role;

[0174] Evaluating the condition against the request to assume the second role; and

[0175] Sending a temporary security credential to act as the second role with permission to perform a strict subset of the group of actions on the resource.

[0176] 6. The method according to clause 4, wherein performing the specific action on the resource by the first entity acting as the second role with permission to perform a strict subset of the group of actions on the resource includes sending, by the first entity acting as the second role with permission to perform a strict subset of the group of actions on the resource, a request for a service to perform the specific action on the resource in the provider network.

[0177] 7. The method according to clause 4, further comprising:

[0178] Sending the request to assume the first role using a session key, the value of the session key specifying an identifier of the customer role; and

[0179] Allowing the first entity to assume the first role based on a string pattern matching expression that verifies that the value specifying the identifier of the customer role satisfies the trust policy for the first role, the string pattern matching expression matching a string value in the form of a service principal.

[0180] 8. The method according to clause 4, further comprising:

[0181] Based on verifying that the value of the session key associated with the request to assume the first role satisfies a string pattern matching expression of the trust policy of the first role, allowing the first entity to assume the first role, the value of the session key identifies a resource of a service that makes the request to assume the first role in the provider network, the value of the session key specifies a specific type of resource, the string pattern matching expression matches a string value in the form of a resource principal, and the resource principal form requires the specific type of resource.

[0182] 9. The method as described in clause 4, further comprising:

[0183] Sending the request to assume the first role using a first session key, where the value of the first session key specifies an identifier of the customer role;

[0184] Based on verifying that the value of the identifier specifying the customer role satisfies a string pattern matching expression of the trust policy of the first role, allowing the first entity to assume the first role, and the string pattern matching expression matches a string value in the form of a service principal;

[0185] Based on verifying that the value of a second session key associated with the request to assume the second role satisfies a sub - condition of the condition, allowing the first entity to assume the second role, and the sub - condition of the condition requires that the value of the second session key matches the value of the first session key.

[0186] 10. The method as described in clause 4, further comprising:

[0187] Based on verifying that the value of the session key associated with the request to assume the second role satisfies a sub - condition of the condition, allowing the first entity to assume the second role, and the sub - condition of the condition requires that the value of the session key does not match the service principal specified by the sub - condition.

[0188] 11. The method as described in clause 4, further comprising:

[0189] Based on verifying that the value of the session key associated with the request to assume the second role satisfies a sub - condition of the condition, allowing the first entity to assume the second role, and the sub - condition of the condition requires that the value of the session key does not match the account identifier specified by the sub - condition.

[0190] 12. The method as described in clause 4, further comprising:

[0191] Based on verifying that a value of a session key associated with the request to assume the second role satisfies a sub - condition of the condition, allowing the first entity to assume the second role, the sub - condition of the condition requires that the value of the session key match an identifier of a scope - narrowing policy specified by the sub - condition.

[0192] 13. The method as described in clause 4, further comprising:

[0193] Allowing the first entity to assume the customer role in the case of having permission for a strict subset of performing the group action on the resource includes sending a temporary security credential to the first entity, the temporary security credential encoding the strict subset of the group action that the assuming service has the right to perform on the resource.

[0194] 14. The method as described in clause 4, wherein the first entity is an on - demand code - execution service in the provider network, wherein the resource is a message queue, and wherein the specific action is polling the message queue for new messages.

[0195] 15. A system, comprising:

[0196] A first electronic device in one or more electronic devices for implementing an assuming service in a provider network, the assuming service including instructions that, when executed, cause the assuming service to perform the following operations:

[0197] Send a request to assume a delegated role, the delegated role including a permission policy, the permission policy of the delegated role allowing the assumption of a customer role under certain conditions, the customer role including a permission policy, the permission policy of the customer role allowing a group of actions on customer resources, the condition requiring the assumption of the customer role in the case of having permission for a strict subset of performing the group action on the customer resources;

[0198] Send a request to assume the customer role, the request requesting permission to perform the strict subset of actions on the customer resources; and

[0199] Perform a specific action in the strict subset on the customer resources;

[0200] A second electronic device in one or more electronic devices for implementing a temporary - credential service in the provider network, the temporary - credential service having instructions that, when executed, cause the temporary - credential service to perform the following operations:

[0201] Receive the request to assume the delegated role;

[0202] Send a temporary security credential to assume the delegated role;

[0203] Receive the request to assume the customer role; and

[0204] Send a temporary security credential to assume the customer role with permission to perform the strict subset of the group actions on the customer resources.

[0205] 16. The system as described in clause 15, wherein the temporary credential service includes instructions that, when executed, cause the temporary credential service to perform the following operations:

[0206] Evaluate the trust policy for the delegation role against the request to assume the delegation role; and

[0207] Evaluate the condition against the request to assume the customer role.

[0208] 17. The system as described in clause 15, wherein the instructions configured to perform the specific action in the strict subset on the customer resources include instructions that, when executed by the assume service, further cause the assume service to send a request for a service in the provider network that performs the specific action on the customer resources.

[0209] 18. The system as described in clause 15, further comprising:

[0210] A second electronic device in one or more electronic devices for implementing a temporary credential service in the provider network, the temporary credential service including instructions that, when executed, cause the temporary credential service to perform the following operations:

[0211] Allow the assume service to assume the second role based on verifying that a value of a session key associated with the request to assume the customer role satisfies a sub-condition of the condition, the sub-condition of the condition requiring that the value of the session key match an identifier of a scope reduction policy specified by the sub-condition.

[0212] 19. The system as described in clause 15, further comprising:

[0213] A second electronic device in one or more electronic devices for implementing a temporary credential service in the provider network, the temporary credential service including instructions that, when executed, cause the temporary credential service to perform the following operations:

[0214] Allow the assume service to assume the customer role based on verifying that a value of a session key associated with the request to assume the customer role satisfies a sub-condition of the condition, the sub-condition of the condition requiring that the value of the session key not match an account identifier specified by the sub-condition.

[0215] 20. The system as described in clause 15, further comprising:

[0216] A second electronic device in one or more electronic devices for implementing a temporary credential service in the provider network, the temporary credential service including instructions that, when executed, cause the temporary credential service to perform the following operations:

[0217] Based on verifying that the value of the session key associated with the request assuming the customer role satisfies a sub-condition of the condition, allowing the assuming service to assume the customer role, the sub-condition of the condition requiring that the value of the session key does not match a service principal specified by the sub-condition.

[0218] Those skilled in the art should clearly understand that the above embodiments can be changed in various ways without departing from the scope of the present invention. Therefore, the scope of the present invention should be determined by the following claims and their legal equivalents. < / service> < / partition> < / resource-type> < / account-id> < / region> < / service> < / partition> < / service> < / partition> < / region> < / service> < / partition> < / resource-type> < / account-id> < / region> < / service> < / partition>

Claims

1. A computer-implemented method for role-based permission delegation in a provider network, the method comprising: Sending, by a first entity in the provider network, a request to assume a first role, the first role including a first permission policy, the first permission policy of the first role allowing assumption of a second role under certain conditions, the second role including a second permission policy, the second permission policy of the second role allowing a set of actions on a resource, the conditions requiring assumption of the second role in the case of having permission for a strict subset of the set of actions on the resource; Sending, by the first entity assuming the first role, a request to assume the second role, the request requesting permission to perform the strict subset of actions on the resource; And Performing, by the first entity assuming the second role in the case of having permission for a strict subset of the set of actions on the resource, a specific action in the strict subset on the resource.

2. The computer-implemented method according to claim 1, wherein the first entity is a bearer service in the provider network.

3. The computer-implemented method according to claim 1, wherein the first role is a delegation role.

4. The computer-implemented method according to claim 1, wherein the second role is a customer role.

5. The computer-implemented method according to any one of claims 1 to 4, further comprising: Receiving the request to assume the first role; Evaluating the trust policy of the first role against the request to assume the first role; Sending a temporary security credential to assume the first role; Receiving the request to assume the second role; Evaluating the conditions against the request to assume the second role; And Sending a temporary security credential to assume the second role in the case of having permission for a strict subset of the set of actions on the resource.

6. The computer-implemented method according to any one of claims 1 to 4, wherein performing the specific action on the resource by the first entity assuming the second role in the case of having permission for a strict subset of the set of actions on the resource includes sending, by the first entity assuming the second role in the case of having permission for a strict subset of the set of actions on the resource, a request for a service to perform the specific action on the resource in the provider network.

7. The computer-implemented method according to any one of claims 1 to 4, further comprising: Sending the request to assume the first role using a session key, the value of the session key specifying an identifier of the customer role; And Based on a string pattern matching expression that verifies that the value specifying the identifier of the customer role satisfies the trust policy of the first role, allowing the first entity to assume the first role, the string pattern matching expression matching a string value in the form of a service principal.

8. The computer-implemented method according to any one of claims 1 to 4, further comprising: Based on verifying that the value of the session key associated with the request to assume the first role satisfies a string pattern matching expression of the trust policy of the first role, allowing the first entity to assume the first role, the value of the session key identifies the resource of the service that makes the request to assume the first role in the provider network, the value of the session key specifies a specific type of resource, the string pattern matching expression matches a string value in the form of a resource principal, and the resource principal form requires the specific type of resource.

9. The computer-implemented method according to any one of claims 1 to 4, further comprising: Sending the request to assume the first role using a first session key, the value of the first session key specifying an identifier of the customer role; Based on verifying that the value of the identifier specifying the customer role satisfies a string pattern matching expression of the trust policy of the first role, allowing the first entity to assume the first role, and the string pattern matching expression matches a string value in the form of a service principal; Based on verifying that the value of the second session key associated with the request to assume the second role satisfies a sub-condition of the condition, allowing the first entity to assume the second role, and the sub-condition of the condition requires the value of the second session key to match the value of the first session key.

10. The computer-implemented method according to any one of claims 1 to 4, further comprising: Based on verifying that the value of the session key associated with the request to assume the second role satisfies a sub-condition of the condition, allowing the first entity to assume the second role, and the sub-condition of the condition requires the value of the session key not to match the service principal specified by the sub-condition.

11. The computer-implemented method according to any one of claims 1 to 4, further comprising: Based on verifying that the value of the session key associated with the request to assume the second role satisfies a sub-condition of the condition, allowing the first entity to assume the second role, and the sub-condition of the condition requires the value of the session key not to match the account identifier specified by the sub-condition.

12. The computer-implemented method according to any one of claims 1 to 4, further comprising: Based on verifying that the value of the session key associated with the request to assume the second role satisfies a sub-condition of the condition, allowing the first entity to assume the second role, and the sub-condition of the condition requires the value of the session key to match the identifier of the scope reduction policy specified by the sub-condition.

13. The computer-implemented method according to any one of claims 1 to 4, further comprising: Allowing the first entity to assume the customer role in the case of having permission for a strict subset of performing the group action on the resource includes sending a temporary security credential to the first entity, and the temporary security credential encodes the strict subset of the group action that the assuming service has the right to perform on the resource.

14. The computer-implemented method according to any one of claims 1 to 4, wherein the first entity is an on-demand code execution service in the provider network, wherein the resource is a message queue, and wherein the specific action is polling the message queue for new messages.

15. A system, comprising: a set of one or more electronic devices in a provider network; and instructions that, when executed, cause the set of one or more electronic devices to perform the method according to any one of claims 1 to 14.

Images