Dell ObjectScale 1.3 Administration Guide

Same account access with AssumeRole

You can access the same account using AssumeRole by attaching a policy to the user (identical to the previous user in a different account) or by adding the user as a principal directly in the role trust policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "urn:osc:iam::ns1:user/user1"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Cross account access with AssumeRole

By default, an IAM user in one account has no access to buckets in another account. 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 account. From which, you segregate a staging environment from a production environment. Certain users such as developers from the staging account may also want to access the production account 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 account, 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 account and role information with the users who need to assume the role.
• In the staging account, 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 account. 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.