Hello Team,

I hope you are doing well. I am testing AWS Landing Zone Accelerator and actually faced a lot of issues (Using AWS Organization instead of Control Tower) but I was able to fix it all. However, I am currently stuck with the Bootstrap Phase of CodePipeline. The build stage is returning:

Cannot assume role for 3600 seconds: AccessDenied: User: arn:aws:sts::ManagementAccountID:assumed-role/AWSAccelerator-PipelineSt-AdminCdkToolkitRole292E1-LNLW330962BO/AWSCodeBuild-afe03dcb-5634-43cf-852f-8d5e1e7fbf79 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::SecurityAccountID:role/AWSControlTowerExecution

Although I have disabled Control Tower in the global-config file, "controlTower: enable: false" the Bootstrap is still assuming that the Control Tower IAM Role "AWSControlTowerExecution" is created but this is not the case for me. The Landing Zone Accelerator documentation stated that if Control Tower is not enabled, the default Role "OrganizationAccountAccessRole" would do the job. This role is present in all my org accounts and the master account can assume these roles but still, the bootstrap is expecting the "AWSControlTowerExecution" role.

Apologies for any inconvenience and thank you so much for your support on this.

Thanks,

Describe the bug Creating a stateful firewall rule group fails when using strict order.

To Reproduce Add statefulRuleOptions: "STRICT_ORDER" to a stateful firewall rule group in network-config.yaml.

centralNetworkServices:
  networkFirewall:
    rules:
      - name: firewall-rule-group:
        regions:
          - *HOME_REGION
        capacity: 100
        type: STATEFUL
        ruleGroup:
          rulesSource:
            statefulRules:
              - action: PASS
                header:
                  destination: 10.0.0.0/24
                  destinationPort: '80'
                  direction: FORWARD
                  protocol: TCP
                  source: 10.50.0.0/20
                  sourcePort: Any
                ruleOptions:
                  - keyword: sid
                    settings: ['1']
          statefulRuleOptions: "STRICT_ORDER"

Expected behavior Create a stateful firewall rule group with rule option strict order with no error.

Please complete the following information about the solution:

• [ ] Version: 1.2.2
• [ ] Region: us-gov-west-1
• [ ] Was the solution modified from the version published on this repository? No
• [ ] If the answer to the previous question was yes, are the changes available on GitHub? N/A
• [ ] Have you checked your service quotas for the sevices this solution uses? N/A
• [ ] Were there any errors in the CloudWatch Logs? No

Additional context Attached is the CodeBuild error log. I'm sure that I have the correct code because it failed earlier in the Build stage when, I believe, the solution goes through code verification. I changed the code to the snippet above to get past the error, but now it fails at the Network_Prepare stage of Deploy.

firewall-rule-error.txt

Hi,

I'm trying to deploying the Landing Zone Accelerator in EU-WEST-1. During the CodePipeline Account stage it fails as it is looking for a CDK folder in US-EAST-1. There are only 4 regions listed in the GlobalRegionMap section of the template.

To Reproduce Deploy in any region other than US-EAST-1, US-GOV-WEST-1, US-ISOB-EAST-1 or US-ISO-EAST-1 which are all listed.

Expected behavior Expect LZA to deploy all resources in my EU-WEST-1 not split across EU-WEST-1 and US-EAST-1.

Please complete the following information about the solution:

• [ ] Version: [e.g. v1.2.0]
• [ ] Region: [e.g. eu-west-1]
• [ ] Was the solution modified from the version published on this repository? No
• [ ] If the answer to the previous question was yes, are the changes available on GitHub?
• [ ] Have you checked your [service quotas] yes (https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) for the sevices this solution uses?
• [ ] Were there any errors in the CloudWatch Logs? See screenshots

Screenshots If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context Add any other context about the problem here.

Describe the bug The accelerator pipeline not able to create infrastructure OU on first run.

To Reproduce Pipeline runs the first time

