Role-based delegation of permissions in a provider network

Abstract

Techniques for providing role-based delegation of permissions in a provider network. The techniques include a bearing service in the provider network sending a request to a temporary credential service in the provider network to bear a delegated role. The bearing service sends a request to a temporary credential service to bear the customer role according to a scope narrowing policy while acting in the delegated role. The bearing service performs an action in a strict subset of actions on customer resources while acting in the customer role. The techniques improve the operation of the provider network by allowing permissions granted by a customer to a delegated service in the provider network to perform actions on the customer resources to be delegated to the bearing service while adhering to the principle of least privilege access control.

Description

Technical Field

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

[0002] Due to the development and increasing prevalence of computer technology, more and more individuals, companies, organizations, and other users are using 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 often use provider network infrastructure for building and hosting. Currently, popular provider networks encompass millions of servers worldwide supporting hundreds of products and services that users use to build and deploy their computing applications and workloads.

[0003] Provider networks offer a wide variety of services to users. For example, a popular provider network may offer services such as virtualization (equivalent to "elastic computing"), relational database services, data storage services, on-demand code execution (equivalent to "serverless code execution"), content delivery network (CDN) services, machine learning services, and others. From the provider network's perspective, its users are sometimes referred to as "customers."

[0004] Because 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 content can access services and resources within the provider network. IAM in a provider network typically operates according to the principle of least privilege. According to this principle, accessing entities should only be granted the permissions necessary to perform their intended function, and not more (stronger) permissions. Based on this principle, services in a provider network are either not granted any permissions by default, or only granted very limited permissions to access resources supplied to customers within the provider network. Typically, customers must grant services permission to access resources before the services can perform useful actions on those resources on behalf of the customer. Attached Figure Description

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

[0006] Figure 1 The diagram illustrates an example of a system for role-based license delegation in a provider network.

[0007] Figure 2 The image shows an example of a character link.

[0008] Figure 3 The diagram illustrates an example of a trust strategy for delegating roles.

[0009] Figure 4 The diagram illustrates an example of a licensing strategy for delegated roles.

[0010] Figure 5 The diagram illustrates an example of a range reduction strategy.

[0011] Figure 6 The diagram illustrates an example of trust and permission policies for customer roles.

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

[0013] Figure 8 The diagram illustrates a network of providers that can implement the technologies disclosed herein.

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

[0015] It should be understood that, for the sake of simplicity or clarity, the elements shown in the accompanying drawings are not necessarily drawn to scale. For example, the dimensions of one element may be enlarged relative to another element for clarity. Furthermore, reference numerals have been repeated in the drawings where deemed appropriate to indicate corresponding or similar elements. Detailed Implementation

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

[0017] 1. Overview

[0018] Various aspects of this disclosure provide systems and methods for role-based license delegation in provider networks.

[0019] like Figure 1As shown, one aspect provides a system 100 for role-based permission delegation in a provider network 102. System 100 includes a provider network 102 and, where appropriate, an intermediate network 148 and a remote electronic device 140. Provider network 102 includes a delegation service 104, a responsibility service 106, resources provided to customers 108 (equivalent to “customer resources 108”), and an identity and access service 110 (equivalent to “IAM service 110”). IAM service 110 includes a customer account, a delegation service account 116, a responsibility service account 118, a delegation role 120, a customer role 128, and a scope narrowing policy 136. Delegation role 120 includes a trust policy 122 and a permission policy 124. Customer role 128 also includes its own trust policy 130 and permission policy 132. Permission policy 132 of customer role 128 allows a set of actions 134 to be performed on customer resources 108. The licensing policy 124 of the delegated role 120 specifies the conditions 126 for assuming the client role 128. The conditions 126 for assuming the client role 128 require compliance with the scope narrowing policy 136. The scope narrowing policy 136 restricts the actions allowed to be performed on the client resource 108 to a strict subset 138 of the group of actions 134 permitted by the licensing policy 132 of the client role 128. 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.

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

[0021] like Figure 1 As indicated by the circles marked S1, S2, and S3, one aspect provides a method for role-based license delegation in a provider network 102. The method includes, at step S1, a delegation service 106 sending a request for a delegation role 120 to a temporary credential service 112. The method further includes, at step S2, a delegation service 106 acting as delegation role 120 sending a request for a client role 114 to the temporary credential service 112 according to a scope narrowing policy 136. The method further includes, at step S3, a delegation service 106 acting as client role 114 performing an action from a strict action subset 138 on client resource 108.

[0022] The method can be performed in system 100 or in any other suitable system.

[0023] The system and method improve the operation of provider network 102 by allowing permission granted by a client to delegate service 104 to perform actions on client resource 108 to undertaking service 106. Undertaking service 106 can perform actions more efficiently (e.g., with lower latency, higher throughput, fewer CPU or GPU clock cycles, or less data storage space), perform actions with lower administrative or organizational costs (e.g., by reducing or avoiding software development costs), or perform actions 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 the benefit of improved operation of provider network 102 by providing a mechanism that allows permission to perform a strict subset 138 of actions on client resource 108 to undertaking service 106 without undertaking service 106 obtaining permission to perform all actions in the group of actions 134 on client resource 108, thereby adhering to the principle of least privilege. Since the system and method can be used to ensure that the undertaking service 106 receives permission to perform only the actions necessary to carry out the tasks assigned to it, the system and method improve the operation of the provider network by reducing or eliminating actions that the undertaking service 106 does not need to perform in order to carry out the assigned tasks, whether accidentally or intentionally performed by the undertaking service 106.

[0024] Additional aspects, applications, and advantages will become apparent with reference to the following description and related figures.

[0025] 2. System

[0026] like Figure 1As shown, one aspect provides a system 100 for role-based permission delegation in a provider network 102. System 100 includes a provider network 102 and, where appropriate, an intermediate network 148 and a remote electronic device 140. Provider network 102 includes a delegation service 104, a responsibility service 106, resources provided to customers 108 (equivalent to “customer resources 108”), and an identity and access service 110 (equivalent to “IAM service 110”). IAM service 110 includes a customer account, a delegation service account 116, a responsibility service account 118, a delegation role 120, a customer role 128, and a scope narrowing policy 136. Delegation role 120 includes a trust policy 122 and a permission policy 124. Customer role 128 also includes its own trust policy 130 and permission policy 132. Permission policy 132 of customer role 128 allows a set of actions 134 to be performed on customer resources 108. The licensing policy 124 of the delegated role 120 specifies the conditions 126 for assuming the client role 128. The conditions 126 for assuming the client role 128 require compliance with the scope narrowing policy 136. The scope narrowing policy 136 restricts the actions allowed to be performed on the client resource 108 to a strict subset 138 of the group of actions 134 permitted by the licensing policy 132 of the client role 128. 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 and any of its components depicted herein may include any other suitable components.

[0028] System 100 includes a provider network 102 for providing a computing environment that enables the technologies disclosed herein. Provider network 102 can be programmed or configured to conform to a cloud computing model. This 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 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 within provider network 102 as needed, such as virtual machines, containers, server time, network storage, or any other resources, with minimal or no human interaction with the service provider. Resources of provider network 102 are available through an intermediate network 148 (e.g., the Internet) and accessed via 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, tablets, laptops, workstations, smart appliances, Internet of Things (IoT) devices, or any other type of electronic device.

[0030] Resources in Provider Network 102, such as compute, storage, processing, memory, and network resources, are aggregated to serve multiple customers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on customer demand. There is a sense of location independence because customers typically cannot control or know the exact location of the resources provided, but can specify the location at a higher level of abstraction (e.g., at the level of country, state, data center, or any other location granularity). Provider Network 102 can automatically control and optimize resource usage by leveraging metering capabilities at an appropriate level of abstraction for service types (such as compute, storage, processing, memory, network bandwidth, active customer accounts) or any other suitable level of abstraction (e.g., based on pay-as-you-go, charge-as-you-go, subscription-based, or any other fee basis). Monitoring, controlling, and reporting resource usage in Provider Network 102 provides transparency for both the providers and customers utilizing the services.

[0031] Provider network 102 can offer its capabilities to customers based on 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, capabilities can be provided to customers using software applications of provider network 102 running on provider network 102's infrastructure. Applications may be accessible from various remote electronic devices (e.g., remote device 140) via thin client interfaces such as command-line interface (CLI) 142, graphical user interface (GUI) 144 (e.g., via a web browser or mobile or web application), software development kit (SDK) 146, or any other interface. Provider network 102's infrastructure may include hardware resources such as servers, storage, and network resources, and software deployed on the hardware infrastructure to support the services provided. Typically, under the SaaS model, customers do not manage or control the underlying infrastructure, including networks, servers, operating systems, storage, or individual application capabilities, except for limited customer-specific application configuration settings.

[0033] For PaaS, it provides customers with the ability to deploy applications created or acquired by the customer onto the hardware and software infrastructure of the provider's network 102 using programming languages, libraries, services, and tools supported by the provider's network 102 or other sources. Typically, under the PaaS model, customers do not manage or control the underlying hardware and software infrastructure, including the network, servers, operating system, or storage, but they can control the deployed applications and may control the configuration settings of the application hosting environment.

