June 7, 2017

540 words 3 mins read

AWS's root contradiction

If you work in the cloud, you’ve probably got an AWS account. It’s not just any account though, it’s the magical “AWS Root Account”. With this root user account, you are imbued with the god-like power to create worlds and smite instances. Your power is only limited by the thickness of your wallet (and the built in service limits). Of course such power should be reserved for only the most special occasions which is why the very first recommendation of AWS root accounts is to create an IAM user, then don’t use your root account.

The Account Root User best practice guide states that you only use your root account for a very select set of tasks that require said root account. This seems like a simple enough concept except there are major flaws with this plan.

The first that as in real-world-practice Amazon recommends you actually never use root. If you’re concerned with root account security, AWS Support will tell you to set a really long password and MFA… then lose both credentials. The forums are filled with posts of similarly worded suggestions. If you use AWS Organizations to create new accounts, it will do so with the assumption that you’ll actually only use those accounts via IAM assume role (ex: There is no way to set the root account password).

The second is that the “very select set of tasks” is actually a number of items that you might need to do on a fairly regular basis. Maybe it’s not “typical” for a large enterprise but when you’re a small and growing business it’s not unusual to need to change the billing setup — which needs root. Anything related to changing your support plan — needs root. Domain transfers — needs root. Don’t forget penetration testing, which most companies do at least yearly, but most do much more frequently — needs root.

This really frustrates me the most when it comes to AWS Organization spawned accounts. You can create them via API, they come with IAM assume role permissions, you can setup IAM to access the accounts. It’s a nearly perfect system, but certain features like SUPPORT are account specific. If you don’t mine the $100/mo/account cost, you could in theory get support on every account. But the catch is you can’t sign up for support in anyway except for using the root user of each account… which you don’t have (because you never gave it a password previously). So instead of having a root-less account, one needs to go through the trouble of first setting up root on each account, then subscribing to support, then setting up security on the root for every account.

Oh, and don’t think that you’ll be more clever than AWS and simply file a ticket in the AWS Organization master because they won’t provide cross account support. Even if you own all the accounts (because it’s AWS Organizations and comes with consolidated billing by default), even if you’ve got the power of our dear and fluffy lord, they will not help you across accounts.

So remember you MUST setup root on every AWS account. You MUST secure root on every AWS account. However you SHOULD lose the credentials and NEVER use root.