Expected behavior Infrastructure OU is automatically created.

Please complete the following information about the solution:

• [ x ] Version: [e.g. v1.0.1]
• [ x ] Region: ap-south-1
• [ x ] Was the solution modified from the version published on this repository? No
• [ x ] If the answer to the previous question was yes, are the changes available on GitHub?
• [ x ] Have you checked your service quotas for the sevices this solution uses? yes
• [ x ] Were there any errors in the CloudWatch Logs? Nope

Screenshots If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context Add any other context about the problem here.

Describe the bug When choosing Control Tower (CT) to initialise your environment it will propose to create an extra OU which by default is called "Sandbox". But the Installer is expecting it to be called "Infrastructure". It would be great to have it documented.

To Reproduce Follow the LZA doc going the Control Tower way (which only mention "To set up AWS Control Tower, refer to Getting started with AWS Control Tower in the AWS Control Tower User Guide."). Then deploy LZA Installer with CT enabled. It will fail with an error mentioning that "Infrastructure" OU does not exists and found "Sandbox" one instead.

Expected behavior Properly documented setup for CT.

Please complete the following information about the solution:

• [x] Version: v1.3.0

Describe the bug S3 protection gets enabled on guard duty for all account irrespective of settings are disabled on manifest

To Reproduce

1. Disable s3protection on guardduty on manifest

2. It is still comes up as enabled

Expected behavior S3 protection should be disabled

Please complete the following information about the solution:

• [ x ] Version: [e.g. v1.1.0]

To get the version of the solution, you can look at the description of the created CloudFormation stack. For example, "(SO0021) - Video On Demand workflow with AWS Step Functions, MediaConvert, MediaPackage, S3, CloudFront and DynamoDB. Version v5.0.0". If the description does not contain the version information, you can look at the mappings section of the template:

guardduty:
    enable: true
    excludeRegions: []
    s3Protection:
      enable: false
      excludeRegions: []
    exportConfiguration:
      enable: true
      destinationType: S3
      exportFrequency: FIFTEEN_MINUTES

• [x] Region: ap-south-1
• [x] Was the solution modified from the version published on this repository? No
• [x] If the answer to the previous question was yes, are the changes available on GitHub? No
• [x] Have you checked your service quotas for the sevices this solution uses?
• [x] Were there any errors in the CloudWatch Logs?

Screenshots If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context Add any other context about the problem here.

Describe the bug A previous accounts configuration contained a reference to an OU that was then removed from the configuration. The pipeline fails to build at the prepare stack step with the resulting CloudWatch message:

Provisioning failure error message: InvalidParametersException The parent organizational unit 'OUName (ou-afqi-xxx5xxx9)' is not enrolled in AWS Control Tower.

where 'OUName (ou-afqi-xxx5xxx9)' does not exist in any LZ Accelerator configuration file. All accounts to be created are under different existing OUs registered successfully in control tower.