[0034] For IaaS, it provides customers with the ability to provision processing, storage, networking, and other basic computing resources on which customers can deploy and run any software, including operating systems and applications. Customers typically do not manage or control the underlying hardware and software infrastructure, but they can control the operating system, storage, and deployed applications, and may have limited control over the selection of network components (such as, for example, host firewalls).

[0035] Provider network 102 can offer its capabilities to customers based on a variety of different deployment models, including 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 provider network 102 is provided for the exclusive use of a single organization that may include multiple customers. A private cloud is owned, managed, and operated by an organization, a third party, or some combination thereof, and it can exist on-premises or off-premises.

[0037] In a community cloud, the hardware and software infrastructure of provider network 102 is dedicated to specific communities of customers within organizations that share common concerns, such as mission security requirements, policies, and compliance considerations. A community cloud may be owned, managed, and operated by one or more of the organizations within the community, third parties, or some combination thereof, and it may reside internally or off-site.

[0038] In a public cloud, infrastructure is provided for public use. A public cloud is owned, managed, and operated by commercial, academic, or governmental organizations, or a combination thereof. A public cloud may reside within the premises of a public cloud provider.

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

[0040] To provide a clear example, Figure 1 The provider network 102 is depicted as including one delegated service, one undertaken service, and one customer resource. However, in a real implementation, the provider network 102 may include multiple delegated services, multiple undertaken services, or multiple customer resources. Again, for the sake of clarity, Figure 1 The IAM service 110 is described as including only one delegate role, one customer role, one scope narrowing strategy, one customer account, one delegated service account, and one undertaken service account. However, in actual implementations, the IAM service 110 may include multiple different components of any one or all of these. Similarly, system 100 may include multiple remote electronic devices, or multiple intermediate networks connecting remote electronic devices to provider network 102. Therefore, Figure 1

[0041] Delegation service 104 is a service within provider network 102, whereby a customer grants it permission to perform the group of actions 134 on customer resource 108. The techniques disclosed herein are used to delegate permission for a strict subset 138 of those actions 134 on customer resource 108 to undertaking service 106. Here, the strict subset 138 is less than all actions 134, such that undertaking service 106 is not authorized to perform at least one of the actions 134 on customer resource 108, while delegation service 104 is authorized to perform the actions on customer resource 108 according to the authorization of customer role 128. Through the role-based permission delegation disclosed herein, permission to perform the strict subset 138 of actions on customer resource 108 is delegated to undertaking service 106 without requiring the customer to change the permission granted to delegation service 104, nor does the customer need to grant undertaking service 106 permission to perform the strict subset 138 of actions on resource 108. In fact, the customer may be unaware that delegation is occurring. This provides greater flexibility to provider network 102 in role-based licensing of service delegation across 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 on provider network 102's limited computing resources, wherein undertaking service 106 can perform actions on customer resource 108 more efficiently than delegating service 104; reduced error rate of provider network 102 performing tasks on behalf of customers, wherein undertaking service 106 can perform actions on customer resource 108 more reliably than delegating service 104; reduced development and maintenance costs for provider network 102's operators, wherein undertaking service 106 has pre-existing functionality to perform actions on customer resource 106, while delegating service 104 does not have such functionality or said functionality has been deprecated, or any other implemented benefits or technical effects.

[0042] Provider network 102 is built according to a service-oriented, web service, or microservice architecture. This architecture integrates distributed, individually maintained, and deployed services. A service is a discrete unit of software or hardware functionality provided by provider network 102, which can be remotely accessed (e.g., from remote device 130 or from another service within provider network 102) and can act and update independently of other services. For example, a service may have any or all of the following characteristics: logically representing a repeatable function with a specified result; self-contained; a "black box" from the perspective of a client of provider network 102, because the client does not need to understand the implementation details of the service to obtain utility; and composed of other services within provider network 102.

[0043] The services in provider network 102 provide application programming interfaces (APIs), which allow remote access to the functions of the services in the following ways: (1) through other services in provider network 102, which are connected to the services through an intermediate network in provider network 102. Figure 1 (1) (not shown in the diagram) or (2) via 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 constructing and integrating services or devices. An API is a contract representing an agreement between services or devices that, if one service or device sends a remote request to another service or device via an intermediate network constructed in a specific manner, the other service or device will perform one or more specific actions and respond in a specific manner via the intermediate network. For example, an API may be designed based on web standards, such as using the Hypertext Transfer Protocol (HTTP) or other suitable protocols to define the structure of request messages and response messages. Response messages may be in the form of machine-readable data formats, 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 specifications, may be used to standardize the exchange of information via the API. APIs can contain web hooks (equivalent to "reverse APIs" or "push APIs"), which are HTTP-based callback functions that allow lightweight, event-driven communication between two APIs. Web hooks place the responsibility for communication on the service, not the client. Using a web hook, instead of the client sending an HTTP request to request data, the server immediately sends a single HTTP publish request to the client when the data is available.

[0044] The API standards and protocols listed above are merely examples of some possible standards and protocols that can be used to implement the APIs of the services in Provider Network 102. Other standards or protocols may be used depending on the requirements of the specific service. The service APIs in Provider Network 102 do not require any specific standards or protocols.

[0045] Provider Network 102 offers a variety of services to its customers. Some possible services that Provider Network 102 may provide 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 aforementioned list of services is merely an example of a set of services that Provider Network 102 may provide. Provider Network 102 may provide different services. No specific service or set of services is required.

[0046] Virtualization services allow customers to rent virtual computers to run their own computer applications. Virtualization services include a network service that allows customers to launch and configure virtual machines (equivalent to "instances") containing and configuring the software they need. Using the network service, customers can create, launch, or terminate instances as needed and pay for active instances. This ability to create, launch, and terminate instances as needed is sometimes referred to as "elastic" computing.

[0047] Relational database services are a type of distributed database service. They include web services that simplify the setup, operation, and scaling of relational databases for use by client applications. For example, relational database services can facilitate administrative processes such as patching database software, backing up the database, enabling point-in-time recovery, or any other suitable relational database management tasks.

[0048] Data storage services provide data object storage through a network service interface. Data storage services can store any type of data object and manage 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 a "bucket." 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., CLI 142), 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 languages ​​such as NODE.JS, PYTHON, JAVA, GO, RUBY, C#, or other suitable computer programming languages. The service executes the code as temporary instances. For example, each temporary instance can be an operating system container (equivalent to a "zone," "virtual private service," "partition," "virtual environment," "virtual kernel," or "prison"). Each instance can access a limited amount of random access memory (RAM) (e.g., between 1,128 MB and 10,240 MB of RAM). Each instance is provided with a limited amount of temporary data storage (e.g., between 512 MB and 10 GB), which is only available during the instance's duration and its data content is discarded after the instance terminates. Each instance executes for a limited time (e.g., between 1 second and 900 seconds). During operation, a code package containing the code to be executed and a maximum compressed size is created or uploaded to the data storage service. For example, the maximum compressed size of the code package could be 50 MB. The On-Demand Code Execution Service is instructed (via its API) to download the package from the data storage service and run the contained code in response to an event. 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 each time. Each instance runs in a new environment, making it impossible or only possible to access the execution context of previous and subsequent executions of the code. Therefore, each instance is inherently stateless, and input and output data are stored alongside other services. For example, an instance's input or output data may be stored alongside 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 on clients' and users' remote electronic devices, thereby reducing latency in accessing (downloading) content.

[0051] The function of a machine learning service is to enable users to create, train, and deploy machine learning models. Machine learning services operate at varying levels of complexity when training and deploying machine learning models. For example, a machine learning service may offer pre-trained machine learning models that can be deployed as is, built-in machine learning algorithms that customers can use to train machine learning models, and managed instances of machine learning frameworks (such as TENSORFLOW or Apache MXNET) that customers can use to create their own machine learning models.

[0052] The services described above are merely examples of the possible services that provider network 102 may provide. Provider network 102 may provide different services or similar services with different functions or implementations. No specific service, service function, or service implementation is required.

[0053] Delegation service 104 is a service within provider network 102. In the example discussed here, delegation 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 may indicate a change in the environment of provider network 102 and may be represented as a JSON object, etc. An event has a set of fields. For example, an event may 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 client account held by provider network 102 associated with the event. The value of the “time” field includes a timestamp (date and time) of the event (e.g., the time the event occurred or was generated). The value of the “region” field identifies the geographic 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) involved in the event in provider network 102. The value of the “detail” field contains a nested JSON object or similar containing information about the event, which 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. Events received by the event bus service can contain different fields. No specific event or set of event fields is required.

