One of the standout features announced by AWS in 2024 is the ability to control root access keys for all accounts within the Landing Zone using the IAM service. This centralization offers significant benefits for managing security at scale.

Centralized Root Access

By centralizing root access, you can effectively remove and prevent root user credential recovery and access across all accounts enrolled in the Organizations service. This means:

• Deleting Root User Credentials: you can remove root user passwords, access keys, signing certificates, and deactivate and delete multi-factor authentication (MFA). New accounts created in Organizations will have no root user credentials by default, enhancing security.

• Performing Privileged Tasks: some tasks require root user credentials, but these can now be managed by the management account or a delegated IAM administrator. This allows for secure, controlled access to perform necessary actions without compromising security.

Enabling Account Recovery

If root user credential recovery is needed, the Organizations management account or a delegated IAM administrator can enable the Allow password recovery privileged task. This allows the person with access to the root user email inbox to reset the password and recover credentials. It's recommended to delete root user credentials once the required task is completed to maintain security.

Short-Term Privileged Sessions

AWS now allows for short-term privileged sessions, giving temporary credentials to perform specific root user tasks on member accounts. These sessions enable actions such as:

• Deleting misconfigured Amazon S3 bucket policies

• Deleting misconfigured Amazon SQS queue policies

• Managing root user credentials for member accounts

However, one feature I would love to see is the ability to update unmanageable KMS policies directly. Currently, administrators must log in as the root user, create a support ticket, and have AWS Support grant temporary permissions. For instance, if a key policy grants access to only one user and that user is deleted, the key becomes unmanageable, requiring AWS Support intervention.

Since I was excited to give it a try and remove all the console credentials and the MFA devices registered, I looked into how to create a bash script using AWS CLI to go over all accounts in my organization, check if there's a Console Password set and remove it. The same goes for the MFA Devices for each root user.

The bash script can be found here. It iterates over all accounts in the organization, assumes the IAMDeleteRootUserCredentials
role in each child account, checks if there's any login profile and deletes it for the root user using the delete-login-profile command. Next, it lists the MFA registered devices for the root user using the
list-mfa-devices command and deactivates them using the
deactivate-mfa-device command. Interestingly, you don't need to delete the existing MFA devices; you need to deactivate them. This isn't specified in the official documentation, or I missed it.

The script uses the credentials from the organization account as initial credentials to further assume the IAMDeleteRootUserCredentials role in each child account. If you manage the root credentials for your company, you probably know what I'm talking about.

To make granular changes, I've used the OU ID parameter (PARENT_ID) so you can start with your sandbox and non-prod accounts. This is the only thing you need to change in the script before running it.

Another thing worth mentioning is that the aws sts assume-role command needs the region specified, as STS uses regional endpoints. Also, the --task-policy-arn option has a strange syntax: "arn=arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials". Notice it starts with arn=arn, which is a terrible way of doing it. I honestly have no idea why the service team implemented it this way.

If your teams are using GuardDuty for monitoring suspicious activity in their accounts, you might want to give them a heads-up as the deletion of the root credentials will trigger an alert of Policy:IAMUser/RootCredentialUsage type which looks like this:

The API GetAccountSummary was invoked using root credentials from IP address

This feature greatly enhances the ability to manage and secure AWS environments effectively, ensuring that root access is controlled and monitored at all times.

Have you tried this new feature? What do you think about it?