Abstract: A request to add tags (e.g., labels, key-value pairs, or metadata) to resources can be digitally signed by the entity making the request, such that the source can be verified and an authorization determination made for each tag. For a request involving multiple services (or entities) that can each add tags, any tag added by a service can be included in the request and digitally signed by that service. Each service processing the request can also digitally sign the request before forwarding, so that each service signs a version of the request, which includes elements signed by other services earlier in the request chain. When the request is received to a tagging service, the service ensures that every tag was digitally signed by the appropriate authorized entity or service, and validates the signatures to ensure that no data was modified or omitted, before adding the tags to the designated resource(s).

Abstract: User identities can managed at an organization level, instead of across multiple individual resource accounts. In a resource provider environment, access to various resources and services may require users to have identities with specific resource accounts. Users can instead be associated with organization accounts, or virtual accounts that are not associated with specific resources or services. The organization accounts are attached at the appropriate location(s) in an organizational hierarchy. A user having an organization account can project the identity in any sub-account in the organization hierarchy. This can include any lower-level resource account, or can child accounts under a relevant branch of the hierarchy. A user can validate against the organization account, and receive access to the relevant service or resources using the identity projected in the corresponding resource account.

Abstract: A request to modify a set of permissions (e.g., delete the permissions, replace the set of permissions with a different set of permissions) is received at a computing device. A set of services are prevented from using the set of permissions to access resources. The set of permissions are changed while the set of services are prevented from using the set of permissions to access resources.

Abstract: A request to add tags (e.g., labels, key-value pairs, or metadata) to resources can be digitally signed by the entity making the request, such that the source can be verified and an authorization determination made for each tag. For a request involving multiple services (or entities) that can each add tags, any tag added by a service can be included in the request and digitally signed by that service. Each service processing the request can also digitally sign the request before forwarding, so that each service signs a version of the request, which includes elements signed by other services earlier in the request chain. When the request is received to a tagging service, the service ensures that every tag was digitally signed by the appropriate authorized entity or service, and validates the signatures to ensure that no data was modified or omitted, before adding the tags to the designated resource(s).

Abstract: A request to add tags (e.g., labels, key-value pairs, or metadata) to resources can be digitally signed by the entity making the request, such that the source can be verified and an authorization determination made for each tag. For a request involving multiple services (or entities) that can each add tags, any tag added by a service can be included in the request and digitally signed by that service. Each service processing the request can also digitally sign the request before forwarding, so that each service signs a version of the request, which includes elements signed by other services earlier in the request chain. When the request is received to a tagging service, the service ensures that every tag was digitally signed by the appropriate authorized entity or service, and validates the signatures to ensure that no data was modified or omitted, before adding the tags to the designated resource(s).

Abstract: User identities can managed at an organization level, instead of across multiple individual resource accounts. In a resource provider environment, access to various resources and services may require users to have identities with specific resource accounts. Users can instead be associated with organization accounts, or virtual accounts that are not associated with specific resources or services. The organization accounts are attached at the appropriate location(s) in an organizational hierarchy. A user having an organization account can project the identity in any sub-account in the organization hierarchy. This can include any lower-level resource account, or can child accounts under a relevant branch of the hierarchy. A user can validate against the organization account, and receive access to the relevant service or resources using the identity projected in the corresponding resource account.

Abstract: User identities can managed at an organization level, instead of across multiple individual resource accounts. In a resource provider environment, access to various resources and services may require users to have identities with specific resource accounts. Users can instead be associated with organization accounts, or virtual accounts that are not associated with specific resources or services. The organization accounts are attached at the appropriate location(s) in an organizational hierarchy. A user having an organization account can project the identity in any sub-account in the organization hierarchy. This can include any lower-level resource account, or can child accounts under a relevant branch of the hierarchy. A user can validate against the organization account, and receive access to the relevant service or resources using the identity projected in the corresponding resource account.

Abstract: A request to add tags (e.g., labels, key-value pairs, or metadata) to resources can be digitally signed by the entity making the request, such that the source can be verified and an authorization determination made for each tag. For a request involving multiple services (or entities) that can each add tags, any tag added by a service can be included in the request and digitally signed by that service. Each service processing the request can also digitally sign the request before forwarding, so that each service signs a version of the request, which includes elements signed by other services earlier in the request chain. When the request is received to a tagging service, the service ensures that every tag was digitally signed by the appropriate authorized entity or service, and validates the signatures to ensure that no data was modified or omitted, before adding the tags to the designated resource(s).

Abstract: Transitive restrictions can be applied to requests received on a session. A session token can be issued for an active session, and a transitivity setting specified to indicate the types of requests for which the transitive restriction is to be enforced. This can include enforcing the restriction on requests received from outside a trusted environment, requests within a scope of enforcement, or enforcing the restriction at request authentication. Any request received from an untrusted source that fails to satisfy the transitive restriction will be denied. Requests from inside the trusted environment may not have the transitive restriction enforced, such as where a new token is issued. This enables services within the environment to make calls on behalf of the customer, while ensuring that third parties obtaining the session token cannot successfully initiate such calls.