[0055] Upon 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 client using the Event Bus Service's API. The target is a resource in provider network 102; when an event matches a rule, the Event Bus Service sends the event to that resource. Rules define the event structure and the fields that the rule matches. For example, a rule can be a regular expression that matches or does not match one or more field names or one or more values ​​of one or more fields of an event (e.g., the value of the "source," "detail-type," or "detail" field of the event). For example, when the Event Bus Service receives an event indicating that a virtual machine instance has changed from a pending state to a running state, the Event Bus Service's rules can send the event to an On-Demand Code Execution Service instance for further processing. In addition to event-pattern-based rules, or as an alternative, rules are based on a schedule for periodically executed actions. For example, rules can periodically trigger the execution of an On-Demand Code Execution Service instance according to a schedule (e.g., based on a cron expression or a rate expression).

[0056] Although in the example discussed herein, delegated service 104 is an event bus service, delegated service 104 and the present invention are generally not limited thereto. For example, delegated service 104 may be a different type of service in provider network 102 (e.g., virtualization service, on-demand code execution service, relational database service, or other service in provider network 102). The example of providing an event bus service is for the purpose of providing clarity, but the present invention is not intended to limit delegated service 104 to being an implementation of an event bus service. Depending on the requirements of the present particular implementation, delegated service 104 may be a different type of service in provider network 102.

[0057] Through the permission policy 132 of the customer-created customer role 128, the delegated service 104 is granted permission by the customer to perform the group of actions 134 on the customer resource 108. For example, the customer resource 108 could be a message queue supplied to the customer in the provider network 102. In this case, the permission policy 132 of the customer role 128 can grant the delegated service 104 permission to perform certain actions on the customer resource 108, such as, for example, receiving and deleting messages from the message queue. This is merely one example of the group of actions 134 that the permission policy 132 of the customer role 128 can grant the delegated service 104 permission to perform on the customer resource 108. Permissions to perform different sets of actions are possible. No specific permission or action is required.

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

[0059] Alternatively, the permission granted to perform actions on client resource 108 inherently does not include permission to perform smaller actions on client resource 108. In this case, the permission policy 132 of client role 128 must grant permission to perform any smaller actions. For example, if client resource 108 is a message queue, the permission policy 132 of client role 128 could grant permission to delegate service 104 to receive messages from the message queue, delete messages from the message queue, and poll the message queue for new messages.

[0060] By utilizing the permission granted by the customer through the permission policy 132 of the customer role 128 to perform the group action 134 on the customer resource 108, the delegation service 104 can perform those actions on behalf of the customer on the customer resource 108. For example, in the case that the delegation service 104 is an event bus service, the delegation service 108 can poll a message queue to get new messages, read messages from the queue, and delete messages from the queue.

[0061] However, one or more actions in the group of actions 134, where the delegated service 104 has permission from the client to execute on the client resource 108, can be performed more efficiently by the undertaking service 106. For example, the on-demand code execution service, due to its "serverless" nature, can perform the action of polling the message queue more efficiently than the event bus service. In this case, it might be necessary to use the event bus service's scheduling rules to periodically start an on-demand code execution service instance that polls the message queue for any new messages available. The output of the on-demand code execution service instance can indicate whether a new message is available in the message queue based on the latest poll. If a new message is available, the event bus service can receive the output of the on-demand code execution service instance as an event. The event bus service's event pattern rules can be used to match events indicating that a new message is available in the message queue. When such an event is matched, the event bus service can read the new message from the message queue. By utilizing this operational separation, 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 the message queue is merely one example of a scenario where the delegated service 104 is granted permission by the client to perform the group action 134 on the client resource 108, wherein one or more actions in the group action 134 are performed more efficiently by the undertaking service 106. Permissions to perform other group actions may be granted by the client to the delegated service 104, and different actions may be performed more efficiently by the undertaking service 106 without requiring 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 undertaking service 106. However, there may be other reasons besides improving computational efficiency, or as an alternative. For example, permissions may be delegated for administrative or organizational reasons. For instance, a software developer on a team responsible for maintaining the On-Demand Code Execution service may have already developed code for polling message queues to be executed as an instance of the On-Demand Code Execution service, where no equivalent functionality currently exists for the event bus service. In this example, delegating the permission to perform the action of polling message queues to the On-Demand Code Execution service may be more administratively or organizationally efficient (e.g., more cost-effective) because the programmed functionality already exists, while adding polling functionality to the event bus service would require additional software development time and effort. Security is another reason for delegation. For example, the undertaking service 106 may have access to the client's encryption key required to perform an action on client resource 108. In this case, the action can be delegated to the undertaking service 106 instead of granting additional access to the encryption key to the delegating service 104.

[0064] The above are just some examples of reasons for delegating the permission to perform actions on resource 108 to service 106. There may be other reasons besides or alternatives to these. No special reason is required.

[0065] Services in provider network 102 have identifiers (equivalent to "identities") referred to herein as "service subjects". Service subjects, such as those for delegating service 104 or undertaking service 106, take a form suitable for distinguishing one service from another in provider network 102. For example, a service subject may belong to a hierarchical namespace, similar to the hierarchical format of domain name services. For instance, a service subject in provider network 102 may have the following general format: <service-name>".examplepn.com", where "exa mplepn.com" is an example of a top-level domain service domain from provider network 102.<servi ce-name> This is a placeholder for the service name. For example, if delegated service 104 is an event bus service, then the service principal of delegated service 104 could be "evtbussvc.examplepn.com", where "evtbussvc" is the name assigned to the event bus service. As another example, if undertaken service 106 is an on-demand code execution service, then the service principal of undertaken service 106 could be "codeexecsvc.examplepn.com", where "codeexecsvc" is the name assigned to the on-demand code execution service.

[0066] The service principal is a shortened name or alias of a common top-level part, which may be omitted, either separately or alternatively. For example, in a provider network 102 where a group of services share a common top-level part of their respective service principals (such as "examplepn.com" in the previous example), the valid service principal of a service may contain only its service name (e.g., "evtbussvc" or "code execsvc"), without having to use its fully qualified service principal (e.g., "evtbussvc.exa mplepn.com" or "codeexecsvc.examplepn.com"), where the common top-level part is either implicit or explicit.

[0067] Hierarchical service principals allow for more fine-grained (equivalent to "nested") service principals. For example, a sub-service, component, or resource of a service can have nested service principals nested within the service principal of the service. For instance, a resource of an event bus service might have a service principal "pipes.evtbussvc.examplepn.com" or simply "pipes.evtbussvc," nested within a service principal "evtbussvc.examplepn.com" or simply "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 distinct from the service itself. This can be useful for, for example, granting permission to perform actions on a resource only to a specific sub-service, component, or resource of the service without granting permission to the entire service.

[0068] Service 106 is a service that obtains permission from provider network 102 to perform a strict subset 138 of the group actions 134 on customer resource 108. Service 106 uses role-based licensing to obtain permission to perform the strict subset 134 of actions on customer resource 108.

[0069] An IAM role (or "role" only) is an IAM identity (or "identity" only) existing in IAM service 110 that 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 resources supplied to the customer in provider network 102. Customer role 128 and delegated role 120 are two examples of roles.

[0070] A role can be assumed by a service in provider network 102 that requires the role. For example, a service may assume the role of performing actions on behalf of a client on a resource in provider network 102 (e.g., resource 108). 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, temporary security credentials are provided to the service through temporary credential service 112. The role of a service performing actions on a resource in provider network 102 that is supplied to a client is sometimes referred to herein as a "service" role. A service role includes the permission required for the service to access the resources in provider network 102 that the service needs to perform tasks on behalf of the client. For example, client role 128 may grant delegated service 104 permission to perform the group action 134 on client resource 108. For example, in the case where delegated service 104 is an event bus service and client resource 108 is a message queue supplied to a client, permission policy 132 of client role 128 may grant 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 referred to herein as a "role" subject. The role subject uniquely identifies a role in string data format. The role subject can be used to identify roles in licensing policies. For example, the role subject can take the form of a Uniform Resource Name (URN), a Universally Unique Identifier (UUID), etc. However, a specific data format is not required for the role subject. For example, the role subject 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," indicating that what follows is the component resource name that identifies the resource in provider network 102. <partition>A component refers to a partition of provider network 102 where the resource resides. <service>The component identifies the service within provider network 102 to which the resource belongs. (Optional) <region>The component identifies the geographic region of the provider network 102 where the resource is located. <account-id>A component is an identifier for a client account that owns resources or to which resources are supplied. <resource-type>The component identifies the type of resource. <resource-id>A component is an identifier for a resource.

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

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

[0076] In this example, <partition>It is "examplepn", which refers to provider network 102. <service>"iamsvc" refers to IAM service 110 in provider network 102. No zone specified; this indicates that the role subject can be used to identify roles in all zones of provider network 102. Example <account-id>"111122223333" identifies customer account 114 held by provider network 102 through its account identifier. Customer account 114 has customer role 128. <resource-type>It is "role" and <resource-id>It is "customer-role-1".

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

[0078] Roles have trust policies. For example, customer role 128 and delegated role 120 each have trust policies 130 and 122, respectively. A role's trust policy defines the entity trusted to assume the role. The trusted entity can be a service entity. For example, trust policy 130 for customer role 128 could define delegated service 104 trusted to assume customer role 128. An example of trust policy 130 is provided herein. As another example, trust policy 122 for delegated role 120 could define service 106 trusted to assume delegated role 120. An example of trust policy 122 is provided herein.

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

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

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

