In this blog post, we show how you can centrally manage root credentials and perform tasks that previously required root credentials across member accounts in your organization.
Centralized root access
This new IAM capability has two features: root credentials management and privileged root actions in member accounts.
Root credentials management enables you to centrally monitor, remove, and disallow recovery of long-term root credentials across your member accounts in AWS Organizations. This helps to prevent unintended root access and improves account security at scale throughout your organization. It helps reduce the number of privileged credentials and multi-factor authentication (MFA) devices that you need to manage.
Note: After you enable root credentials management in your organization, new AWS accounts you create from AWS Organizations will not have a root user password, and will not be eligible for the root user password recovery procedure until you re-enable account recovery.
Privileged root actions in member accounts provide you with a way to centrally perform the most common privileged tasks that previously required root user credentials in your organization member accounts. Your security teams can support your member account users by performing privileged tasks such as unlocking a misconfigured S3 bucket or SQS queue centrally, through short-term (maximum 15 minutes) task-scoped root sessions. You can authorize the root session to perform only the actions that the session was intended for. For example, a root session that you initiate to unlock an S3 bucket policy can only unlock an S3 bucket policy, and cannot be used for other root tasks. The root sessions can only be initiated from your management account or from a delegated administrator account. An IAM principal requires permissions to the new IAM action sts:AssumeRoot in the management account or the delegated administrator account to create a root session.
Service control policies, VPC endpoint policies, and other relevant policies remain effective during the root sessions. For example, you can restrict root sessions to only expected networks.
You can scope temporary root sessions with one of the following AWS managed policies:
policy/root-task/IAMDeleteRootUserCredentials – The root session is scoped to allow the deletion of member root credentials (console passwords, access keys, signing certificates, and MFA devices).
policy/root-task/IAMCreateRootUserPassword – The root session is scoped to allow the creation of a member root login profile.
policy/root-task/IAMAuditRootUserCredentials – The root session is scoped to review root credentials.
policy/root-task/S3UnlockBucketPolicy – The root session is scoped to allow deletion of an S3 bucket policy
policy/root-task/SQSUnlockQueuePolicy – The root session is scoped to allow deletion of an SQS queue resource policy.
Enable centralized root access
In this section, we show you how to enable centralized management of root access. You must be signed in to your organization management account with Organizations admin permissions.
To enable centralized root access (console)
In the IAM console, in the left navigation menu, choose Root access management.
Choose the Enable When you enable centralized root access by using the console, you also enable trusted access for IAM in AWS Organizations.
Figure 1: Centralized root access capability in the IAM consoleOn the Centralized root access for member accounts page, both the Root credentials management and Privileged root actions in member accounts capabilities are selected by default, as shown in Figure 2. As a security best practice, AWS strongly recommends that you delegate the administration of this service to a dedicated member account used by your security team that is separate from AWS accounts that are used to host your workloads or applications. You can also use a delegated administrator account to avoid unnecessary access to your management account.
Figure 2: Enable root access management
Enable centralized root access (CLI)
From the Organizations management account, you can also enable centralized root access from the command line.
To enable centralized root access (CLI)
First, make sure that you’ve updated to the latest AWS CLI so that the new APIs are available.
Next, enable root actions:
aws iam enable-organizations-root-sessions
aws iam enable-organizations-root-credentials-management
To reduce unnecessary access to the management account, delegate the administration of this service to a dedicated Security member account by using the following command. Make sure to replace <MEMBER_ACCOUNT_ID> with the member account ID where the delegated administrator will register.
Centralized root access is now enabled and delegated to a dedicated Security member account. From that account, you can manage root credentials for member accounts or gain short-term task-scoped root access into member accounts in order to perform specific root actions. Sign in to the Security member account to follow the rest of the steps in this post.
Root credentials management
The first feature that we will discuss is root credentials management. Navigate to the new centralized root access management console page as described earlier, and you will see the organizational structure. As shown in Figure 3, there is a Root user credentials field for each AWS account, which tells you if the root user credential is present.
Figure 3: Preview of member accounts with root credential status
From this console page, you can delete or create the root user console password (login profile) for each member account.
To delete or create the root user console password
Under Accounts, select one account and choose the Take privileged action button.
Select either Delete root user credentials or Allow password recovery (for AWS accounts where root credentials do not exist). Note that creating a root user login profile does not restore the previous root user configurations, such as the previously set password and associated MFA device.
Figure 4: The Delete root user credentials feature in the IAM console
Privileged root tasks
After you enable the privileged root actions feature, you (as a security admin) will be able to use the console or CLI to perform privileged tasks such as unlocking S3 bucket or SQS queue policies in member accounts.
To perform privileged root actions (console)
From your delegated administrator account, navigate to the IAM console. In the left navigation menu, choose Root access management.
Select the account where your S3 bucket or SQS queue exists. Then choose the Take privileged action button.
Confirm your intent to delete the resource policy and then choose Delete bucket policy.
Select the privileged task you want to perform on the member account and provide the details of the S3 bucket or SQS queue from which you would like remove the resource policy. In the example in Figure 5, we’ve selected the Delete S3 bucket policy action and entered the URI of the S3 bucket in the member account.
Figure 5: Privileged root actions in the IAM console
To perform privileged root actions (CLI)
From a terminal, update to the latest AWS CLI to make sure that the new APIs are available.
Delete the locked S3 bucket policy, making sure to replace <value> with the name of the bucket:
aws s3api delete-bucket-policy --bucket <value>
Use the following command to load the new credentials in the CLI:
From the delegated admin account, get a root session in a member account by using the STS/AssumeRoot API action, as shown following. The default and maximum duration for the root session is 15 minutes. Make sure to replace <MEMBER_ACCOUNT_ID> with your member account ID.
Now the bucket policy is available, and the bucket owner can write a new policy.
Best practices for centralized root access
This section outlines security considerations for centralized root access and usage of temporary root sessions.
Restrict who can use root sessions
Only grant access to use the new root sessions with AssumeRoot to admins and automations that need access. Within your organization’s management and delegated admin account for root management, only grant sts:AssumeRoot permissions to the persons and automations who need it.
You can further limit the root actions that an admin or automation principal can perform by using the AWS Security Token Service (AWS STS) condition key sts:TaskPolicyArn, as shown in the following policy statement.
Break glass access refers to an alternative method of gaining access for use in exceptional circumstances, such as tasks that can only be performed with root access. When you follow the recommendations for break glass access, root user access is not needed. Review and update your existing procedures that rely on the root user to reduce the dependency of break glass access on root credentials.
Automate routine root actions
Because the centralized root access feature launched with AWS API, CLI, and SDK support, you can build automations to save time and reduce the need for security teams to take manual actions. For example, you can build an Amazon EventBridge integration with your ticketing system, where an EventBridge rule triggers an AWS Lambda function when the queue or bucket owner submits a ticket with approval. The Lambda function then uses a task-scoped root session to delete the policy on an SQS queue or S3 bucket. The diagram in Figure 6 shows an example of this type of automation.
Figure 6: An automation to delete policies on SQS queues or S3 buckets upon ticket approval
The flow of the automation is as follows:
When a ticket to delete a policy on an S3 bucket or SQS queue is approved in your ticketing system, an event is put on the EventBridge event bus and an EventBridge rule is triggered on your delegated admin account.
The EventBridge rule triggers and invokes a Lambda function, passing a copy of the event.
The Lambda function uses the assumeRoot action, with the scope as one of the centralized root access task policies.
AWS STS returns temporary credentials with the scope that was determined in the task policy in the preceding step.
Using the temporary credentials, the Lambda function performs the privileged root action of deletion of S3 bucket or SQS queue policies on your member account.
Review and update your root usage and root credentials management procedures
Now that the tasks that most commonly required root user access (S3 bucket recovery and SQS queue recovery) no longer require long-lived root user credentials, you should revisit your procedures for those use cases and migrate to using root sessions instead of long-lived root users.
Because it is now possible to delete the root user’s login profile, you should revisit the credential management procedures for the root users of your organization’s member accounts. Rather than performing password rotation or MFA device management, you might be able to improve your overall security posture by deleting the root login profile so no credential can be used to access the root user, and no way to initiate the password recovery procedure.
Continue to follow root user best practices for the root user in your organization’s management account
The new capability allows you to more simply manage root credentials from your organization’s member accounts. However, the organization’s management account root user must still exist with a known credential. See the IAM User Guide to learn more about the best practices for managing the organization’s management account root user.
How to remove root credentials in a scalable manner
This section outlines an approach to securely remove your root user credentials at scale. First, get a summary of root credentials for your member accounts. Review the usage of root credentials and identify accounts where root credentials can be safely removed. Then build automation to remove unused root credentials at scale across your member accounts.
Get a summary of root credentials for your member accounts
First, verify whether the root account for your member accounts has credentials before you remove them. If you already have a security admin role in your member accounts, use the getAccountSummary action to audit root credentials. If you don’t have such a role and can’t create an audit role across your member accounts, you can build automation that uses an assume-root session scoped for the IAMAuditRootUserCredentials task to determine whether root credentials exist, and the last time the persistent root credentials were used. The persistent root account can have two types of credentials, password and access keys. You need to check both.
Below is a sample bash script that you can run from your delegated admin account to get a summary of the root credentials on your member accounts.
To use the bash script to get a summary of root credentials
Make sure that you have the AWS CLI installed and are signed in to your delegated admin account using admin role credentials with permissions to the organizations:ListAccounts and sts:AssumeRoot actions.
Save the code that follows to GetRootCredentialsSummary.sh.
The profile used in the scripts is root-access-management. You can modify the scripts to use another profile.
Run GetRootCredentialsSummary.sh on your terminal.
The output will have a .csv file for the root accounts that lists their last login, for both password and access key. Use this information to determine which root accounts are safe to remove. If there is no last-used information, then the credentials are unused, and you can proceed to remove them. If they were used, trace the actions for which they were used in AWS CloudTrail. If the credentials were used for root actions, replace them with an alternative method for member accounts. Identify accounts for which root credentials cannot be removed at this time and need to be excluded from the deletion process.
#!/bin/bash
# Specify the AWS profile to use
AWS_PROFILE="root-access-management"
# Specify the account IDs to exclude (comma-separated)
EXCLUDED_ACCOUNTS="111122223333,444455556666"
# Get the list of accounts in the organization
ACCOUNTS=$(aws organizations list-accounts --profile $AWS_PROFILE --query 'Accounts[*].[Id]' --output text 2>&1) || handle_error $? $LINENO
# Open a CSV file for writing
: > root_user_last_login.csv # Create an empty file
echo "AccountId,MFADevices,AccountAccessKeysPresent,AccountMFAEnabled,AccountPasswordPresent,PasswordLastUsedTime" >> root_user_last_login.csv
# Set the assume-root parameters\
REGION="us-east-1"
TASK_POLICY_ARN="arn=arn:aws:iam::aws:policy/root-task/IAMAuditRootUserCredentials"
# Iterate over each account
while IFS=',' read -r account_id account_name; do
# Check if the account is excluded
if [[ ",$EXCLUDED_ACCOUNTS," == *,"$account_id",* ]]; then
echo "Skipping account $account_id ($account_name) as it is excluded."
continue
fi
# Set the role ARN and session name for the current account
SESSION_NAME="session_${account_id}"
TARGET_PRINCIPAL="${account_id}"
# Assume the role and capture the JSON response
# Assume the role
ASSUME_ROLE_OUTPUT=$(aws sts assume-root \
--profile "$AWS_PROFILE" \
--region $REGION \
--task-policy-arn "$TASK_POLICY_ARN" \
--target-principal "$TARGET_PRINCIPAL" \
--output json )
# Extract the temporary credentials from the JSON response
ACCESS_KEY_ID=$(echo "$ASSUME_ROLE_OUTPUT" | jq -r '.Credentials.AccessKeyId')
SECRET_ACCESS_KEY=$(echo "$ASSUME_ROLE_OUTPUT" | jq -r '.Credentials.SecretAccessKey')
SESSION_TOKEN=$(echo "$ASSUME_ROLE_OUTPUT" | jq -r '.Credentials.SessionToken')
# Export the temporary credentials as environment variables
export AWS_ACCESS_KEY_ID="$ACCESS_KEY_ID"
export AWS_SECRET_ACCESS_KEY="$SECRET_ACCESS_KEY"
export AWS_SESSION_TOKEN="$SESSION_TOKEN"
# Fetch IAM account summary using get-account-summary
iam_summary=$(aws iam get-account-summary --query 'SummaryMap')
# Extract relevant information
mfa_devices=$(echo "$iam_summary" | jq -r '.MFADevices // "No"')
account_accesskeys_present=$(echo "$iam_summary" | jq -r '.AccountAccessKeysPresent // "No"')
# Extract MFA and password status for the root user
mfa_enabled=$(echo "$iam_summary" | jq -r '.AccountMFAEnabled // "No"')
password_present=$(echo "$iam_summary" | jq -r '.AccountPasswordPresent // "No"')
# Get the root user's password last used information
ROOT_PASSWORD_LAST_USED=$(aws iam get-user --query User.PasswordLastUsed --output text 2>&1)
# Unset temporary credentials for security
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN
# Write the account information to the CSV file
echo "$account_id,$mfa_devices,$account_accesskeys_present,$mfa_enabled,$password_present,$ROOT_PASSWORD_LAST_USED" >> root_user_last_login.csv
sleep .1 # Waits 0.1 second.
done <<< "$ACCOUNTS"
echo "Root user last login information has been written to root_user_last_login.csv"
Remove root credentials at scale
After you determine which AWS accounts have persistent root credentials that you want to remove, use the new action, assumeRoot, to access these accounts and remove the root credentials.
Below is a script that will remove root login profiles across your entire organization. You can exclude certain accounts by updating the variable EXCLUDED_ACCOUNTS.
To use the script to remove root credentials
Make sure that you have the AWS CLI installed and are signed in to your delegated admin account using admin role credentials with permissions to the organizations:ListAccounts and sts:AssumeRoot actions.
Save the code that follows to DeleteRootCredentials.sh.
The profile used in the script is root-access-management. You can modify the script to use another profile.
Run ./DeleteRootCredentials.sh on your terminal.
The output will have a .csv file for the root accounts (except the ones in EXCLUDED_ACCOUNTS) with the status for root login profile deletion.
#/bin/bash
# Specify the account IDs to exclude (comma-separated)
EXCLUDED_ACCOUNTS="111122223333,444455556666"
# Specify the AWS profile to use
AWS_PROFILE="root-access-management"
# Set the role name and additional parameters
REGION="us-east-1"
TASK_POLICY_ARN="arn=arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials"
# Function to handle errors
handle_error() {
echo "Error on line $2: Command exited with status $1" >&2
exit $1
}
# Get the list of accounts in the organization
ACCOUNTS=$(aws organizations list-accounts --profile $AWS_PROFILE --query 'Accounts[*].[Id]' --output text 2>&1) || handle_error $? $LINENO
# Open a CSV file for writing
: > root_user_deletion.csv # Create an empty file
echo "AccountId,AccountName,RootUserDeleted" >> root_user_deletion.csv
# Iterate over each account
while IFS=$'\t' read -r account_id ; do
# Check if the account is excluded
if [[ ",$EXCLUDED_ACCOUNTS," == *,"$account_id",* ]]; then
echo "Skipping account $account_id ($account_name) as it is excluded."
continue
fi
SESSION_NAME="session_${account_id}"
TARGET_PRINCIPAL="${account_id}"
# Assume the role
assume_role=$(aws sts assume-root \
--profile "$AWS_PROFILE" \
--region $REGION \
--task-policy-arn "$TASK_POLICY_ARN" \
--target-principal "$TARGET_PRINCIPAL" \
--output json)
# Extract temporary credentials from the assume role response
export AWS_ACCESS_KEY_ID=$(echo $assume_role | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $assume_role | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $assume_role | jq -r '.Credentials.SessionToken')
# Attempt to delete the root user
ROOT_USER_DELETED="false"
if aws iam delete-login-profile ; then
ROOT_USER_DELETED="true"
fi
# Unset temporary credentials for security
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN
# Write the account information to the CSV file
echo "$account_id,$account_name,$ROOT_USER_DELETED" >> root_user_deletion.csv
done <<< "$ACCOUNTS"
echo "Root user deletion results have been written to root_user_deletion.csv"
You can extend this script to delete root access keys by using the delete-access-key command. To do so, you retrieve the list of access keys by using the list-access-keys command, iterate through the list of access keys to determine which keys to delete, and pass the resulting access key IDs to delete-access-key to delete the access keys.
Similarly, you can extend the script to delete MFA devices by doing the following. Retrieve the list of MFA devices by using list-mfa-devices, iterate through the list to determine which MFA devices to delete, and pass the resulting device serial numbers to deactivate-mfa-deviceand delete-virtual-mfa-device to deactivate the MFA devices and further delete the virtual MFA devices.
Conclusion
In this post, we showed you how to enable and use the various features of centralized root access. Additionally, we covered best practices for using this new capability and discussed considerations for adoption.
Oracle Corporation has reported slower-than-expected revenue growth for its second quarter, falling short of Wall Street forecasts and highlighting the
