Deploying to Root is not possible about aws-control-tower-customizations HOT 10 CLOSED

Hi Lalit

Thank you for your answer! I understand SCP's wouldn't make sense.

Just to give you an idea of what we try to accomplish. We are using Control Tower and CT customized to adhere to all recommendations of the CIS benchmark for AWS (see page 152-154 for summary), and to do that we for example need to apply Config in all used regions on all accounts which include root account. Since we use CT customized to apply Config + rules to all OU's in CT (managed) unsupported regions, it would just be a nice feature for us if we could just add Root to the list of OU's and accounts and provision Config from one location.

I understand if you don't want to include that in your design. I just thought you should know that there are some great use cases for it.

from aws-control-tower-customizations.

Hello Mikkel (@miqueloi) Thanks for reaching out.
Many of the preventative controls wouldn't apply to the Org master account since Service Control Policies (SCPs) are not applicable to this account. Hence, we try to use that account as little as possible.
Hope this helps.

from aws-control-tower-customizations.

+1
We have a business need requiring us to deploy a stack in the master account and we are encountering the same issue.

from aws-control-tower-customizations.

@miqueloi @Wenzil Thanks for sharing your use case.

from aws-control-tower-customizations.

Hi @groverlalit, thanks for your help.

I got a scenario in which I want to deploy an Identity Provider to all accounts, including the Master account.

But this doesn't seem to be feasible with this solution, my suggestions are:

1. Raise an error if master account name/number is listed in the manifest file

...or...

2. Allow Cloudformation Resources to be deployed to the master account if listed in the deploy_to_account.

Thoughts?

from aws-control-tower-customizations.

Hi @groverlalit, thanks for your help.

I got a scenario in which I want to deploy an Identity Provider to all accounts, including the Master account.

But this doesn't seem to be feasible with this solution, my suggestions are:

1. Raise an error if master account name/number is listed in the manifest file

...or...

1. Allow Cloudformation Resources to be deployed to the master account if listed in the `deploy_to_account`.

Thoughs?

+1 I have a customer with the same requirement. It seems that the problem is in the manifest parser. When you try to deploy an stackset using deploy_to_account: the master account is not listed as an active account:

Raising the exception:

raise ValueError("Unsupported deploy_method: {} found for "
"resource {} and Account: {} in Manifest"
.format(resource.deploy_method,
resource.name,
sanitized_account_list))

https://github.com/awslabs/aws-control-tower-customizations/blob/b006bd8342ebf03b9458ec11e794ecb3bbba7845/source/manifest/manifest_parser.py#L120

The real issue is that the method

def get_final_account_list(self, account_list, accounts_in_all_ous,
accounts_in_ou, name_to_account_map):

It does not return the accounts of the Root OU:

https://github.com/awslabs/aws-control-tower-customizations/blob/b006bd8342ebf03b9458ec11e794ecb3bbba7845/source/manifest/manifest_parser.py#L166

Best regards,
Jesus Federico

from aws-control-tower-customizations.

Hi Lalit

Thank you for your answer! I understand SCP's wouldn't make sense.

Just to give you an idea of what we try to accomplish. We are using Control Tower and CT customized to adhere to all recommendations of the CIS benchmark for AWS (see page 152-154 for summary), and to do that we for example need to apply Config in all used regions on all accounts which include root account. Since we use CT customized to apply Config + rules to all OU's in CT (managed) unsupported regions, it would just be a nice feature for us if we could just add Root to the list of OU's and accounts and provision Config from one location.

I understand if you don't want to include that in your design. I just thought you should know that there are some great use cases for it.

@miqueloi just in case you haven't seen it - https://aws.amazon.com/solutions/implementations/aws-security-hub-automated-response-and-remediation/

I know it doesn't solve the complete issue you're having, or cover the full CIS benchmarks, but it's better than nothing

from aws-control-tower-customizations.

I'm running into the same issue. Being unable to deploy IaC in the root account doesn't make sense, especially if I need to add the root account to my monitoring solutions (GuardDuty, etc.) Please add!

from aws-control-tower-customizations.

We're running into this as well.

from aws-control-tower-customizations.

In order for a pipeline to create a stack set instance in the master account, AWSControlTowerExecution role needs to be created manually in the master account.

Here are more details around requirements for the role: https://docs.aws.amazon.com/controltower/latest/userguide/enroll-account.html#enrollment-prerequisitesa

from aws-control-tower-customizations.