[0082] Figure 2 This is an interactive diagram illustrating the role linking. At operation 240, the assumption service 106 sends a request to the temporary credential service 112 to assume the delegated role 120. At operation 242, the temporary credential service 112 responds to the assumption role request from operation 240 by returning the temporary security credentials of the delegated role 120 to the assumption service 106. Using the temporary security credentials of the delegated role 120, the assumption service 106 can assume the delegated role 120 (possessing its identity). At operation 244, the assumption service 106 uses the temporary security credentials of the delegated role 120 to comply with condition 126 by requesting the temporary credential service 112 to assume the client role 114. To comply with condition 126, when making the assumption role request at operation 244, the assumption service 106 must request permission to perform only the actions or multiple actions (equivalent to "delegated actions") permitted by condition 126, where the permitted actions are actions within a strict subset 138 of the group of actions 134 defined by the scope narrowing strategy 136. At operation 246, the temporary credential service 112 responds to the assumption role request of operation 244 by returning a temporary security credential for the client role 114 with narrowed permissions to the assumption service 106. Using the temporary security credential for the client role 114 with narrowed permissions, the assumption service 106 can assume the client role 114 (with its identity), but has permission to perform a strict subset of actions 138 on the client resource 108, but not permission to perform all actions 134 on the client resource 108. At operation 248, the assumption service 106 performs the delegated actions in the strict subset 138 on the resource 108.

[0083] As a concrete example, suppose client resource 108 is a message queue. Client role 128's permission policy 132 can grant delegated service 104 permission to perform read, delete, and polling actions on the message queue. Delegated role 120's trust policy 122 can grant assuming service 106 permission to assume delegated role 120. Permission policy 124, including condition 126 for delegated role 120, can authorize delegated role 120 to assume client role 114, but only to perform polling actions on the message queue, not to perform read or delete operations. In this case, after successfully assuming delegated role 120 at operation 242 and thus receiving temporary security credentials, assuming service 106, acting as delegated role 120, can assume client role 114 only if the assuming role at operation 244 requests permission to perform polling actions on the message queue but not permission to perform read or delete operations.

[0084] Although in the example discussed herein, service 106 is an on-demand code execution service, service 106 and the present invention are generally not limited thereto. For example, service 106 may be different types of services in provider network 102 (e.g., virtualization services, relational database services, etc.). The example of on-demand code execution service is provided for clarity, but the present invention is not intended to limit service 106 to an implementation of on-demand code execution service. Depending on the requirements of the particular implementation, service 106 may be different types of services in provider network 102.

[0085] Customer resource 108 is an object existing within a service of provider network 102. For example, customer resource 108 could be a message queue existing within a message queuing service of provider network 102. However, customer resource 108 is not limited to any particular resource or any particular 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 may support any or all of the following actions on the message queue: creating a message queue, deleting a message from a message queue, polling a message queue for new messages, receiving a message from a message queue, delivering (sending) a message to a message queue, or any other suitable message queue action. However, the service does not need to support any particular action or set of actions on the resource. And the actions or multiple actions supported by the service on the resource can vary between different resource types and different services.

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

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

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

[0089] The above general resource naming format has been discussed in more detail in the discussion about the main character above.

[0090] For example, the resource entity of customer resource 108 could be:

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

[0092] In this example, <partition>It is "examplepn", which refers to provider network 102. <service>"qsvc" refers to the message queuing service in provider network 102. The region is "us-west-1," indicating that resource 108 is located in the western United States (Northern California) geographic region of 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>It is "queue" and <resource-id>It is "some-queue-1".

[0093] The resource body string data format described above is merely one example of possible string data formats that can be used to identify resources in provider network 102. Alternatively, other string data formats may be used, including formats based on web page standards such as the Uniform Resource Name (URN) standard (Draft for Comments (RFC) 8141) or the Universal Unique Identifier (UUID) standard (RFC 4122). No specific string data format is required, and any string data format suitable for identifying resources in provider network 102 can be used.

[0094] Although in the example discussed herein, customer resource 108 is a message queue of a message queuing service in provider network 102, customer resource 108 and the present invention are generally not limited thereto. For example, customer resource 108 may be a resource of a different type belonging to a different service in provider network 102. For example, customer resource 108 may be a database table of a database management service in provider network 102. As other examples, customer resource 108 may be a virtual machine instance of a virtualization service in provider network 102, or customer resource 108 may be a data object stored in a data storage service in provider network 102. The example of a message queue is provided for clarity, but it does not imply that the invention is limited to customer resource 108 being an implementation of a message queue. Furthermore, customer resource 108 may be a resource of a different type in provider network 102, depending on the requirements of the present particular implementation.

[0095] The function of IAM service 110 is to securely control access to resources in provider network 102 by authorizing a "requesting" subject to perform actions on resources in provider network 102. The requesting subject may include, but is not limited to, a role subject. When a "requesting" service (e.g., undertaking service 106) in provider network 102 sends a request (e.g., an HTTP or HTTP request) to a "target" service (e.g., a service providing access to customer resource 108) in provider network 102 to perform an action on a resource (e.g., resource 108), IAM service 110 evaluates and authorizes the request based on the request context of the request. The request context may contain data specifying any or all of the following: the requested action to be performed, the requested resource, the requesting subject (e.g., a role subject), environmental data (e.g., information about a network address, user agent, SSL enabled status, or the current date / time associated with the requesting service sending the request), resource data (e.g., data related to the requested resource, such as a database table name or a virtual machine instance identifier), 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 IAM service 110. For example, the temporary security credentials may include an access key identifier that identifies the temporary security credentials, the expiration date / time of the temporary security credentials, a secret access key that can be used to cryptographically sign the request 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 requesting service's request may include the session token of the temporary security credentials. Alternatively or additionally, the request or request context may be cryptographically signed using the secret access key of the temporary security credentials.

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

[0098] 2.6 Temporary Certificate Service

[0099] The Temporary Credentials Service 112 of IAM Service 110 provides an API that allows services in Provider Network 102 (e.g., Assumption Service 106) to assume a role. To assume a role, Assumption Service 106 makes an assumption role request to Temporary Credentials Service 112. If the assumption role request is successful, Temporary Credentials Service 112 returns temporary security credentials for the assumed role.

[0100] The role assumption request accepts several request parameters, including the "Role Session Duration" parameter and the "Role Identifier" parameter, as well as other possible parameters. The Role Session Duration parameter specifies the duration (in seconds) of 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 role assumption request, the Temporary Credentials Service 112 uses a default duration (e.g., 3600 seconds) when generating temporary security credentials to return to the requesting service. The minimum allowed duration (e.g., 900 seconds) and the maximum allowed duration (e.g., 432000 seconds) limit the possible values ​​for the Role Session Duration parameter. After the expiration date, the requesting service will no longer be able to use the temporary security credentials to perform actions for the assumed role. The requesting service must submit a new role assumption request to the Temporary Credentials Service 112 to obtain a new set of temporary security credentials with an updated validity period for the assumed role. The Role Identifier parameter specifies the role subject of the role to be assumed.

[0101] When the undertaking service 106 makes an undertaking role request, it can specify a set of session tags. Session tags are key-value pairs. Furthermore, when the undertaking service 106 makes the undertaking role request, it cryptographically signs the request using a secret encryption key representing its identity. For example, the undertaking service 106 can sign the undertaking role request using a secret key associated with the undertaking service account 118. By doing so, the temporary credential service 112 verifies the undertaking role request and determines that it was initiated by the undertaking service account 118.

[0102] The assumption role request signed by assumption service 106 includes one or more session tags. Temporary credential service 112 evaluates policies based on the session tags in the assumption role request. When assumption service 106 makes an assumption role request for assumption delegation role 120, assumption service 106 specifies at least two session tags in the assumption role request. One session tag has a key named "AssumableCutomterRoleRn". Another tag has a key named "SourceRn". These key names are just examples of possible session tag names, and other names may be used.

[0103] The value of the "AssumableCustomerRoleRn" session tag must be the role principal of the role that the Assuming Service 106 requests to assume. For example, the value of "AssumableCustomerRoleRn" could be the role principal of the Customer role 128. The purpose of this session tag is to enable the Temporary Credentials Service 112 to enforce the following objective: the Assuming Service 106 assumes the delegated role 120 solely for the purpose of assuming the 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 type for which service 106 is facilitating its work. For example, the value of the "SourceRn" session tag could be the resource principal of the resource that delegates service 104. This session tag is required to mitigate proxy obfuscation. Proxy obfuscation is a security issue where an entity without the authority to perform an action can force a more privileged entity to perform that action.

