Open mosh313 opened 2 years ago
@mosh313 thank you for reaching out.
During AFT deployment, AFT uses CT management account as the 'hub' account from where the role assumption takes place into respective accounts ( CT management account is 'Account A' in this case ). Additionally, the AWSControlTowerExecution role in all the target accounts in a CT environment trust the CT management account by default, and you should not need to edit the AWSControlTowerExecution role manually.
Please may you clarify if you are failing to do the initial deployment of AFT in your CT environment? Also, AFT deployment requires you to have AdministratorAccess permissions into the CT management account which vends an AFT module that establishes all infrastructure necessary to orchestrate your AFT requests. Can you confirm that you have AdministratorAccess to the CT management account while performing the AFT deployment?
It would be great if you could elaborate your use case more to help us assist you better.
Thanks for getting back to me Snehal. Yes, this problem is occurring with the initial deployment of AFT. The problem is in Terraform, the provider that builds the terraform is not the CT management account. It assumes the role of the CT management account but in the submodules it cannot assume those roles.
Bug Description We are currently using Terraform Enterprise (TFE) to manage Terraform in multiple accounts. Theres is a central TF role in the TF build account. Then there are terraform roles in every sub account that are assumed by the main build role. When workspaces are made in Terraform enterprise, the provider has the role in the sub accounts and this role has the permissions to execute the terraform code. However, when trying to run the AFT module, because there is a provider block assuming the AWSControlTowerExecution role for the logging and audit account, the original context of the workspace assumed role is lost, and the main TFE role tries to assume this role and is blocked because it is not a trusted entity.
To summarize: Normal TFE use: Main TFE Role A in Account A -> Assumes TFE Role B in Account B -> Terraform executes for Account B
Expected Behavior when running AFT Module: Main TFE Role A in Account A -> Assumes TFE Role B in Account B (In AFT Mngmt Acc) -> Role B assumes AWSControlTowerExecution role in logging/audit accounts and executes terraform code
Actual Behavior when running AFT Module: Main TFE Role A in Account A -> Assumes TFE Role B in Account B (In AFT Mngmt Acc) -> Role A tries to assume AWSControlTowerExecution role in logging/audit accounts and is blocked because only the AFT Mngmt Account is the trusted entity
And I cannot add Account A as a trusted entity to AWSControlTowerExecution because of mandatory guardrails set by control tower.
Relevant logs: 'api error AccessDenied: User: arn:aws:sts::x-x-x-x:assumed-role/(Role A) is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::x-x:role/AWSControlTowerExecution'
Also should be noted that the provider used to run the AFT module uses Role B in the AFT mngmt account, but Terraform Enterprise still uses the main TFE (Role A) to assume providers in submodules.
Any recommendations on how to deal with this?