Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

ECS 3.6.2 Data Access Guide

PDF

Cross account access with AssumeRole

By default, an ECS IAM user in one namespace has no access to buckets in another namespace. However, you can access different accounts using the role trust policy through AssumeRole.

Your account must be trusted by the role to assume a role from a different account. The trust relationship is defined in the role trust policy when the role is created. That trust policy states which accounts are allowed to delegate that access to users in the account. Also, ensure that you have permissions that are delegated from the user account administrator. The administrator must attach a policy that allows you to call AssumeRole for the Amazon Resource Name (ARN) of the role in the other account.

For example, your organization has multiple namespaces. From which, you segregate a staging environment from a production environment. Certain users such as developers from the staging namespace may also want to access the production namespace when you move the staging environment to the production.

  • For this scenario, the admin creates two groups for the staging account namely Dev and QE, and each group has its own policy.
  • In the production namespace, the administrator performs the following:
    • Specifies a trust policy to the role to state that the staging account as a Principal. So that the authorized users from the staging account can use that role.
    • Specifies which role users have read and write permissions to the productionsys bucket through a permissions policy.
    • Shares the namespace and role information with the users who need to assume the role.
  • In the staging namespace, the administrator grants permission to the Dev group to assume the UpdateSys role. By doing this, the Dev group members can switch their role to the required and permitted role. For example, the Dev group members can switch their role to the UpdateSys role in the production namespace. Other users such as QE group members cannot switch their role. Hence, they cannot access the productionsys bucket.

In this process, STS verifies whether the requester is a trusted entity. After verifying, it returns temporary credentials to the authorized users to perform the required actions.

Example
  1. Trust policy for Role in ns1:
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "AWS": "urn:ecs:iam::ns2:root"
          },
          "Action": "sts:AssumeRole"
        }
      ]
    }
    
  2. Policy that is attached to the user in ns2 to AssumeRole:
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Action": [
            "sts:AssumeRole"
          ],
          "Resource": "urn:ecs:iam::ns1:role/assumeRoleCrossAccount",
          "Effect": "Allow",
          "Sid": "VisualEditor0"
        }
      ]
    }
    

Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\