[0105] Figure 3 This is an example of trust policy 122 for delegation 120. When the undertaking service 106, acting as undertaking service account 118, requests the temporary credential service 112 to assume the delegation role 120, the temporary credential service 112 evaluates trust policy 112. Trust policy 122 is defined in JSO N format, but other machine-readable formats (e.g., XML) may also be used. Line numbers (e.g., "07") are in... Figure 1 The `<assumable>` tag is used for reference, but is not part of Trust Policy 122. Overall, Trust Policy 122 grants (allows) Assuming Service 106 (lines 02-04) permission to perform a set of actions (lines 05-08) under certain conditions (lines 09-16) (line 01). In this example, Assuming 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., Assuming Service 106) permitted by Trust Policy 122. The set of actions at lines 05-08 includes permission to perform Assuming Role actions and permission to perform Tag Session actions. The Tag Session Action permission allows Assuming Service 106 to specify session tags in Assuming Role requests, such as the "AssumableCustomerRoleRn" session tag and the "SourceRn" session tag.

[0106] The conditions at lines 09 to 16 define two sub-conditions, which, according to the implicit logical AND operator on these two sub-conditions, must be satisfied to satisfy the overall condition. The first sub-condition at lines 10 to 12 requires the undertaking service 106 to specify the value of the "AssumableCustomerRoleRn" session tag, 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 undertaking the delegated role 120, the first sub-condition requires the undertaking service 106 to provide the value of the "AssumableCustomerRoleRn" session tag in the role undertaking request, the value of which matches the role body pattern. This only serves the purpose of the undertaking service 106 undertaking the delegated role 120, i.e., undertaking the role identified by the value of the "AssumableCustomerRoleRn" session tag (e.g., customer role 128), and not undertaking other roles. The second sub-condition at lines 13-15 requires the undertaking service 106 to specify a value for the "SourceRn" session tag, whereby the value matches the string expression specified in the second sub-condition (with the asterisk character ('*') used as a wildcard match). Specifically, when undertaking the delegated role 120, the second sub-condition requires the undertaking service 106 to provide a value in the undertaking role request that matches the pattern of the resource principal of the resource type for which the undertaking service 106 is providing work assistance. The purpose of requiring this session tag is to mitigate proxy obfuscation. Proxy obfuscation is a security issue where an entity without the authority to perform an action can force an entity with more privileges to perform that action. Figure 3 In the example trust policy 122, the delegated service 104 is an event bus service and undertakes the "pipeline" resource facilitation work on behalf of the delegated service 106.

[0107] Assuming service 106 initially acts as assuming the identity of assuming service account 118. Then, assuming service 106 requests temporary credential service 112 to assume the delegated role 120. In doing so, assuming service 106 specifies the values ​​of the "AssumableCustomerRoleRn" session tag and the "SourceRn" session tag. For example, the value of the "AssumableCustomerRoleRn" session tag could be the role principal of customer role 128, while the value of the "SourceRn" session tag could be the resource principal of the resource of delegated service 104. Upon receiving the assumption role request, temporary credential service 112 verifies whether the values ​​of the "AssumableCustomerRoleRn" and "SourceRn" session tags satisfy the conditions of trust policy 122 for delegated role 120. If satisfied, temporary credential service 112 returns temporary security credentials allowing assuming service 106 to assume the delegated role 120. For example, the temporary security credentials could allow assuming service 106 to perform assumption role and tag session actions while assuming the delegated role 120 (with its identity). Please note that if the undertaking service 106 does not specify valid values ​​for the "AssumableCustomerRole Rn" and "SourceRn" session tags when requesting the undertaking delegated role 120, the conditions of the trust policy 122 of the delegated role 120 will not be met, and the temporary credential service 112 will not return valid temporary security credentials to the undertaking service 106 for the purpose of acting as the delegated role 120.

[0108] Next, if Service 106 has successfully assumed the delegated role 120, Service 106 may continue to assume the customer role 128 in accordance with the conditions 126 of the licensing policy 124 of the delegated role 120. Figure 4 This is an example of the permission 124 for the delegated role 120, evaluated by the temporary credential service 112, when the undertaking service 106, acting as the delegated role 120 (using its identity), requests to assume the client role 128. In general, permission policy 124 allows (line 01) a set of actions (lines 02-05) to be performed on any resource (line 06) under condition 126 (lines 07-18). In this example, the set of actions at lines 02-05 includes permission to perform the undertaking role action and permission to perform the tag session action. The permission to perform the undertaking role action allows the undertaking service 106, acting as the delegated role, to request the undertaking role from the temporary credential service 112 to assume the client role 128. The permission to perform the tag session action allows the undertaking service 106 to specify one or more session tags when requesting to assume the client role 128.

[0109] Condition 126 is actually the condition for service 106 to assume the client role 128 while playing the delegating role 120. Condition 126 has sub-conditions, which are connected together by a 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 subcondition at lines 08 to 10 allows the assuming role 106, which plays the delegating role 120, to assume only the role specified by the value of the "AssumableCustomerRoleRn" session label when making a request to assume the delegating role 120. For example, the first subcondition allows the assuming role 106, which plays the delegating role 120, to assume only the customer role 128.

[0111] When the temporary credential service 112 evaluates a policy such as the authorization policy 124 for the delegated role 120 against a request for the assumed role (such as a request for the assumed client role 128 made by the assumed service 106 acting as the delegated role 120), certain session tags may 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 key provided by the requesting service (e.g., the assumed service 106), the temporary credential service 112 may evaluate the conditions of the policy (e.g., condition 126) from the perspective of the conditional session key.

[0112] The first subcondition of condition 126 (line 09) references the "ResourceRn" session key, which is an example of a conditional session key. The value of the "ResourceRn" conditional session key is set by IAM service 110 to the resource subject of the requested resource. For example, when undertaking service 106, acting as delegate role 120, requests to undertake customer role 128, the requested resource is customer role 128, and the value of the "ResourceRn" conditional session key is the set of role subjects for customer role 128. Therefore, the first subcondition checks whether the role that undertaking service 106 requests to undertake when acting as delegate role 120 is the same as the role declared when undertaking service 106 requests to undertake delegate role 120. For example, if undertaking service 106, acting as undertaking service account 118, specifies the role subject of customer role 128 as the value of the "Assuma bleCustomerRole" session key when requesting to undertake delegate role 120, then the first subcondition of condition 126 checks whether undertaking customer role 128 is requested when undertaking service 106 makes an undertaking role request as delegate role 120. When the undertaking service 106, which plays the delegated role 120, requests to assume a certain 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 purpose of ensuring that the undertaking service 106 assumes the delegated role 120 for the purpose of assuming the customer role 128 and not other roles.

[0113] The second subcondition (lines 11-14) serves the purpose of ensuring that the assumed service 106 does not escalate privileges. Both the "ResourceServiceName" and "Resource Account" session tags are conditional session tags. The "ResourceServiceName" conditional session tag is set by IAM service 110 to a set of one or more service principals that own one or more services that assume the assigned role. For example, when the assuming service 106, acting as the delegated role 120, requests to assume the client role 128, "ResourceServiceName" is not set to a service principal of the delegated service 104 because the delegated service 104 does not own the client role 128. The second subcondition verifies that the assumed role does not belong to the delegated service 104 or any other service listed in the second subcondition. 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 IAM service 110 to a set of one or more account identifiers that own one or more accounts that assume the assigned role. For example, when the assuming service 106, acting as delegated role 120, requests to assume client role 128, the account identifier of delegated service account 116 is not set to "ResourceAccount" because delegated service account 116 does not own client role 128. The second subcondition verifies that the assumed role does not belong to delegated service account 116 or any other account listed in the second subcondition. Specifically, lines 11 and 13 test whether each value in the set of one or more values ​​of the "ResourceAccount" condition 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 subcondition ensures that when the assuming service 106, acting as delegated role 120, requests to assume a role, the role does not belong to an unauthorized service or account. For example, the assuming service 106, acting as delegated role 120, is not authorized to assume a role belonging to delegated service 104 or delegated service account 116.

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

[0115] The third subcondition (lines 15-17) requires that the undertaking service 106 specify the scope narrowing strategy 136 based on the resource name of strategy 136 when acting as a delegate 120 and when requesting to assume the client 128. Alternatively, the undertaking service 106 may specify the scope narrowing strategy 136 inline in a hypothetical point name (e.g., as a JSON object containing the text of strategy 136, etc.) instead of specifying strategy 136 by reference or by pointer. Upon receiving the undertaking role request, the temporary credential service 112 will grant the undertaking service 106 a license limited to the license specified in the scope narrowing strategy 136. Specifically, the license is limited to performing a strict subset of actions 138 on the client resource 108. For example, Figure 5 An example of scope narrowing strategy 136 is shown. In this example, the permission granted to the undertaking service 106 is limited to performing the "GetQueueAttributes" action on the client resource 108. For example, when the client resource 108 is a message queue, the undertaking service 106 can perform the "GetQueueAttributes" action on the message queue. This action allows the undertaking service 106 to determine whether there are new messages in the message queue, but not to read or delete new messages.

