Skip to content

Obviate.io

To anticipate and prevent

  • Home
  • About Us
  • History
  • Privacy Policy
  • Toggle search form

AWS’s root contradiction

Posted on 2017-06-07 By Jon No Comments on 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.

AWS, Cloud, Stupid Companies Tags:amazon, amazon web servicces, AWS, aws organizations, contradictions, i am groot, root users, support

Post navigation

Previous Post: So now I’m printing in PETG?!
Next Post: CoreOS Fest 2017

More Related Articles

Amazon’s desperate Video On Demand promotions Stupid Companies
Wishlist for a “Kindle 3″ Books
Wrapping my brain around DynamoDB Cloud

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

June 2017
S M T W T F S
 123
45678910
11121314151617
18192021222324
252627282930  
« May   Aug »

Copyright © 2022 Obviate.io

Powered by PressBook Premium theme