Open kisst opened 1 month ago
Are you using Control Tower ?
If so, you have to set this in global-config.yaml
managementAccountAccessRole: AWSControlTowerExecution # UPDATE: If using Control Tower, set to AWSControlTowerExecution
And set the useManagementAccessRole to true:
cdkOptions:
useManagementAccessRole: true
customDeploymentRole: AWSAccelerator-PipelineRole # UPDATE: If using a custom AcceleratorPrefix in the installer stack, this need to be updated accordingly
No Control Tower, in use in this install in the meantime I opened a support ticket within the effected AWS account as well, where the workaround suggested by the support was to create this Org role in the Master account too by hand while the fix is being worked on, as apparently this error is observed in other installations too..
We are running into a similar issue. We've got customizations cloudformation stacks with target:
deploymentTargets:
organizationalUnits:
- Root
which deploys the stack to all member accounts + the management account.
So far it behaved correctly and did assume-role for the member accounts and for the management account assume-role was skipped.
However somehow for the latest pipeline run LZA tries to do an assume role on the AWSControlTowerExecution
role when deploying to the management account.
The interesting thing is that we haven't updated the LZA version.
This is the diff of the change that triggered the new behavior which seems rather unrelated:
diff --git a/security-config.yaml b/security-config.yaml
index a0bf456..a07939c 100644
--- a/security-config.yaml
+++ b/security-config.yaml
@@ -26,38 +26,8 @@ centralSecurityServices:
destinationType: S3
exportFrequency: FIFTEEN_MINUTES
securityHub:
- enable: true
- regionAggregation: true
- excludeRegions: []
- standards:
- # https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html
- - name: AWS Foundational Security Best Practices v1.0.0
- deploymentTargets:
- organizationalUnits:
- - Root
- enable: true
- controlsToDisable:
- - IAM.6
- - Inspector.1
- - Inspector.2
- - Inspector.3
- - Inspector.4
- - GuardDuty.1
- - GuardDuty.5
- - GuardDuty.6
- - GuardDuty.8
- - GuardDuty.9
- - GuardDuty.10
- - Macie.1
- - name: CIS AWS Foundations Benchmark v1.2.0
- deploymentTargets:
- organizationalUnits:
- - Root
- enable: false
+ enable: false
+ standards: []
ssmAutomation:
excludeRegions: []
documentSets: []
Describe the bug
As per the above error message, for some reason the deployment of the Logging stack running within the management account itself, is trying to use the
managementAccountAccessRole
within the accountTo Reproduce Unsure what's changed, rebuild it with an older version of the config zip ( one which run before ) and it failed this time, no changes in the account, or in the config.
Please complete the following information about the solution:
Additional context After a full pipeline run, made a single line change in iam, tried to deploy it, but it failed on logging, so after reading the logs, I tried rolling back the config change, and rebuild, but it still failed.