[0116] Figure 6 The diagram illustrates an example of client role 128. Trust policy 130 allows (line 01) delegation service 104 (here, the event bus service) to assume client role 128. Permission policy 132 allows (line 01) client role 128 to perform the group action 134 (lines 02-06) on client resource 108 (line 07). In this example, client resource 108 is a message queue, and the group action 134 includes reading messages from the message queue, deleting messages from the message queue, and retrieving attributes of the message queue. Note that client role 128 does not grant any permissions to assuming service 106.

[0117] 3. Methods

[0118] like Figure 1 As indicated by the circles marked S1, S2, and S3, one aspect provides a method for role-based license delegation in a provider network 102. The method includes, at step S1, a delegation service 106 sending a request for a delegation role 120 to a temporary credential service 112. The method further includes, at step S2, a delegation service 106 acting as delegation role 120 sending a request for a client role 114 to the temporary credential service 112 according to a scope narrowing policy 136. The method further includes, at step S3, a delegation service 106 acting as client role 114 performing an action from a strict action subset 138 on client resource 108.

[0119] The method can be performed in system 100 or in any other suitable system.

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

[0121] Upon receiving a request from the undertaking service 106 to undertake the delegated role 120, the temporary credential service 112 evaluates the trust policy 122 of the delegated role 120 to determine whether the undertaking service 106 is authorized to undertake the delegated role 120. This evaluation includes verifying that the identity of the undertaking service account 118 is authorized to undertake the delegated role 120 according to the trust policy 122 of the delegated role 120 (e.g., as...). Figure 3 Example trust policy 122 (line 03). The evaluation also includes temporary credential service 112 verifying that the "AssumableCustomerRoleRn" value specified by the assuming service 106 in the request matches the pattern of the role principal (e.g., as shown in line 03 of the example trust policy 122). Figure 3 (As shown in lines 10 to 12). 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 a pattern of the resource type on which the assuming service 106 represents its work (e.g., as shown in lines 10 to 12). Figure 3 (As shown in rows 13 to 15).

[0122] If the identity of the undertaking service 106 is permitted by trust policy 122 for the identity of the undertaking delegation 120, and if the conditions of 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 undertaking service 106. If issued, the issued temporary security credential grants the undertaking service 106 the undertaking role and marks the session as authorized. These permissions are encoded in the session token of the temporary security credential issued to the undertaking service 106.

[0123] At step S754, the undertaking service 106, acting as delegated role 120, sends a request to the temporary credential service 112 to assume the client role 128. The request includes a session token or other data from the temporary security credential indicating that permission has been granted to the undertaking service 106 by successfully assuming the delegated role 120 in step 752. Upon receiving the request to assume the client role 128, the temporary credential service 112 evaluates the request according to the delegation role 120's permission policy 124. This evaluation includes assessing condition 126 against the request to assume the client role 128. The evaluation can achieve several objectives. A first objective is to ensure that the undertaking service 106 assumes the delegated role 120 for the purpose of assuming the client role. A second objective is to ensure that the undertaking service 106 assumes the delegated role 120 to facilitate the work of the type of resources desired by the delegation service 104 (e.g., mitigating agent confusion). A third objective is to ensure that the undertaking service 106 assumes only one role and cannot escalate privileges within the delegation service 104 by assuming the role in any account within the delegation service 104's service body. The fourth objective is to ensure that delegated service 104 narrows the scope of actions that service 104 can perform within customer account 114. Figure 3 In the example trust policy 122 for delegated role 120, the first objective is supported at the trust policy end by the first sub-condition at lines 10-12, while the second objective is supported by the second sub-condition at lines 13-15. Figure 4 In example condition 126 of the licensing policy 124 for delegated role 120, the first objective is supported by the first sub-condition at lines 08 to 10. The third objective is supported by the second sub-condition at lines 11 to 14. The fourth objective is supported by the third sub-condition at lines 15 to 17.

[0124] Temporary credential service 112 evaluates the request to assume the client role 128 based on condition 126. Unless condition 126 is met, assumption service 106 cannot assume the client role 128. If condition 126 is not met, assumption service 106 cannot assume the client role 128. Even if condition 126 is met, the permission granted to assumption service 106 is limited to the permission granted in the scope reduction policy 136, which is a strict subset 138 of the group actions 134 granted to delegated role 120 by permission policy 132 of client role 128. The temporary security credential returned by temporary credential service 112 in response to the request of assuming the client role 128 encodes the scope reduction permission (e.g., in a session token).

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

[0126] 4. Changes

[0127] In one variant, the assumption service 106 uses a single assumption role request from the temporary credential service 112 to assume the client role 128 with a narrowed scope of permissions, instead of requiring two assumption role requests as described above. The design emphasizes server-side delegation representation to minimize duplication of state managed by the delegation service 104. The design also allows the assumption service 106 to make a single assumption role request for the client role 128. This is achieved through a new IAM service entity called "DelegationRelationship" 110.

[0128] A DelegationRelationship is a combination of the delegating service 104, the undertaking service 106, the scope narrowing strategy 136 listing the delegated licenses, and the type of public resource to which the delegation is directed. The pair of delegating service 104 and undertaking service 106 can have multiple DelegationRelationships with different delegation scenarios (e.g., different scope narrowing strategies or different types of public resources to which the delegation is directed).

[0129] When assuming the client role 128, service 106 references DelegationRelationship to temporary credential service 112. Temporary credential service 112 verifies that DelegationRelationship applies to the calling service and the client role trust relationship, that the target role account is not in either the service principal of delegating service 104 or assuming service 106, and that the "SourceRn" conditional session key matches the resource type of DelegationRelationship. Temporary credential service 112 then applies the identity of delegating service 104 and assumes the client role 128 using scope policy 136. Note that assuming the client role 128 via DelegationRelationship still implicitly satisfies the first objective discussed above. The first and fourth objectives are satisfied through server-side verification. The third objective is satisfied through the applied scope policy 136.

[0130] In the above variations, the concept of "AuthenticationCode" is added to the "DelegationRelationship" method. When the delegation service 104 wants to delegate work within an untrusted environment to a single client role 128, it creates an AuthenticationCode. This AuthenticationCode requires client role 128 and a DelegationRelationship (and, if applicable, an expiration time), and returns an encrypted and signed representation of the parameters. The DelegationRelationship itself has a new property indicating whether an AuthenticationCode is required for its use. The delegation service 104 passes the created AuthenticationCode, along with client role 128 and the DelegationRelationship, to the undertaking service 106. The undertaking service 106 provides all three items 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 undertaking for client 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 cancellation list can be modeled as a property of the DelegationRelationship entity itself.

[0131] Figure 8 The diagram illustrates a provider network environment 800 in which the techniques disclosed herein can be implemented. Environment 800 includes a provider network 810 and, where appropriate, an intermediate network 830 and a customer network 840. Although Figure 8 Intermediate network 830 and customer network 840 are depicted outside of provider network 810, but intermediate network 830 and customer network 840 may alternatively be inside provider network 810. Provider network 810 provides resource virtualization to its customers via virtualization service 818. Virtualization service 818 allows customers to purchase, lease, subscribe to, or otherwise obtain access to one or more resources (e.g., resource 812).

[0132] Resource 812 can be a computing, storage, or networking resource. Resource 812 can be implemented by electronic devices within a data center within the provider network 810. A data center can be a physical facility or building housing computing, storage, and networking infrastructure. The provider network 810 can contain numerous resources implemented by numerous electronic devices distributed across a set of data centers located in different geographical regions or locations. Examples of electronic devices are described below. Figure 9 The device 900 is described.

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

[0134] In terms of running a single application on a single platform, a container is similar to a virtual machine. However, containers typically package a single application or a group of one or more related applications along with runtime dependencies and libraries, while virtual machines virtualize hardware to create a "computer." Another difference is that container systems typically provide the services of an operating system kernel running on the underlying host's bare hardware to containers that share core services, much like container system coordination. The container system itself runs on the host with the help of the operating system kernel and isolates the containers from each other to some extent. While 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 the host.

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

[0136] Network traffic originating from network entity 820 coupled to intermediate network 830 or client device 842 in client network 840, destined for resource 812 in provider network 810, is typically not directly routed to local IP address 814. Instead, network traffic is addressed to public IP address 816. Public IP address 816 can be mapped to local IP address 814 within provider network 810 using Network Address Translation (NAT) or similar techniques.

[0137] Using client device 842 in client network 840, a client uses, controls, operates, or benefits from virtualization service 818, resource 812, local IP address 814, and public IP address 816 to implement a client-specific application and provides said application to one or more network entities (e.g., network entity 820) on intermediate network 830. Network entity 820 can generate network traffic destined for said application by addressing network traffic to public IP address 816. The traffic can be routed via intermediate network 830 to data center of provider network 810, which houses the electronic device implementing resource 812. Within the data center, the traffic can be routed to local IP address 814, where resource 812 receives and processes the traffic. Response network traffic from resource 812 can be routed back to intermediate network 830 and routed to network entity 820.

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

