AWS Root Access Management: The Full Picture

ChangeLog:

• Dec 17 2024: Minor changes to Section 1.

/0 Intro

AWS Root Access Management was released in November 2024 with many new side-car elements such as "sts:AssumeRoot", root-session IAM policies, and a "sts:TaskPolicyArn" condition key. We can expect more components to be released in the future, but this post will focus on how Root Access Management currently works as of Dec 3, 2024.

I am very excited about this long-awaited feature, but we should always be aware of the security implications and risks associated with any new feature or service, even if it is part of the core IAM and STS services themselves. This one is no different, so let's dive into the nitty-gritty details!

/1 Getting Started

As a prerequisite to this article, I highly recommend reading the official AWS documentation for this new feature here and here, as well as checking out the following AWS blog post.

Speaking of AWS blogs, we all enjoy reading them for their value and extensive background experience. However, after reading countless AWS blogs over the years, I have been dismayed to realize that they tend not to paint the "big picture". They often gloss over or overlook important drawbacks of the features being discussed, while the caveats regarding potential security risks and threats associated with deploying these solutions are not always as clear as they should be.

When we read AWS blogs, we are not just looking for a marketing how-to. As an AWS Community Builder, I feel strongly about presenting the unfiltered feedback of the good, the bad, and the ugly of new or existing features and services so that AWS customers can make better informed decisions early on in the evaluation process about whether or not to implement a feature. This goes hand in hand with the AWS Leadership Principles of Earning Trust, Customer Obsession, Ownership, and so on.

Many in the cloud industry share this sentiment, so hopefully this friendly complaint will be addressed in future AWS blogs. AWS documentation is better in this regard, with lots of useful "be careful" warnings in the right places.

/2 Root Access Management: Beyond the basics

Root Access Management helps to manage root user access in all member accounts of an Organization.

It does not remove (or even disable) the root user itself in member accounts, but rather keeps root users under control by removing their access credentials. After Root Access Management is enabled, root users are controlled by both the AWS Organization Management account and the delegated Admin account. This finally provides a centralized solution for root user access across the entire Organization.

Root Access Management relies heavily on the new sts:AssumeRoot permission and related APIs to work its magic, as we will see in the following sections. sts:AssumeRoot provides temporary and special "root-sessions" that can be used in member accounts.

sts:AssumeRoot cannot be used by a member account on itself, or any other child account. It is also very important to note that sts:AssumeRoot does not provide all the "full" root user privileges to its target accounts, but only 5 privileged and temporary "root-sessions" consisting of the following actions:

1.?????? IAMAuditRootUserCredentials

2.?????? IAMCreateRootUserPassword

3.?????? IAMDeleteRootUserCredentials

4.?????? S3UnlockBucketPolicy

5.?????? SQSUnlockQueuePolicy

More on this in the sections below.

/3 Root Access Management: Existing Deny-Root SCP in our AWS Organization

Prior to Root Access Management, many AWS organizations deployed SCPs to deny the use of root users for all member accounts in their AWS organization, such as the following:

{
  "Version": "2012-10-17",
  "Statement": [

    {
      "Action": "*",
      "Resource": "*",
      "Effect": "Deny",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:root"
          ]
        }
      }
    }
  ]
}        

However, the above SCP will interfere with the core features of Root Access Management’s core features, especially AssumeRoot.

In this case, it is highly recommended to try Root Access Management on a test AWS Organization that does not have such an SCP, and to test out this feature along with AssumeRoot before deploying it to a production AWS Organization.

/4 Root Access Management: Admins and the Root user in the Master Account

All Administrators, as well as the root user in the Management account, can enable and disable Root Access Management. The Administrators of the Management account are allowed to use any root-sessions associated with the sts:AssumeRoot API itself on target member accounts.

Since we can't apply SCPs to the Management account, it is not possible to prevent Administrators (or the root user) from enabling or disabling Root Access Management.

Needless to say, if an AWS Organization's Management account has too many Administrative services, users, or roles, we should be careful and perform a cleanup first (regardless of whether Root Access Management is enabled or not).

The Management Account root user itself is not affected by the entire Root Access Management solution, and still needs to be protected and guarded with care.

Speaking of the Management Account's root user, while it can enable and disable Root Access Management itself, it won't be able to use any of the sts:AssumeRoot features and privileged root-sessions. Attempting to do so will quickly remind us that the root user cannot use AssumeRoot, mainly because it cannot perform an AssumeRole:

/5 Root Access Management: Restricting AssumeRoot through SCPs

