Does gruntwork required aws root account to setup cloud infrastructure in an organisation

[ivishalvarshney]

Dear Team,

I have gone through the document to setup Reference Architecture. I have one concern over the setup that if gruntworks would setup account baseline or landing zone for the organization, does it required aws root account or we can create another account under this root account ?. Since we know AWS does not recommend to provide root account for any services and it could be high security concern.

---

Tracked in ticket #109084

r:terraform-aws-service-catalog

[pete0emerson]

The command line tooling that we strongly recommend you use leverages your root account in order to create the necessary accounts under it, but does not make any changes to the root account itself. This is also done by you in your environment, and not by us. When the accounts are handed over to us for Reference Architecture provisioning, we can only access and modify the (usually six) accounts specific for the Reference Architecture, and cannot access your root account (or any other accounts under your root account).

AWS doesn't permit you to create multiple levels of accounts, so you can't create an account under your root account and then create the reference architecture accounts under that account.

[ivishalvarshney]

Dear @pete0emerson,
Our organization is already running a production grade aws account for previously running applications. If we provides root access to any vendor or third party service it would be very high security concern. Or we need to create another root account for gruntworks and manage multiple aws root account. What do you suggest.?

[pete0emerson]

The command line tooling (source code here) that we recommend that you use is used by you, with IAM user credentials that you provide it. You never turn those credentials over to us, they always remain in your full control.

If you really want to, you can analyze the CLI code to make sure that we're not doing anything sketchy. If this is still not acceptable to your company, then it is possible to bootstrap manually and then hand over the created AWS accounts (not the root account) to us to deploy into.

A few notes, here:

1. The CLI we provide to you (which only uses your root account to create the sub-accounts underneath) is the fastest and most reliable way to get your accounts ready for us to provision. We have seen over and over customer's missteps / mistakes / et cetera that ultimately slows things down and causes a lot of back and forth to try to sort things out. That's why we've created the CLI.

2. If you create an IAM user, grant it Administrator Access, and then run the CLI, you can immediately revoke / roll the credentials afterwards. The window of opportunity for something nefarious to happen would be small. I suppose (to be the devil's advocate) that the CLI tooling could create a new user with administrator privileges to try to be evil, but now we're really playing cat and mouse! We do none of these things. But my saying so may not be a strong enough requirement for your company.

3. Another alternative would be to create a new root account, as you suggest. This doesn't seem like a great option to me, but I'm on the outside looking in.

I hate to make a real suggestion to you, because I don't know your company policies, but when I read this:

If we provides root access to any vendor or third party service it would be very high security concern.

my reaction is: you're not providing root access to us. However, you are providing root access to some tooling which was written by us. Is this acceptable? That's for you to decide.