[0139] Device 900 may be a single-processor system including one processor, or a multiprocessor system including multiple processors. Each of processors 902-1, 902-2, ..., 902-N may be any suitable processor capable of executing instructions. For example, each of processors 902-1, 902-2, ..., 902-N may be a general-purpose processor or an embedded processor implementing any of a variety of instruction set architectures (ISAs) (such as x86, ARM, POWERPC, SPARC, or MIPS ISA or any other suitable ISA).

[0140] System memory 906 stores instructions and data accessible to processors 902-1, 902-2, ..., 902-N. 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 memory, or any other type of memory. Program instructions 908 and data 910 that implement the desired function (such as the methods, processes, actions, or operations of the techniques disclosed herein) are stored in system memory 906 as code 908 (e.g., executable to fully or partially implement the methods, processes, actions, or operations performed by undertaking service 106 or temporary credential service 112) and data 910.

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

[0142] I / O interface 904 may include support for devices attached via various types of peripheral buses, such as, for example, the Peripheral Component Interconnect (PCI) bus standard or variants of the Universal Serial Bus (USB) standard (e.g., a bus implementing a version of the High Speed ​​Peripheral Component Interconnect (PCI-E) standard, or another interconnect such as Fast Path Interconnect (QPI) or Ultra Path Interconnect (UPI)). For example, the functionality of I / O interface 904 may be broken down into two or more separate components, such as a Northbridge and a Southbridge. Furthermore, some of the functionality of I / O interface 904 (such as an interface to system memory 906) may be directly integrated into processors 902-1, 902-2, ..., 902-N.

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

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

[0145] System memory 906 includes one or more computer-accessible media configured to store program instructions 908 and data 910. However, program instructions 908 or data 910 may be received, transmitted, or stored on different types of computer-accessible media. Computer-accessible media include non-transitory computer-accessible media and computer-accessible transport 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 memory (RAM), 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 memory such as NAND flash memory and solid-state drives (SSDs). Other examples of non-volatile computer-accessible media include read-only memory (ROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), ferroelectric RAM, and other computer data storage devices (e.g., disk storage, hard disk drive, optical disk, floppy disk, and magnetic tape).

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

[0147] As used in the foregoing description and 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 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 appended claims and do not exclude additional elements, features, actions, or operations.

[0149] With regard to the term "based on," the term is used in some instances in the foregoing description and appended claims to identify a causal relationship between the stated steps, actions, or operations. Unless the context clearly indicates otherwise, "A based on B" in these instances means that the execution of step, action, or operation B results in the execution of step, action, or operation A. The causal relationship can be direct (without intermediate steps, actions, or operations) or indirect (through the execution of one or more intermediate steps, actions, 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 if in other cases A is based on B. Furthermore, 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 to result in the execution of A in all cases, and in some cases, one or more other steps, actions, or operations besides B may be performed to result in the execution of A. In such cases, even if multiple steps, actions, or operations, including B, are performed to result in 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 appended claims in its inclusive meaning (rather than its exclusive meaning) such that when used, for example, to connect a series of elements, features, actions, or operations, the term "or" means one, some, or all of the series of elements, features, actions, or operations.

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

[0152] At least some embodiments of the disclosed technology may be described in light of the following terms:

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

[0154] A request to assume a delegated role is sent through an assumption service in the provider network to a temporary credential service in the provider network. The delegated role includes a permission policy that allows the assumption of a customer role under certain conditions. The customer role also includes a permission policy that allows a set of actions on customer resources. The conditions require assuming the customer role only if there is permission to perform a strict subset of the set of actions on the customer resources.

[0155] The assuming service, acting as the delegate, sends a request to the temporary credential service to assume the client role, the request requesting permission to perform the strict subset of actions on the client resource; and

[0156] The specific actions within the strict subset are performed on the customer resources by the undertaking service that assumes the customer role with permission to perform the strict subset on the customer resources.

[0157] 2. The method as described in Clause 1, further comprising:

[0158] The temporary credential service is used to receive the request to assume the delegated role;

[0159] The trust policy of the delegated role is evaluated by comparing the temporary credential service with the request of the delegated role.

[0160] Send temporary security credentials through the temporary credential service to assume the delegated role;

[0161] The temporary credential service is used to receive the request to assume the customer role.

[0162] The conditions are assessed by comparing the temporary credential service with the request to assume the customer role; and

[0163] Temporary security credentials are sent via the temporary credential service to assume the customer role with permission to perform the group actions on the customer resources.

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

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

[0166] A request to assume a first role is sent through a first entity in the provider network. The first role includes a first licensing policy that allows the assumption of a second role under certain conditions. The second role includes a second licensing policy that allows a set of actions on a resource. The conditions require the assumption of the second role with permission to perform a strict subset of the set of actions on the resource.

[0167] The request to assume the second role is sent by the first entity playing the first role, the request requesting permission to perform the strict subset of actions on the resource; and

[0168] The first entity, acting as the second role, performs specific actions within the strict subset of the group actions on the resource.

[0169] 5. The method as described in Clause 4, further comprising:

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

[0171] The trust strategy of the first role is evaluated in comparison with the request made by the person assuming the first role.

[0172] Send temporary security credentials to assume the first role;

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

[0174] The conditions are assessed in light of the request to assume the second role; and

[0175] Send temporary security credentials to assume the second role if permitted to perform the group action on the resource.

[0176] 6. The method as described in Clause 4, wherein performing the specific action on the resource by the first entity playing the second role with permission to perform the group action on the resource includes sending a request to a service in the provider network to perform the specific action on the resource by the first entity playing the second role with permission to perform the group action on the resource.

[0177] 7. The method as described in Clause 4, further comprising:

[0178] Send the request to assume the first role using a session key, the value of which specifies an identifier for the client role; and

[0179] Based on a string pattern matching expression that verifies that the value of the identifier specifying the customer role satisfies the trust policy of the first role, the first entity is allowed to assume the first role, wherein the string pattern matching expression matches a string value having the form of a service subject.

[0180] 8. The method as described in Clause 4, further comprising:

[0181] Based on a string pattern matching expression that verifies and associates the value of the session key associated with the request to assume the first role, which satisfies the trust policy of the first role, the first entity is allowed to assume the first role. The value of the session key identifies a resource in the provider network for the service that made the request to assume the first role. The value of the session key specifies a particular type of resource. The string pattern matching expression matches a string value having a resource body form that requires the particular type of resource.

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

[0183] The request to assume the first role is sent using a first session key, the value of which specifies the identifier of the customer role;

[0184] Based on a string pattern matching expression that verifies that the value of the identifier specifying the customer role satisfies the trust policy of the first role, the first entity is allowed to assume the first role, wherein the string pattern matching expression matches a string value having the form of a service subject;

[0185] The first entity is allowed to assume the second role based on a sub-condition of the condition that the value of the second session key associated with the request to assume the second role satisfies the condition, wherein 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] The first entity is allowed to assume the second role based on a sub-condition of the condition that the value of the session key associated with the request to assume the second role satisfies the condition, wherein the sub-condition of the condition requires that the value of the session key does not match the service subject specified by the sub-condition.

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

[0189] The first entity is allowed to assume the second role based on a sub-condition of the condition that the value of the session key associated with the request to assume the second role satisfies the condition, wherein 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] The first entity is allowed to assume the second role based on a sub-condition of the condition that the value of the session key associated with the request to assume the second role satisfies the condition, wherein the sub-condition of the condition requires that the value of the session key match an identifier of a range narrowing strategy specified by the sub-condition.

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

[0193] Allowing the first entity to assume the client role with permission to perform the strict subset of the group actions on the resource includes sending a temporary security credential to the first entity, the temporary security credential encoding the assumption service's right to perform the strict subset of the group actions 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 a service in a provider network, the service including instructions, when executed, to cause the service to perform the following operations:

[0197] Send a request to assume a delegated role, the delegated role including a licensing policy that allows assuming a customer role under certain conditions, the customer role including a licensing policy that allows a set of actions on customer resources, the conditions requiring assuming the customer role with permission to perform a strict subset of the set of actions on the customer resources;

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

[0199] Perform specific actions from 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, when executed, to cause the temporary credential service to perform the following operations:

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

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

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

[0204] Send temporary security credentials to assume the customer role with permission to perform the group actions on the customer resources.

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

[0206] Assess the trust strategy of the delegated role in light of the request to assume the delegated role; and

[0207] The conditions are evaluated in light of the request to assume the customer role.

[0208] 17. The system as described in Clause 15, wherein the instruction configured to perform the specific action of the strict subset on the customer resource includes, when performed by the undertaking service, an instruction to further cause the undertaking service to send a request to a service in the provider network to perform the specific action on the customer resource.