The previous section really highlights the need to include the Delegated Admin account for Root Access Management. Since the Delegated Admin account itself can have an SCP attached to it, we are able to implement a much more fine-grained solution overall. Let's look at some real-world examples.

The following SCP, when attached to the Delegated Administrator account for Root Access Management, allows only the administrators of the delegated account to perform the four root-session actions listed. It also allows all other users who have sts:AssumeRoot + IAMAuditRootUserCredentials in their identity policy, to audit the root user credentials of all member accounts.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SCPForAssumeRoot",
      "Effect": "Deny",
      "Action": "sts:AssumeRoot",
      "Resource": "*",
      "Condition": {
        "ArnEquals": {
          "sts:TaskPolicyArn": [
            "arn:aws:iam::aws:policy/root-task/IAMCreateRootUserPassword",
            "arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials",
            "arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy",
            "arn:aws:iam::aws:policy/root-task/SQSUnlockQueuePolicy"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::111222333444:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AdministratorAccess_000ABCD"
          ]
        }
      }
    }
  ]
}        

We can modify the behavior of the above SCP to add more excluded IAM principals (e.g., for administrative purposes), or modify the list of TaskPolicyARNs to suit our specific needs. Note that if AWS releases additional root task policies in the future, they will need to be added to this SCP, in order for them to be denied.

Another approach is to use an SCP to restrict all IAM principals (including Admins) of the delegated Admin account for Root Access Management to only run "AuditRootUserCredentials", effectively denying all other AssumeRoot actions, in which case only the Management account can perform them. Here is such an SCP:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SpecialSCPForAssumeRoot",
      "Effect": "Deny",
      "Action": "sts:AssumeRoot",
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "sts:TaskPolicyArn": "arn:aws:iam::aws:policy/root-task/IAMAuditRootUserCredentials"
        }
      }
    }
  ]
}        

As we can see, using a delegated Administrator account for Root Access Management is highly recommended if we want more flexibility in using this feature and, by extension, Assume-Root.

/6 Root Access Management: AssumeRoot vs CloudTrail Logs

Based on the tests in the previous sections, I found Enable(Disable)OrganizationsRootCredentialsManagement, Enable(Disable)OrganizationsRootSessions, AssumeRoot (for IAMAuditRootUserCredentials), all under the Management account CloudTrail logs.

Running AssumeRoot with "IAMAuditRootUserCredentials", "IAMAuditRootUserCredentials", or even "S3UnlockBucketPolicy" will create CloudTrail entries in both the Management and the target member accounts.

For "IAMAuditRootUserCredentials", the target member account will have an "AssumeRoot" event for "DeleteLoginProfile", with "root" as the user and "iam.amazonaws.com" as the EventSource.

For "S3UnlockBucketPolicy", the target member account will have an "AssumeRoot" event, and another CloudTrail entry for "DeleteBucketPolicy", run by the root user itself.

/7 Root Access Management: Suggestions and improvements

I am confident that more privileged root-sessions and/or capabilities will be added in the future. However, even the current root-session actions do not scale well. For example, to delete "RootUserCrendentials" on target member accounts, we have to use the following API:

  assume-root
--target-principal <account_id>
--task-policy-arn "arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials"         

As far as I can tell, this STS-based API does not scale well when we need to run it across 800+ AWS accounts, requiring a script to feed it a list of account numbers and some automation with error handling. We all know how we feel about security features and scaling: if it does not scale well natively, it hinders operations and the very benefits it is trying to provide.

/8 Conclusions

Overall, Root Access Management is a nice, powerful feature, as long as we are fully aware of the fine print details and the administrative changes it brings. It gives the Administrators of the Management Account more root user capabilities on member accounts, which they did not have before.

However, it is important to note that Root Access Management does not completely remove all current dependencies on root users for member accounts. Using Root Access Management adds many more necessary steps to reset root user login passwords, if these missing dependencies need to be run on individual member accounts.

It should also be noted that the currently supported AssumeRoot tasks can only be performed by the Administrators of the Management account or the designated principals of the delegated Admin account.

All of this places a much greater operational burden on the Administrators of the Management account, especially when their time is valuable and their resources are limited.

Time will tell if Root Access Management, along with the additional operational overhead for the administrators of the management account (as well as the delegated admin account), is a trade-off that makes sense for AWS organizations with hundreds or thousands of AWS accounts.

Finally, Root Access Management works well with Control Tower or similar Account Vending Machines to automatically remove root user access from newly vended AWS accounts, enforcing compliance across the board.

Acknowledgments:

Thanks to Brendan Sherman for his valuable suggestions and peer review.

Thank you, Merci, for reading and I hope you enjoyed this article! To check out all the other articles, click here.