Assigning users with no permissions administrator credentials

The need arises at times to give sets of permissions to IAM users that are different from what they are already assigned. These users can assume a role with the relevant permissions and STS provides temporary access to the services.

1. About STS

AWS STS (Security Token Service) is used to request temporary credentials for IAM users (real users or roles) or federated users (who log in to AWS using credentials for services other than AWS).

STS has several APIs for various use cases.

I’ll discuss one use case of the AssumeRole API below.

2. AssumeRole

When the AssumeRole API is called, STS will return an access key, a secret access key and a security token. The token expires in one hour by default but this can be changed. The maximum duration for the session is 12 hours.

It’s also possible to attach inline and managed policies to the API call but I won’t do this in this post.

3. Example: Assume administrator role through AssumeRole API

It’s a good practice to limit the number of administrators for an account and protect these users with extra authentication (MFA).

Sometimes a user might need elevated access or permissions to services they are not allowed to access otherwise.

In this case, temporarily assuming a role with the required permissions is the recommended approach (instead of directly giving the user elevated access and then revoke it later).

This workflow includes the user who needs the new access, the role that is temporarily assumed and trust policies which allow the user to assume the role (both on the user and the role side).

In this example, the user with no permissions will assume administrator role in the same account but only if they have MFA enabled. The principle is the same for cross-account access, the only difference is that the account numbers need to be changed in the trust policies accordingly.

4. Let’s do it

Here’s the process step-by-step.

4.1. Create the trust policy for the user

First, let’s create a policy called AssumeAdminRolePolicy, which will be assigned to the group containing our user.

The policy looks like this:

  "Statement": [
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/Administrators"

As it can be seen, the Action (what is Allowed to be done) is AssumeRole, so this policy will allow IAM users from the account 123456789012 to assume the role called Administrators.

4.2. Create a new user and add it to the group

A new user or an existing one with no admin access will do the job. The best way is to create a new user, which, by default, has no permissions at all.

It’s also a best practice to create an IAM group, which is a collection of users. This way, permissions are easier to manage because there’s no need to assign permissions to many different users individually. Permissions can be added to groups, and users in the group will inherit these permissions.

So let’s create a new group called CanAssumeAdmin and add the AssumeAdminRolePolicy (this was created in 4.1) to it. Add the new user to the group.

Now all users in the group have the permission to assume the Administrators role from the account owner (or the administrator).

4.3. Create the Administrators role

Let’s create a new role called Administrators. Attach the AdministratorAccess managed policy to it, which gives full access to all AWS services (excluding some tasks which need root user access).

In the Trust Relationships section, add the following policy to the role:

  "Version": "2012-10-17",
  "Statement": [
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"

This trust policy Allows the users of account 123456789012 to assume the Administrators role only if they have MFA enabled (Condition section).

4.4. Try it out

Log in to the Console with the new user’s credentials.

Since the user has no permissions, it cannot do anything - yet.

Click on the top-right corner where the username and the account number can be seen. Towards the bottom of the dropdown menu, there is a link called Switch Role.

Enter the account number (123456789012 in this example, enter your account number here) and the name of the role Administrators, and then click Switch Role.

The user will assume the Administrators role for the next hour and they can do what they need to in the account.

When an IAM user assumes a role, their original permissions will be lost for that time period. Here, there’s nothing to lose because the user had no permissions, but in many cases users have a different sets of permissions which they won’t be allowed to use while they are assuming the role.

To abandon the role, just click on the Back to USERNAME item in the top-right corner menu.

5. Summary

Assuming a role, especially if it has elevated permissions is a best practice AWS recommends instead of individual users getting the access assigned.

STS is the service, which provides temporary permissions to users to assume the roles through the AssumeRole API.

The methodology described above can be used for both same account and cross account access.

Thanks for reading and see you next time.