AWS Root User Security – the only guide you need

AWS Root User Security – the only guide you need

So you are an Engineer at a software company hosted on AWS public cloud looking to find a strategy to secure AWS Super Admin User aka the Root User, you have come to the right place. In this short but thorough guide, we will explore the security risks of the AWS Root User and the ways to mitigate them using strategies that have been tried and tested at large Cloud software companies.

Is AWS Root User like Linux Root User?

The AWS Root User is the super admin user that gets automatically created as part of the AWS account sign up process. AWS asks for the root user’s email address and password during the account creation process. Due to the nature of the Root user being the single identity with which you start your AWS account, this user has complete access to all AWS services and by design there is no way to reduce the permissions applied to this user. So, yes an AWS Root User is like the Linux Root User which has the highest admin access rights in the AWS system. 

How is the Root User created?

There are two ways to create the Root User –

1. The first time a person manually creates an AWS account, they are asked for a username and password. These credentials are attached to the Root User for the created account and are used for login to the AWS console as Root. 
2. An AWS account can also be created via AWS Organizations using console or cli. When an account is created using this method, AWS creates a Root user for the new account with a long and random password that is neither saved nor provided to the user. If the user wants to use the Root account, they will have to reset its password using the email address provided as part of the account creation.

AWS Root User can be accessed via AWS console and AWS cLI

As part of the AWS account creation, Root User is linked to an email address and password which can be used to login to the AWS console. The other way to impersonate the Root User is via AWS Access keys. Access keys are like username/password but the two elements for using them are called – Access Key ID (similar to username) and Secret Access Key (similar to password). AWS Access keys are auto-generated by AWS but not by default, and they need to be specifically requested by the Root User from the AWS IAM console. An important note from a Security perspective about both the username/password and Access keys is that they are long-term credentials with no expiration by default. 

The security risk associated with Root User is Crazy!

With full AWS access by default and no way to restrict access, the security risk associated with the Root User is crazy. Consider the repercussions of a weak Root User password with no alternate authentication means like MFA, or the exposure of Root User Access keys to public Git repos. The entire AWS account could be under the full control of someone else and they would be able to chaperone cloud resources on your billing. Or worse, get access to any kind of confidential data stored in your AWS resources. 

Do we need to use the Root User? 

Since the privileges associated with Root User cannot be scoped down, the most important security advice for Root User is to not use it for day-to-day activities. We should instead use AWS Identities like IAM User or IAM Role which can be restricted based on least-privilege using IAM Policies. 

If you are a Security maniac, you are probably thinking – If the Root User is so dangerous to keep, why don’t I ask AWS to disable it altogether for my AWS accounts? Firstly, AWS won’t be able to do that for you and secondly, you might need your Root User to perform some actions on AWS which can only be performed by the Root User. This document provided by AWS support contains those specific actions that can only be performed by the Root User – Tasks that require root user credentials. Another reason why you want to hold onto your Root User is in the case of break-glass scenarios. E.g. if the only IAM administrator accidentally revokes their own permissions, you can sign in as the root user to edit policies and restore those permissions.

Pattern #1 of least-maintenance for Root User Security

In this pattern, both primary (console password) and secondary (MFA) authentication is set for the Root User, and then forgotten i.e. not retained anywhere. If you have an existing AWS account, you would have to do the following steps to follow this pattern:

1. Delete all Access Keys associated with the Root User
2. Set a strong password policy in the AWS account so that the future password resets may only be done with a secure password
3. Configure a Software or Hardware-based MFA for the Root User. When configured, delete the account from the MFA Authenticator device so it can never be used. 
4. Reset the password for the Root User with a long and random password which is not brute-forcible by the current technology, and not stored or retained anywhere. 

So in this pattern the Root account is inaccessible for anyone even the account owners, then how would it be used in case of a break-glass scenario? Here lies a loophole in AWS Security where the MFA tied to a Root User can be stripped by AWS Support provided proper verification of the email address and the phone number linked to the Root User. For usage of the Root User in case of break-glass scenarios, the account owners would need to strip MFA for this account with the help of AWS Support.

To summarize this pattern, let’s consider its pros and cons: 

Pattern #2 with more maintenance for Root User Security

In this pattern, the primary authentication (console password) is set for the Root User and then forgotten i.e. not retained anywhere. Then the secondary authentication (MFA) is set for the Root User and stored in a physical safe kept at a secure company location. In order to use the Root account in case of emergencies, we would have to reset the console password and retrieve the MFA code from the secure safe. For an existing AWS account, you would have to do the following steps to follow this pattern:

1. Delete all Access Keys associated with the Root User.
2. Set a strong password policy in the AWS account so that the future password resets may only be done with a secure password.
3. Configure Software or Hardware-based MFA for the Root User. When configured, store the MFA device or the restore codes in a physical safe. To safeguard against lost or inoperable MFA devices, multiple MFA devices should be set up for redundancy.
4. Reset the password for the Root User with a long and random password which is not brute-forcible by the current technology, and not stored or retained anywhere. 
5. Create a secure process to operate the safe in case of break-glass emergency when the Root User needs to be used. This process must involve multiple people so that there is no single point of failure or abuse. 
6. Finally, request your AWS TAM for an under-the-hood AWS feature that provides a mechanism for AWS support to obtain an additional approval from your Leadership team if any request for stripping of MFA is made. 

To summarize this pattern, let’s consider its pros and cons: 

What if your email address and phone number is compromised? 

Even with the above two safeguarding patterns, the security of your Root User depends on the email address and the phone number linked to your AWS account. This means that even if you don’t have a Root User password or MFA token, you can use alternative methods of authentication by verifying your identity using the email address and the primary contact phone number registered with your account. The below two safeguards can be used as defense-in-depth measures in scenarios where both the email address and the phone number linked to account is compromised: 

Defense-in-depth strategy 1 – Security notification for usage of Root User

We can create an email or PagerDuty notification with AWS whenever someone logs in with the Root User. We can use this security event as a means to determine if the login event is legitimate i.e. it occurred as part of our break-glass procedures or if some malicious person used the compromised root email address and the phone number to login with the Root User.

Defense-in-depth strategy 2 – Apply a Service Control Policy (SCP) to disable Root User access

Yes, you read it right, the AWS SCP can restrict Root User access, but a caveat is that this is a partial control because SCPs don’t apply to the Management AWS account (the account with which AWS Organizations is set up). If you are unfamiliar with this topic, take a look at our AWS Organizations and AWS SCP lesson. With this control applied, even if the email address and phone number is compromised, any action with the Root account on any of the accounts with SCP applied would essentially be denied.

In conclusion of this article, I would like to reinstate the fact that the AWS Root account has full AWS account privileges and there is no mechanism to restrict or limit the privileges. It is extremely vital that any Software company hosted on AWS Public Cloud must have a sound Root User security strategy as part of the Privileged Access Management program. In this article, we discussed two patterns to secure the Root User credentials and a couple of defense-in-depth strategies that can together make a comprehensive Root User Security program.