[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, when executed, to cause the temporary credential service to perform the following operations:

[0211] The service is allowed to assume the second role based on a sub-condition of the condition, which states that the value of the session key associated with the request to assume the customer role satisfies the condition, wherein the sub-condition requires that the value of the session key match an identifier of a range narrowing strategy 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, when executed, to cause the temporary credential service to perform the following operations:

[0214] The service is allowed to assume the customer role based on a sub-condition of the condition, which requires that the value of the session key associated with the request to assume the customer role does not match the 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, when executed, to cause the temporary credential service to perform the following operations:

[0217] The service is allowed to assume the customer role based on a sub-condition of the condition, which states that the value of the session key associated with the request to assume the customer role satisfies the condition, wherein the sub-condition requires that the value of the session key does not match the service subject specified by the sub-condition.

[0218] Those skilled in the art will understand that the above embodiments can be modified 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 method for role-based permission delegation in a provider network, the method comprising: The license to delegate a delegated role to a delegated service in the provider network, wherein the license is granted by a customer to the delegated service in the provider network, and wherein the delegated service and the delegated service are discrete units of software or hardware functions provided by the provider network, the discrete units being remotely accessible and capable of taking action and updating independently of each other. The undertaking service sends a request to a temporary credential service in the provider network to assume the delegated role, the delegated role including a permission policy that allows the undertaking service to assume a customer role under a condition, the customer role including a permission policy that allows a set of actions for customer resources, the condition requiring that the customer role be assumed if there is permission to perform a strict subset of the set of actions for the customer resources, wherein the strict subset of the set of actions is less than all actions in the set of actions; The assuming service, acting as the delegate, sends a request to the temporary credential service to assume the client role, the request being for assuming the client role for requesting permission to perform a strict subset of the set of actions on the client resources; as well as By acting as the client, the undertaking service performs specific actions within the strict subset of the set of actions for the client resource, provided that it is authorized to perform such actions on the client resource.

2. The method of claim 1, further comprising: The temporary credential service receives requests to assume the delegated role. The temporary credential service is used to assess the trust policy of the delegated role in comparison with the request to assume the delegated role. Send temporary security credentials through the temporary credential service to assume the delegated role; The temporary credential service receives requests to assume the customer role. The conditions are assessed by comparing them with the request to assume the customer role through the temporary credential service; as well as Temporary security credentials are sent via the temporary credential service to assume the client role with permission to perform a strict subset of the set of actions on the client resources.

3. The method of claim 1, wherein performing actions on the customer resources by the service provider acting as the customer includes: The undertaking service, acting as the customer, sends a request to a service in the provider network to perform the specific action on the customer resource, provided that it has permission to perform the action on the customer resource, within the strict subset of the set of actions on the customer resource.

4. A method for role-based license delegation in a provider network, the method comprising: A license is delegated to a first service in the provider network to assume a first role, wherein the license is granted by a customer to a second service in the provider network, and wherein the first service and the second service are discrete units of software or hardware functions provided by the provider network, the discrete units being remotely accessible and capable of acting and updating independently of each other; The first service sends a request to assume the first role, the first role including a first permission policy, the first permission policy of the first role allowing the first service to assume a second role under a condition, 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 condition requiring the second role to be assumed if there is permission to perform a strict subset of the set of actions on the resource, wherein the strict subset of the set of actions is less than all actions in the set of actions; The first service, acting as the first role, sends a request to assume the second role, the request being for assuming the second role of granting permission to perform a strict subset of the set of actions for the resource; and A specific action in the strict subset of the set of actions on the resource is performed by the first service, which plays the second role, provided it is authorized to perform a strict subset of the set of actions on the resource.

5. The method of claim 4, further comprising: Receive the request to assume the first role; The trust strategy of the first role is evaluated in comparison with the request to assume the first role. Send temporary security credentials to assume the first role; Receive the request to assume the second role; The conditions are evaluated in light of the request to assume the second role; as well as Send temporary security credentials to assume the second role if permitted to perform a strict subset of the set of actions on the resource.

6. The method of claim 4, wherein performing the specific action on the resource by the first service, which plays the second role and has permission to perform a strict subset of the set of actions on the resource, comprises: The first service, which plays the second role and is permitted to perform the specific action on the resource, sends a request to a service in the provider network to perform the specific action on the resource.

7. The method of claim 4, further comprising: A request to assume the first role is sent using a session key, wherein the session key has a value that specifies an identifier for the second role; as well as Based on a string pattern matching expression that verifies that the value of the identifier specifying the second role satisfies the trust policy of the first role, the first service is allowed to assume the first role, wherein the string pattern matching expression matches a string value having the form of a service subject.

8. The method of claim 4, further comprising: Based on a string pattern matching expression that verifies the value of a session key associated with the request to assume the first role and satisfies the trust policy of the first role, the first service is allowed to assume the first role. The value of the session key identifies a resource in the provider network for which the service has made the request to assume the first role. The value of the session key specifies a particular type of resource. The string pattern matching expression matches a string value having a resource body form that requires the particular type of resource.

9. The method of claim 4, further comprising: A request to assume the first role is sent using a first session key, wherein the first session key has a value that specifies an identifier for the second role; Based on a string pattern matching expression that verifies that the value of the identifier specifying the second role satisfies the trust policy of the first role, the first service is allowed to assume the first role, wherein the string pattern matching expression matches a string value having the form of a service subject; The first service is allowed to assume the second role based on a sub-condition of the condition that the value of the second session key associated with the request to assume the second role satisfies the condition, wherein the sub-condition of the condition requires that the value of the second session key matches the value of the first session key.

10. The method of claim 4, further comprising: The first service is allowed to assume the second role if the value of the session key associated with the request to verify and assume the second role satisfies a sub-condition of the condition, wherein the sub-condition requires that the value of the session key does not match the service subject specified by the sub-condition.

11. The method of claim 4, further comprising: The first service is allowed to assume the second role based on a sub-condition of the condition that the value of the session key associated with the request to verify and assume the second role meets the condition, wherein 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.

12. The method of claim 4, further comprising: The first service is allowed to assume the second role based on a sub-condition of the condition that the value of the session key associated with the request to assume the second role satisfies the condition, wherein the sub-condition of the condition requires that the value of the session key match the identifier of the range narrowing strategy specified by the sub-condition.

13. The method of claim 4, further comprising: Allowing the first service to assume the second role while having permission to perform the strict subset of the set of actions on the resource includes: sending a temporary security credential to the first service, the temporary security credential encoding the assuming service having permission to perform the strict subset of the set of actions on the resource.

14. The method of claim 4, wherein the first service 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 to retrieve new messages.

15. A system comprising: A first or more electronic devices are configured to implement a service in a provider network, the service including instructions, when executed, to cause the service to perform the following operations: A license to assume a delegated role, wherein the license is granted by a customer to a delegated service in the provider network, and wherein the assuming service and the delegated service are discrete units of software or hardware functions provided by the provider network, the discrete units being remotely accessible and capable of taking action and updating independently of each other. Send a request to assume the delegated role, the delegated role including a permission policy, the permission policy of the delegated role allowing the assumption of a customer role by the assuming service under a condition, the customer role including a permission policy, the permission policy of the customer role allowing a set of actions for customer resources, the condition requiring that the customer role be assumed if there is permission to perform a strict subset of the set of actions for the customer resources, wherein the strict subset of the set of actions is less than all actions in the set of actions; Send a request to assume the customer role, the request being for assuming the customer role that requests permission to perform the strict subset of the set of actions on the customer resources; as well as Perform a specific action from the strict subset of the set of actions for the resource; A second or more electronic devices are configured to implement a temporary credential service in the provider network, the temporary credential service having instructions, when executed, to cause the temporary credential service to perform the following operations: Receive requests to assume the delegated role; Send temporary security credentials to assume the delegated role; Receive a request to assume the aforementioned customer role; as well as Send temporary security credentials to assume the customer role with permission to perform a strict subset of the set of actions on the customer resources.

16. The system of claim 15, wherein the temporary credential service includes instructions, when executed, to cause the temporary credential service to perform the following operations: Assess the trust strategy of the delegated role in light of requests to assume the delegated role; and The conditions are evaluated in light of the request to assume the aforementioned customer role.

17. The system of claim 15, wherein the instructions configured to perform the specific action within the strict subset of the set of actions on the client resource include: When performed by the undertaking service, the undertaking service further sends an instruction to the service in the provider network to request the execution of the specific action on the customer resource.

18. The system of claim 15, wherein the temporary credential service includes, when executed, further instructions to cause the temporary credential service to perform the following operations: allow the assumption service to assume the second role based on a sub-condition that verifies the value of a session key associated with the request to assume the client role satisfies the condition, wherein the sub-condition of the condition requires the value of the session key to match an identifier of a range narrowing strategy specified by the sub-condition.

19. The system of claim 15, wherein the temporary credential service includes, when executed, further instructions to cause the temporary credential service to perform the following operations: allow the assumption service to assume the customer role based on a subcondition of the condition that verifies the value of a session key associated with the request to assume the customer role satisfies the condition, wherein the subcondition of the condition requires that the value of the session key does not match an account identifier specified by the subcondition.

20. The system of claim 15, wherein the temporary credential service includes, when executed, further instructions to cause the temporary credential service to perform the following operations: allow the undertaking service to assume the customer role based on a sub-condition that verifies the value of a session key associated with the request to assume the customer role satisfies the condition, wherein 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.

Images