Abstract: A request to add tags (e.g., labels, key-value pairs, or metadata) to resources can be digitally signed by the entity making the request, such that the source can be verified and an authorization determination made for each tag. For a request involving multiple services (or entities) that can each add tags, any tag added by a service can be included in the request and digitally signed by that service. Each service processing the request can also digitally sign the request before forwarding, so that each service signs a version of the request, which includes elements signed by other services earlier in the request chain. When the request is received to a tagging service, the service ensures that every tag was digitally signed by the appropriate authorized entity or service, and validates the signatures to ensure that no data was modified or omitted, before adding the tags to the designated resource(s).

Abstract: A security token service receives a request for a token. The request indicates a set of access control policies that define a set of permissions for access to a resource. The security token service generates the token to comprise a set of identifiers of the set of access control policies. The security token service provides the token in response to the request to enable the token to be used to access the resource in accordance with the set of access control policies.

Abstract: A system and method for generating a policy entitlement map usable to provide a visualization of policies based at least in part on a set of resources of a service of a computing resource service provider, a set of actions that can be taken with the set of resources, or one or more identities. The policy entitlement map may be generated to reflect a set of actions performable by identities of the one or more identities, a set of resources accessible by the identities, or a set of actions that may be performed on the resources.

Abstract: User identities can managed at an organization level, instead of across multiple individual resource accounts. In a resource provider environment, access to various resources and services may require users to have identities with specific resource accounts. Users can instead be associated with organization accounts, or virtual accounts that are not associated with specific resources or services. The organization accounts are attached at the appropriate location(s) in an organizational hierarchy. A user having an organization account can project the identity in any sub-account in the organization hierarchy. This can include any lower-level resource account, or can child accounts under a relevant branch of the hierarchy. A user can validate against the organization account, and receive access to the relevant service or resources using the identity projected in the corresponding resource account.

Abstract: User identities can managed at an organization level, instead of across multiple individual resource accounts. In a resource provider environment, access to various resources and services may require users to have identities with specific resource accounts. Users can instead be associated with organization accounts, or virtual accounts that are not associated with specific resources or services. The organization accounts are attached at the appropriate location(s) in an organizational hierarchy. A user having an organization account can project the identity in any sub-account in the organization hierarchy. This can include any lower-level resource account, or can child accounts under a relevant branch of the hierarchy. A user can validate against the organization account, and receive access to the relevant service or resources using the identity projected in the corresponding resource account.

Abstract: Validated policies can be utilized where information regarding the validation travels with the policies. A policy validator can validate information about a policy, such as may relate to compliance with policy requirements and accuracy of the policy output. Information about the validation, such as one or more claims of validity and information about the validator, can be provided with the policy as metadata, such as in a signature block. The signatures, or other verification mechanisms, can be used to ensure that the policy is not modified after the validation. When attempting to utilize the policy, the signature block can be evaluated along with the policy to determine whether to grant the access. In some embodiments the signature block may not be evaluated with the policy, but may be used subsequently for auditing or compliance determinations.

Abstract: A request to add tags (e.g., labels, key-value pairs, or metadata) to resources can be digitally signed by the entity making the request, such that the source can be verified and an authorization determination made for each tag. For a request involving multiple services (or entities) that can each add tags, any tag added by a service can be included in the request and digitally signed by that service. Each service processing the request can also digitally sign the request before forwarding, so that each service signs a version of the request, which includes elements signed by other services earlier in the request chain. When the request is received to a tagging service, the service ensures that every tag was digitally signed by the appropriate authorized entity or service, and validates the signatures to ensure that no data was modified or omitted, before adding the tags to the designated resource(s).

Abstract: A request to add tags (e.g., labels, key-value pairs, or metadata) to resources can be digitally signed by the entity making the request, such that the source can be verified and an authorization determination made for each tag. For a request involving multiple services (or entities) that can each add tags, any tag added by a service can be included in the request and digitally signed by that service. Each service processing the request can also digitally sign the request before forwarding, so that each service signs a version of the request, which includes elements signed by other services earlier in the request chain. When the request is received to a tagging service, the service ensures that every tag was digitally signed by the appropriate authorized entity or service, and validates the signatures to ensure that no data was modified or omitted, before adding the tags to the designated resource(s).

Abstract: A secure shell (SSH) bastion service can proxy customer SSH traffic through SSH host resources before routing the traffic to the target resource instances in a customer allocation of a multi-tenant environment. The bastion service supports connections directly from a customer allocation management console, which enables the specification of a target instance and selection of an option to establish a secure connection to that instance. The bastion service handles authentication and authorization, ensuring that all security requirements are satisfied. An SSH server of the bastion service can route the traffic to the target instance using the appropriate port for SSH traffic. A second SSH connection is established from the bastion service to the SSH server executing on the target instance, providing end-to-end security of traffic from the client device to the target instance of the customer allocation.

Abstract: A computer-implemented system and method for receiving a request to associate one or more application instance definitions with an application identity of an application configured with a set of permissions to access computer resources in an environment of a computing resource service provider. The system and method cause a computer system to store the one or more application instance definitions in association with the application identity of the application. The system and method also cause the computer system to evaluate a request originating from an application corresponding to the application identity and the application instance definition to determine if fulfillment of the request complies with the permissions.