To Reproduce Add an OU to the organization config without creating the OU prior. Add an account to the accounts config that references the OU that does not yet exist. run the pipeline using this configuration Add the OU manually using the console and register it in control tower rerun the pipeline. It will fail with a log message that the parent OU is not registered in Control Tower (even though the OUID number is correct, and control tower shows no issues with the OU. The account is not created. delete the configuration from the account and organization configs rerun the pipeline. The same message occurs the the parent OU is not registered in Control Tower

Expected behavior Expected behavior is that removing the references in the accounts and organization config should remove any artifacts from the pipeline. The pipeline should now run successfully and not try to deploy anything to the previous configuration.

Please complete the following information about the solution:

• [x] Version: [e.g. v1.1.0] v1.1.0

• [x] Region: [e.g. us-east-1]

• [x] Was the solution modified from the version published on this repository?

• no

• [x] If the answer to the previous question was yes, are the changes available on GitHub?

• [x] Have you checked your service quotas for the sevices this solution uses?

• [x] Were there any errors in the CloudWatch Logs? Full CloudWatch log message:

2022-08-18T22:01:10.162Z 913140eb-f4f7-455f-b024-683254d8af17 INFO { RequestType: 'Delete', ServiceToken: 'arn:aws:lambda:us-east-1:1234567891011:function:AWSAccelerator-PrepareSta-CreateCTAccountsCreateCo-jrmzNQRYwAaI', ResponseURL: 'https://cloudformation-custom-resource-response-useast1.s3.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-1%1234567891011%3Astack/AWSAccelerator-PrepareStack-1234567891011-us-east-1/c4f8e500-1f3f-11ed-8673-0a3a69fb2f09%7CCreateCTAccounts3049A752%7Ca9969771-bdaf-4ef7-9671-1ed7d0b05f66?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20220818T220108Z&X-Amz-SignedHeaders=host&X-Amz-Expires=7200&X-Amz-Credential=AKIA6L7Q4OWTVPX5N4HK%2F20220818%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=7bdc2f2642c72e435def6cc5f00f642150aa2e2ef70550b63b6bfbacd729e718', StackId: 'arn:aws:cloudformation:us-east-1:1234567891011:stack/AWSAccelerator-PrepareStack-1234567891011-us-east-1/c4f8e500-1f3f-11ed-8673-0a3a69fb2f09', RequestId: 'a9969771-bdaf-4ef7-9671-1ed7d0b05f66', LogicalResourceId: 'CreateCTAccounts3049A752', PhysicalResourceId: '97fc9681-1857-4b29-b43e-dca64893d3b2', ResourceType: 'Custom::CreateControlTowerAccounts', ResourceProperties: { ServiceToken: 'arn:aws:lambda:us-east-1:1234567891011:function:AWSAccelerator-PrepareSta-CreateCTAccountsCreateCo-jrmzNQRYwAaI', uuid: 'da85c318-59b8-482b-b0fe-53555cad737f' }, IsComplete: true } 2022-08-18T22:01:10.524Z 913140eb-f4f7-455f-b024-683254d8af17 INFO getSingleAccount response {"Items":[],"Count":0,"ScannedCount":0} 2022-08-18T22:01:10.649Z 913140eb-f4f7-455f-b024-683254d8af17 INFO Provisioning failure error message: InvalidParametersException The parent organizational unit 'Sandbox (ou-afqi-hatb5wy9)' is not enrolled in AWS Control Tower. 2022-08-18T22:01:10.649Z 913140eb-f4f7-455f-b024-683254d8af17 INFO Control Tower account provisioning failed 2022-08-18T22:01:10.649Z 913140eb-f4f7-455f-b024-683254d8af17 INFO Error: Accounts failed to enroll in Control Tower. Check Service Catalog Console at Runtime.Nr [as handler] (/var/task/index.js:1:17989) at processTicksAndRejections (internal/process/task_queues.js:95:5) 2022-08-18T22:01:10.649Z 913140eb-f4f7-455f-b024-683254d8af17 INFO Create accounts failed. Deleting pending account creation records

Describe the bug For any change to be deploy after a commit pushed to the aws-accelerator-config codecommit repo I have to click on "Release Change" in console for them to be applied.

To Reproduce Push updates to the config repo. Nothing will happen in pipeline

Expected behavior Automatic trigger of AWSAccelerator-Pipeline on aws-accelerator-config codecommit repo commits.

Please complete the following information about the solution:

• [x] Version: v1.3.0

• [x] Region: eu-west-1

• [x] Was the solution modified from the version published on this repository? No

• [x] If the answer to the previous question was yes, are the changes available on GitHub? -

• [x] Have you checked your service quotas for the sevices this solution uses? Yes

• [x] Were there any errors in the CloudWatch Logs? No

Now that IAM Identity Center (previous AWS SSO) has a proper set of APIs (https://docs.aws.amazon.com/singlesignon/latest/APIReference/welcome.html) it would be great to be able to manage Permission sets, Groups and account associations through LZA config.

It might be integrated in iam-config.yaml file.

Describe the bug Prepare phase fails for existing accounts in existing Landing Zone when added to config.

498 | AWSAccelerator-PrepareStack-036499323218-us-east-1 | 4:44:51 PM | CREATE_FAILED | Custom::ValidateEnvironmentConfig | ValidateEnvironmentConfig/Resource/Default (ValidateEnvironmentConfigB40B464F) Received response status [FAILED] from custom resource. Message returned: Error: Found account with id xxxxx in OU Infrastructure that is not in the configuration.,Found account with id xxxxxx in OU Infrastructure that is not in the configuration. Pipeline: AWSAccelerator-Pipeline Phase: Prepare

To Reproduce Existing landing Zone created in Control Tower. Installed Landing zone accelerator 1.2.2 Modified Config to add existing OU and Accounts (Matching Name and Email)

  enable: true
  organizationalUnits:
    - name: core
    - name: Security
    - name: Development
    - name: Infrastructure
    - name: Network
    - name: Production
    - name: Sandbox
  serviceControlPolicies: []
  taggingPolicies: []
  backupPolicies: []

accounts-config.yaml

  workloadAccounts:
    - name: caplz-security-services
      description: >-
        The security account
      email: xxxxx
      organizationalUnit: Infrastructure
    - name: caplz-shared-services
      description: >-
        The shared services account
      email: xxxxxx
      organizationalUnit: Infrastructure

Both Accounts are indeed in this OU and are registered.

ERROR:

Failed resources:

498 | AWSAccelerator-PrepareStack-036499323218-us-east-1 | 4:44:51 PM | CREATE_FAILED | Custom::ValidateEnvironmentConfig | ValidateEnvironmentConfig/Resource/Default (ValidateEnvironmentConfigB40B464F) Received response status [FAILED] from custom resource. Message returned: Error: Found account with id xxxxx3306 in OU Infrastructure that is not in the configuration.,Found account with id xxxxxx344 in OU Infrastructure that is not in the configuration.

Expected behavior Recognize Account Config as Matching AWS Actual

Please complete the following information about the solution:

• [release/v1.2.2] Version: [e.g. v1.1.0]

• [ us-east-1] Region: [e.g. us-east-1]

• [no] Was the solution modified from the version published on this repository?

• [no] If the answer to the previous question was yes, are the changes available on GitHub?

• [yes] Have you checked your service quotas for the sevices this solution uses?

• [yes ] Were there any errors in the CloudWatch Logs?

Screenshots

Additional context Add any other context about the problem here.

Describe the bug Specifing multiple OUs for a TagPolicy in the organization-config.yaml causes the LZA pipeline to fail in the bootstrap stage with error: undefined.

To Reproduce Steps to reproduce the behavior. Add more than one OU for a TagPolicy taggingPolicies:

• name: TagPolicy description: Organization Tagging Policy policy: tagging-policies/org-tag-policy.json deploymentTargets: organizationalUnits: - Infrastructure - PolicyStaging - Production - Sandbox

Expected behavior A clear and concise description of what you expected to happen. LZA Pipeline to succeed and create the Tagging Policy and attached to passed OUs

Please complete the following information about the solution:

• [ ] Version: 1.2.1
• [ ] Region: us-east-1
• [ ] Was the solution modified from the version published on this repository? No
• [ ] If the answer to the previous question was yes, are the changes available on GitHub?
• [ ] Have you checked your service quotas for the sevices this solution uses? Not a service limit issue
• [ ] Were there any errors in the CloudWatch Logs? No

Screenshots If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context Add any other context about the problem here. Logs from CodeBuild --partition aws [2022-11-11 19:47:45] - info: [toolkit] Executing cdk synth [2022-11-11 19:48:12] - info: [app] Begin Accelerator CDK App [2022-11-11 19:48:13] - debug: [prepare-stack] homeRegion: us-east-1 [2022-11-11 19:48:13] - debug: [prepare-stack] CloudWatch Encryption Key [2022-11-11 19:48:13] - debug: [prepare-stack] Lambda Encryption Key [2022-11-11 19:48:13] - debug: [prepare-stack] Configuration assets creation [2022-11-11 19:48:13] - info: [prepare-stack] Load Config Table [2022-11-11 19:48:13] - info: [prepare-stack] Call create ou construct [2022-11-11 19:48:13] - info: [prepare-stack] newOrgAccountsTable [2022-11-11 19:48:13] - info: [prepare-stack] newControlTowerAccountsTable [2022-11-11 19:48:13] - info: [prepare-stack] Validate Environment [2022-11-11 19:48:13] - info: [prepare-stack] Create new organization accounts [2022-11-11 19:48:13] - info: [prepare-stack] Get Portfolio Id [2022-11-11 19:48:13] - info: [prepare-stack] Create new control tower accounts [2022-11-11 19:48:13] - info: [prepare-stack] Completed stack synthesis [2022-11-11 19:48:13] - debug: [finalize-stack] Region: us-east-1 [2022-11-11 19:48:13] - debug: [finalize-stack] Retrieving CloudWatch kms key [2022-11-11 19:48:13] - info: [finalize-stack] Completed stack synthesis [2022-11-11 19:48:13] - debug: [accounts-stack] Region: us-east-1 [2022-11-11 19:48:13] - debug: [accounts-stack] Enable Service Access for access-analyzer.amazonaws.com [2022-11-11 19:48:13] - debug: [accounts-stack] Enable Service Access for guardduty.amazonaws.com [2022-11-11 19:48:13] - debug: [accounts-stack] Enable Service Access for securityhub.amazonaws.com [2022-11-11 19:48:13] - info: [accounts-stack] Completed stack synthesis [2022-11-11 19:48:13] - debug: [organizations-stack] homeRegion: us-east-1 [2022-11-11 19:48:13] - debug: [organizations-stack] logging.cloudtrail.enable: false [2022-11-11 19:48:13] - debug: [organizations-stack] logging.cloudtrail.organizationTrail: false [2022-11-11 19:48:13] - debug: [organizations-stack] Enable Service Access for access-analyzer.amazonaws.com [2022-11-11 19:48:13] - debug: [organizations-stack] Starts guardduty admin account delegation to the account with email xxxxx account in us-east-1 region [2022-11-11 19:48:13] - debug: [organizations-stack] Guardduty Admin Account ID is xxxxxxx [2022-11-11 19:48:13] - debug: [organizations-stack] Starts SecurityHub admin account delegation to the account with email xxxxxx account in us-east-1 region [2022-11-11 19:48:13] - debug: [organizations-stack] SecurityHub Admin Account ID is xxxxxx [2022-11-11 19:48:13] - info: [organizations-stack] Adding Tagging Policies [2022-11-11 19:48:13] - error: undefined

Bumps json5 from 1.0.1 to 1.0.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

It would be great if we could specify parameters to customizations.cloudFormationStacks. Example:

Example:

customizations:
  cloudFormationStacks:
    - deploymentTargets:
        organizationalUnits:
          - SDLC
      description: Project A - Auto CDK bootstrap stack
      name: cdk-bootstrap-template
      regions:
        - us-east-1
      runOrder: 1
      template: cloudformation-templates/cdk-bootstrap-template.yaml
      terminationProtection: true
      parameters:
        - CDK_VERSION: 2.48.0
        - QUALIFIER: projectA

Would be great to be able to manage groups and users through LZA leveraging identity store API the same way we can manage permission sets and assignments

Is your feature request related to a problem? Please describe. In large environments, running the full pipeline takes hours. This discourage customers to use the native LZA configuration files. It would be nice to be able to run simple changes (e.g. adding a new role, adding a new permissionSet, a new assignment etc.) without having the run the full pipeline (or having to stop its execution once the required stage is finished).

Describe the feature you'd like Being able to re-run a single stage of the pipeline (e.g. security or organization) once a configuration change has been made.

Additional context It's also more environmental friendly and uses less resources ;)

Describe the bug LZA 1.2.2 creates the Config aggregator in the Management Account, and when I set the CloudWatch alarms deployment target to this account, the alarm default action will send the notifications to the SNS topics created in the Audit account.

I received the following error message when I created some events to trigger the alarm: "CloudWatch Alarms does not have authorization to access the SNS topic encryption key."

To fix the issue, I have to update the key "accelerator/kms/sns/key" in the Audit account manually as following.

    {
        "Sid": "Allow_CloudWatch_for_CMK",
        "Effect": "Allow",
        "Principal": {
            "Service": "cloudwatch.amazonaws.com"
        },
        "Action": [
            "kms:Decrypt",
            "kms:GenerateDataKey*"
        ],
        "Resource": "*"
    }

To Reproduce Steps to reproduce the behavior.

Expected behavior CloudWatch should have access to the SNS topic encryption key and the Alarm should be able to send the notifications via the topics created in the Audit account.

Please complete the following information about the solution:

• [x] Version: [e.g. v1.1.0] v1.2.2
• [ ] Region: [e.g. us-east-1]
• [ ] Was the solution modified from the version published on this repository?
• [ ] If the answer to the previous question was yes, are the changes available on GitHub?
• [ ] Have you checked your service quotas for the sevices this solution uses?
• [ ] Were there any errors in the CloudWatch Logs?

Screenshots If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context Add any other context about the problem here.

Describe the bug I appear unable to add customer managed policies to IAM roles.

To Reproduce Try to add a customer managed policy to an IAM role within iam-config.yaml

Expected behavior I am expecting to be able to add customer managed policies to IAM roles. Specifically, I am trying to add the LZA generated Session Manager roles to this specific role.

Please complete the following information about the solution:

• [ ] Version: v1.2.2
• [ ] Region: us-gov-west-1
• [ ] Was the solution modified from the version published on this repository? No
• [ ] If the answer to the previous question was yes, are the changes available on GitHub? N/A
• [ ] Have you checked your service quotas for the sevices this solution uses? N/A
• [ ] Were there any errors in the CloudWatch Logs? No

Additional context

I am trying to create all IAM roles necessary to use EKS in the iam-config.yaml file. I can create multiple IAM roles with no problem. When I add the role with only AWS managed policies there are no problems. If I try the same action with only customer managed polices or with both customer managed polices and AWS managed policies, it fails with no apparent error (see attached CodeBuild logs). I have tried assigning customer managed policies with both arn and name, and both have the same results. I even tried to use the wrong customer managed policy name (as seen in the attached CodeBuild log), and I still have no error in the logs, but end up with a failure.

roleSets:
  # Roles for EKS
  - deploymentTargets:
      accounts:
        - NCCTDev
    roles:
      - name: eksRole
        assumedBy:
          - type: service
            principal: eks.amazonaws.com
        policies:
          awsManaged:
            - AmazonEKSClusterPolicy
      - name: eksNodeRole-temp
        assumedBy:
          - type: service
            principal: ec2.amazonaws.com
        policies:
          awsManaged:
            - AmazonEKSWorkerNodePolicy
            - AmazonEKS_CNI_Policy
            - AmazonS3FullAccess
            - AmazonEC2ContainerRegistryReadOnly
          customerManaged:
            - arn:aws-us-gov:iam::****:policy/AWSAccelerator-SessionManagerLogging-us-gov-west-1
            - arn:aws-us-gov:iam::****:policy/AWSAccelerator-SessionManagerUserKMS-us-gov-west-1

CodeBuild-Output.txt