aws-solutions / aws-control-tower-customizations Goto Github PK

In addition to S3, and the newly added CodeCommit source providers, I would like to see GitHub be added too for those of us using GitHub instead.

You should be able to select "GitHub" in the CodePipelineSource parameter, and then have a choice if you want to "Poll" or if you want a "Webhook" to be created. A parameter for the GitHub token secret should also be added.

Hi @georgebearden @leavertj

I would like to inform you that the step function failed due to AWS CloudFormation causing the error "Canceled since failure tolerance has exceeded".

{ "RequestType": "Create", "ResourceProperties": { "StackSetName": "CustomControlTower-ipsense-cloudzoom", "TemplateURL": "", "Capabilities": "CAPABILITY_NAMED_IAM", "Parameters": {}, "AccountList": [ ], "RegionList": [ "us-east-1" ], "SSMParameters": {} }, "params": { "ClassName": "CloudFormation", "FunctionName": "describe_stack_set_operation" }, "LoopFlag": "not-applicable", "StackSetExist": "no", "StackSetStatus": "success", "CreateInstance": "yes", "DeleteInstance": "no", "ActiveAccountList": [ ], "ActiveRegionList": [ "us-east-1" ], "OperationId": "70a507fe-bcd7-47a7-ad26-0d3935f55e96", "RetryDeleteFlag": false, "OperationStatus": "FAILED", "us-east-1": "Cancelled since failure tolerance has exceeded" }

Thank you very much for the solution created

When i use the manifest version 2021-03-15 present in documentation like:

region: ap-southeast-2
version: 2021-03-15
...
CodeBuild failed to validate the manifest:

ERROR - validation.invalid
ERROR - --- All found errors ---
ERROR - ["Enum '2021-03-15' does not exist. Path: '/version' Enum: [datetime.date(2020, 1, 1)]", "Key 'resources' was not defined. Path: ''"]
...

this shouldnt fail?

In manifest_parser.py, the get_final_account_list() method has a logic error. the statement below is checking for name.lower() in the string key.lower(). the problem arises when you have an account name that is a subset of another account name. I have one account named "aws-ct" and one account named "aws-ct-master". when I specify "aws-ct" as a deploy_to_account, the logic in the statement below matches both "aws-ct" and "aws-ct-master" which is deploying the resource to both accounts, even though only the "aws-ct" account is listed in manifest.yaml. see the snipped below from my cloudtrail logs that show the name_to_account_map object.

    if name_list:
        # convert OU Name to OU IDs
        for name in name_list:
            name_account = [value for key, value in
                            name_to_account_map.items()
                            if name.lower() in key.lower()]
            self.logger.info("%%%%%%% Name {} -  Account {}"
                             .format(name, name_account))
            new_account_list.extend(name_account)

2020-12-10T09:31:29.382-08:00 | {"time_stamp": "2020-12-10 17:31:28,252","log_level": "INFO","log_message": Print Account Name > Account Mapping}
-- | --
  | 2020-12-10T09:31:29.382-08:00 |  
  | 2020-12-10T09:31:29.382-08:00 | {"time_stamp": "2020-12-10 17:31:28,253","log_level": "INFO","log_message": {
  | 2020-12-10T09:31:29.382-08:00 | "aftest3": "",
  | 2020-12-10T09:31:29.382-08:00 | "Audit": "",
  | 2020-12-10T09:31:29.382-08:00 | "aftest2": "",
  | 2020-12-10T09:31:29.382-08:00 | "Log archive": "",
  | 2020-12-10T09:31:29.382-08:00 | "account-factory-new-acct-lab": "",
  | 2020-12-10T09:31:29.382-08:00 | "route53": "",
  | 2020-12-10T09:31:29.382-08:00 | "aws-ct": "",
  | 2020-12-10T09:31:29.382-08:00 | "aws-ct-master": ""
  | 2020-12-10T09:31:29.382-08:00 | }}```

I've found execution fails at the SCP stage, and never continues on to the Stack Set build, if it encounters an OU listed in the manifest.yaml that does not exist. This prevents a use-case we are interested in, where we are planning to build multiple new OU's so add them all to the manifest preemptively. Ideally the stack would continue on to the OU's that do exist at the time instead of failing completely. This would also apply to the Stack Set build pipeline; if it doesn't find the account, log an error but continue on with the accounts that do exist at the time.

`Error

ValueError
Cause

{
"errorMessage": "OU id is not found for NTI",
"errorType": "ValueError",
"stackTrace": [
" File "/var/task/state_machine_router.py", line 204, in lambda_handler\n return service_control_policy(event, function_name)\n",
" File "/var/task/state_machine_router.py", line 69, in service_control_policy\n response = scp.list_policies_for_ou()\n",
" File "/var/task/state_machine_handler.py", line 940, in list_policies_for_ou\n raise ValueError("OU id is not found for {}".format(ou_name))\n"
]
}`

AWS supports Organizational Units to a depth of 5. Organizational Units may be specified as the target for deployment of SCPs, but only at the level directly beneath the root of an Organization.

A delimiter character is mentioned in one test file, but the feature is not implemented.

Are you looking into supporting this?

https://aws.amazon.com/de/blogs/aws/new-use-aws-cloudformation-stacksets-for-multiple-accounts-in-an-aws-organization/

Hello Team,

Nice work on this project!

I am working on some test scenarios for ControlTower and would like to use this project. However, I am having difficulties finding information about the following items:

• manfiest.yaml.j2 :
  any documentation related to this file available? should I have manifest.yaml and copy it into manifest.yaml.j2 while changing only the region to a string interpolation?

• Triggering the pipeline on update:
  When I update the package, upload it to s3 buckets, and then update cloudformation stack, the config deployer lambda does not update the S3 file that triggers the pipeline. any insights/docs on this would be appreciated.

Thank you

I ran into a couple of errors when initially deploying this AWS Solution. First, there seems to be a misconfiguration in the source stage of the codepipeline that is created. I had to add a "_" to the object name in this stage. Also, initially the account that the solution is deployed in has no access to download the customization templates from S3 because the KMS key used doesn't allow the root of the account to decrypt using the key.

Terminated few unused accounts in my AWS Organizations.
Pipeline is now stuck since there are some nested StackSet that can not update (complaining about missing roles - well yes the roles are not there anymore since the account has been deleted).
I have tried to delete StackSets manually, but the best I could do was
https://aws.amazon.com/premiumsupport/knowledge-center/cloudformation-removal-stacksets/

The account deleted was in INOPERABLE state so I had to set RetainStacks to true.
Now in the stacksets the deleted account does not show up, but it is still listed under StackInstanceAccountList.

I have a failure in the Step Function which is:
{"time_stamp": "2021-02-24 13:52:07,488","log_level": "INFO","log_message": Account: xxxxx - describing stack instance in eu-west-1 region}

This account is the Suspended one:

   "FunctionName": "describe_stack_set_operation"

    "eu-west-1": "Cancelled since failure tolerance has exceeded",

Version of customizations is 1.2.1

Is there an easy way to manually invoke the stack instead of being triggered by a new account creation event? This would be useful for us as we have a need to standardize the cloudformation stacks in place across previously deployed accounts as well as newly deployed accounts.

So we are starting to use this awesome project (thank you so much for putting this together) and really liking it so far, but I do have one question, wouldn't it be better if the stacksets were created directly as "Deploy to Organizational Unit" instead of doing what the manifest parser seems to be doing here: https://github.com/awslabs/aws-control-tower-customizations/blob/master/source/manifest/manifest_parser.py#L198 which is to build a list of accounts from the provided OU name.

Apologies, if this is a stupid question, but I think it would be great if there was some documentation around why the OU feature for cloudformation stacksets is not being used.

We use the same customizations package in two different organizations. We would like the ability to parameterize the account ids in the deployment_targets:/accounts: section of the manifest so that we can use the same manifest across both organizations (we have a couple of instances where an account needs to be referenced by name vs. OU). Ideally, the values come from the SSM parameter store in the master account home region so it can be set-and-forget.

Hello,

When i use user_input.yaml in add-on to templatize some files, values are not correctly replaced by the find_replace.py script.

Example, for the variable named key with value value_of_key_variable.

In template, the string {{ key }} will be replaced by "value_of_key_variable" instead of "value_of_key_variable".

A small modification of the script introduce this error in v1.1.0.

v1.0.0:

# bin/codebuild_scripts/find_replace.py:33
...
        j2env = jinja2.Environment(loader=j2loader)
...

v1.1.0:

# bin/codebuild_scripts/find_replace.py:35
...
        j2env = Environment(loader=j2loader, autoescape=True)  # Compliant
...

Can you reverse it ?

Hi! I have been using custom control tower for a while now, but ever since i updated I am not allowed to copy the zip directly into the s3 bucket. I have tracked it down to the bucket now uses a default encryption KMS key that is only allowing specific roles to use the key (It has been a while since i updated the custom control tower stack, sorry if im coming late with this issue). I cant find in the documentation where I am doing something wrong, maybe someone can help?

Specific error on 's3 cp' is: 'An error occurred (AccessDenied) when calling the PutObject operation: Access Denied'

Hi,

I have been used to work with automated landing zone where there was a depends_on attribute to each cloudformation resource. I can read in the developer guide that: "The order of cloudformation_resources is used to determine the execution order for creating cloudformation_resource dependencies."
Does it mean that each stack wait for the previous to reach CREATE_COMPLETE before provisioning the next? If so it seems like a slow way to provision independent stacks.

BR Mikkel

Hello,

The Control Tower Customizations solution is offered from within Service Catalog as a Product as well as from the Solutions web site and github.
The version number of the product on the Solutions page is 1.1
The latest version listed on github is 1.2
The version of the Service Catalog Product is 1.0

Is it possible to sync the releases so that all three are using the same version? If they are intentionally out of sync, could there be posted a release timing pattern?

Thanks

I noticed that when the OU is changes for an SCP or a CFN resource, that SCP or CFN resource is added to the 'new' OU, but not removed from the old one.

Also, when deleting an SCP or CFN resource, that does not appear to delete it.

eg. deploying an S3 logging bucket to all accounts and all regions can take more than 30 mins.
This makes adding new CF templates to the manifest (e.g. for CIS remediations) painful to develop and deploy.

Hi All,

Is Control Tower Pipeline perform the "Detach" SCP action from an OU/Account if we remove the code snippet from the manifest.yaml file?

For example,

Before: mainfest.yaml

organization_policies:

• name: scp1
  description: test scp1
  policy_file: policies/scp1.json
  apply_to_accounts_in_ou:
  • OU1
  • OU2

The CT pipeline "ATTACH" scp1

update:mainfest.yaml

organization_policies:

• name: scp2
  description: test scp2
  policy_file: policies/scp2.json
  apply_to_accounts_in_ou:
  • OU1
  • OU2

The CT pipeline "ATTACH" scp2, my expectation after update mainfest.yaml and "Detach" the scp1 from OU1,OU2 but it's not. Does control tower has that "Detach" capability?

Thanks, Sasi

In /source/aws/utils/boto3_session.py, def get_client(self):
All 4 (boto3.client) calls should pass in config=Config structure and allow setting max number and retry as indicated here (https://boto3.amazonaws.com/v1/documentation/api/latest/guide/retries.html#defining-a-retry-configuration-in-a-config-object-for-your-boto3-client)

The reason for this is that currently list stack instances call will hit the default 4 retries frequently if there is a large number of stack instances (1K+). Ideally AWS would increase the limits, but until then, it should be allowed to set overrides in some way. Or if you can't set overrides, at least change to standard, 10 instead of legacy, 4.

Filing another report for previously closed issue, Build fails if OU has no accounts #37.

I have the identical issue as described in #37, but I think you are missing a valid use case. We are performing a greenfield deployment for a customer, and they want to define all of their newly created OUs within the CFCT manifest file even though they are empty, this way as new accounts are provisioned via Account Factory they will automatically receive the customizations.

With the current issue around empty OUs the customer will be forced to deploy a first account into an OU which will not receive the customizations, then edit the manifest file to add the OU. This hurts the usefulness of allowing users to deploy their own accounts via Service Catalog because they still need to involve an Administrator to edit the manifest if this is a new or empty OU.

any workarounds for this use case?

When defining a stackset resource in the manifest.yaml file, I have the following:
manifest.yaml

  - name: baseline-vpc
    template_file: templates/network/vpc.yaml
    parameter_file: parameters/network/oregon/vpc.json
    deploy_method: stack_set
    deploy_to_ou: 
      - NonProduction
      - Production
    deploy_to_account: 
      - 'xxxxxxxxx' 
    regions:
    - us-west-2

which works as expected and deployed correctly.

After defining an additional stackset resource
manifest.yaml

  - name: baseline-vpc
    template_file: templates/network/vpc.yaml
    parameter_file: parameters/network/oregon/vpc.json
    deploy_method: stack_set
    deploy_to_ou: 
      - NonProduction
      - Production
    deploy_to_account: 
      - 'xxxxxxxxx' 
    regions:
    - us-west-2



  - name: baseline-vpc 
    template_file: templates/network/vpc.yaml
    parameter_file: parameters/network/sydney/vpc.json
    deploy_method: stack_set
    deploy_to_ou: 
      - NonProduction
      - Production
    deploy_to_account: 
      - 'xxxxxxxxx' 
    regions:
    - ap-southeast-2

the behaviour i experienced was a creation event in the ap-southeast-2 region for my additional stack instances, but then a subsequent Delete event for the region us-west-2 which was defined earlier by the same name as the new addition.

Can the manifest file be checked for duplicate resources or merge duplicate resources to be combined?

In my situation VPC resources were deleted in us-west-2 until a resource dependency was found and the stack instance threw a failure holting the remaining stack instances from being processed.

I may be seriously confused regarding intended scenario for ssm_parameters manifest property.

My understanding is that it is supposed to help with dependencies between stack sets. Here is a simple example with two stack sets:

• network-stack-set - deploys network resources (VPC, security groups, etc)
• app-stack-set - deploys resources that rely on VPC deployed by network-stack-set

I expect that I can save output variable from stack instance in SSM parameter within Account/Region where the stack instance is deployed, so it can be consumed by different stack sets, like below:

My expectation is that I can achieve this with the following manifest:

---
region: eu-west-1
version: 2020-01-01

cloudformation_resources:
  - name: network-stackset
    template_file: templates/network.template
    parameter_file: parameters/network.json
    ssm_parameters:
      - name: /org/member/VpcId
        value: $[output_VpcId]
    deploy_method: stack_set
    deploy_to_ou:
      - Custom
    regions:
      - eu-west-1
      - eu-central-1  
  - name: app-stackset
    template_file: templates/app.template
    parameter_file: parameters/app.json
    deploy_method: stack_set
    deploy_to_ou: 
      - Custom
    regions:
      - eu-west-1
      - eu-central-1 

However, what I observe is that /org/member/VpcId SSM parameter is created in master account/region - the account where the solution is deployed (the one with Control Tower enabled). No SSM parameters are created in member accounts, therefore app-stackset deployment fails as it relies on these parameters.

I tracked the issue down to the following lines (note that SSM client is created with default parameters, which means current - master - account and region):

https://github.com/awslabs/aws-control-tower-customizations/blob/b006bd8342ebf03b9458ec11e794ecb3bbba7845/source/state_machine_handler.py#L1010-L1016

Also, may be related to this problem - when Step Function exports CFN output variables to save them in SSM, it does so for the first Account/Region pair returned, which looks incorrect:

https://github.com/awslabs/aws-control-tower-customizations/blob/b006bd8342ebf03b9458ec11e794ecb3bbba7845/source/state_machine_handler.py#L1033-L1037

For now I have to manage SSM parameters manually within CFN templates without relying on the manifest file support. Please let me know if my understanding of the issue is correct - happy to help with PR to address it.

When a stackset bugs out there's no easy way to see which stack/ account / region caused the issue.

Executing: CloudFormation/describe_stack_set_operation

"time_stamp": "2020-04-22 12:40:44,287","log_level": "INFO","log_message": { "StackSetName": "CustomControlTower-s3-access-logging-bucket", "TemplateURL": "https://s3.amazonaws.com/controltowercustomisatio-customcontroltower ...

{"time_stamp": "2020-04-22 12:40:44,698","log_level": "INFO","log_message": { "StackSetOperation": { "OperationId": "c5410449-d03f-404d-8bba-f56c84db88be", "StackSetId": "CustomControlT

{"time_stamp": "2020-04-22 12:40:44,698","log_level": "INFO","log_message": Operation Status: FAILED}

The code in v2.0.0 validation/run-validation.sh that validates the manifest.yml schema version is fragile, and prone to reporting ERROR: Invalid manifest schema version. in conditions that it should be able to accept.

This validation only succeeds if the following conditions hold:

• this line is the only line in the file containing the string 'version'
• this line has exactly two words, in one of the following forms (e.g. without a valid YAML comment postpended):
  • version: 2020-01-01
  • version: 2021-03-15

I have a cloudformation_resources entry

  - name: StackSetExecutionRole
    template_file: s3://cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml
    parameter_file: parameters/stack-set-execution-role.json
    deploy_method: stack_set
    deploy_to_ou: # :type: list
      - Custom
    regions:
      - us-east-1

The initial deployment was fine but the subsequent deployment fails with this error:

{"time_stamp": "2020-10-20 11:44:15,382","log_level": "INFO","log_message": Comparing the template of the StackSet: CustomControlTower-StackSetExecutionRole with local copy of template}
--
895 |  
896 | {"time_stamp": "2020-10-20 11:44:15,382","log_level": "INFO","log_message": Downloading cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml from S3 to /tmp/tmpejy3m4eg}
897 |  
898 | {"time_stamp": "2020-10-20 11:44:15,433","log_level": "ERROR","log_message": Unhandled Exception: An error occurred (403) when calling the HeadObject operation: Forbidden}

So somehow the build script isn't able to download/compare the publicly accessible file in S3?

After successfully deploying the solution, I made some changes to our template for the Audit account, redeployed, and it failed on the stack in our second region due to a dependency error. So, I fixed it and redeployed, but now the code build fails. I traced it down to the compare_template_and_params() function in sm_execution_manager.py. At line 156 it does a "return operation_status_flag" to indicate the template needs to be re-deployed, but the function is supposed to return two parameters, so it fails with a "ERROR","log_message": Unhandled Exception: cannot unpack non-iterable bool object}" at line 54 where it calls the compare_template_and_params() function. I think it needs to "return operation_status_flag, False". A similar situation also exists on line 176 for a different error.

In the case deploying one SCP on a nested OU (one level under top-level OU) following exception is thrown:

OU id is not found

So are nested OU not supported in general?

Hi,
Once upgrade to CfCT v2, I see this issue on cfn_nag

| FAIL FATAL
|
| #<ArgumentError: invalid byte sequence in US-ASCII>

Failures count: 1

Note that I run cfn_nag (v0.7.2) and it is running perfectly.

Hi All,

I would like to test the individual add-on changes in a test aws account rather than going through checks for all the existing add-ons in a manifest.yaml file. Currently for each minor change, we'll have to wait for whole pipeline to run which takes about ~2 hrs which is time consuming

Also, how can we have separate pipeline only for testing isolated from the production pipeline ? Currently we've a single pipeline being used for both the development and production code which resides in s3 bucket.

Any suggestions highly appreciated.

Thanks in advance
Sasi

Hi,

I have been trying to deploy a stack to all accounts under Root, Core and Custom. But Root/Master doesn't gets the Stack provisioned.
Is there a reason why?

BR Mikkel

According to the 2020-07 Developers Guide pg 9 in referring to Cloudformation Resources:
name
The name that is associated with the AWS CloudFormation StackSets. The provided name is used to provide a more user-friendly name for a stack set.
Type: String Required: Yes
Valid Values: a-z, A-Z, 0-9, and an underscore (). Any other character is automatically replaced with an underscore ().

This should be accepting a hyphen (-) and not an underscore as hyphens are valid in stack names, and underscores are not. Including an underscore results in the CloudformationResource build step to fail which can be tracked down in the step function:

"errorMessage": "An error occurred (ValidationError) when calling the CreateStackSet operation: 1 validation error detected: Value 'CustomControlTower-cloudformation_example_name' at 'stackSetName' failed to satisfy constraint: Member must satisfy regular expression pattern: [a-zA-Z][-a-zA-Z0-9]*"

Not sure if this is really an issue or not, but every time pip is run in the build scripts (install_stage_dependencies.sh, etc.) it throws this "error" (which is really more of a warning):

ERROR: After October 2020 you may experience errors when installing or updating packages. This is because pip will change the way that it resolves dependency conflicts.

We recommend you use --use-feature=2020-resolver to test your packages with the new resolver before it becomes the default.

The scripts run to completion, but since it is nearly the end of October 2020, we just want to make sure the solution won't break come next month.

Couldn't find a way to delete a stackset created using deploy_method: stack_set. Please advise

In the March 2021 developer guide, all the example code for inline parameter usage incorrectly use "parameter_name" to reference the key, which triggers an error in the pipeline build process. The syntax documentation properly refers to this as "parameter_key".

When i modify or add the ssm_parameters: key for outputs of the stack_sets and there is no action required on the stack set, the pipeline will fail upon the next stackset which is expecting the ssm paramater to exist.

Is there a way to force ssm_parameters to be always processed even if there is no stack changes?

Hello all,

Our team needs to specify tags for CloudFormation stack instances deployed by the Customizations for Control Tower pipeline in order to comply with an AWS Config rule.

As a feature request, would it be possible to add a "tags" property to the items in the cloudformation_resources section of the manifest file? These tags would then be applied to the individual stack instances on deployment.

Let me know if that makes sense.
Thanks!

The resource.paramter_file is passing Null value when there is no parameter file for a given template. The manifest.yaml is inherited from version 1 repo.

This forces the template files to have a parameter.

2021-03-23T23:49:48.883-07:00	parameters = self._load_params_from_file(resource.parameter_file)
2021-03-23T23:49:48.883-07:00	File "/codebuild/output/src377331526/src/manifest/manifest_parser.py", line 373, in _load_params_from_file
2021-03-23T23:49:48.883-07:00	with open(parameter_file, 'r') as content_file:
2021-03-23T23:49:48.883-07:00	IsADirectoryError: [Errno 21] Is a directory: '/codebuild/output/src377331526/src/'

Provide support for alfred_ssm helper nested in lists

[{
                "ParameterKey": "Key",
                "ParameterValue":[
                        "$[alfred_ssm_/key1]",
                        "$[alfred_ssm_/key2]",
                        "$[alfred_ssm_/key3]"
                    ]
            }]

After Upgrading from 1.1 the first step S3 execution in code pipeline it fails on IAM policy but this is how we work and would like to disable the check?

Updated the stack using the 1.2.1 template, no modification to parameters, and the update consistently fails with:

CustomControlTowerCodeCommit | UPDATE_FAILED | Source code property can't be modified.

Initial deployment used CodeCommit repo as the source. aws-control-tower-customizations v1.1.0 I believe.

Hello. We have been using control tower and this customization tool since they both came out. We have had issues with the templates failing on the 2nd run or when a new account is created. It appears that the resource is not registering. This may also be a template issue or completely a USER ERROR and for that I apologize wasting your time :) . Error below:

The error message is the resource already exists

C Wong was on our account for a long time and introduced us to the tool when it was called Addon Framework.

Extra question do you have AWS addons that can be shared?

I am trying to debug why the cfn_nag_scan exits with status 1, even though all scans returns:

Failures count: 0
Warnings count: 0

The easiest way to debug which stack is invalid should be to out comment the cloudformation_resources stacks in manifest file that might fail and then narrow it down. BUT even though you out comment the stacks in manifest file, the validation still runs on unused template and parameter files. This seems unessesary.

Would it be possible to make cfn_nag more smart in what files it scans?

Hello,

I was just wondering if these new SCPs and Config rules could appear as new Guardrails in the Control Tower console?

Cheers,

I'm using v2.0.0 mainly for rolling out manged AWS Config rules to almost all account in all regions. So in sum more than 200 stack instances are created. The stack set is created with following deployment options:

• Maximum concurrent accounts - 100
• Failure tolerance - 10

See https://github.com/awslabs/aws-control-tower-customizations/blob/677d12e16ecee9ae85c7fa056ded96aac5441525/source/aws/services/cloudformation.py#L28

So in case of so much instances with the above concurrent option it takes very long to apply the change to all accounts. Therefore it would be create to make the region concurrency configurable in manifest.yaml, e.g.

resources:
  - name: pcs-config-rules
    deploy_method: stack_set
    deploy_options:
       - region_concurrency = parallel 

Based on https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html sequential deployment is the default selection

Hello,

When i use the manifest version 2020-01-01 present in documentation v1.1.0 like:

---
region: <String>
version: 2020-01-01
...

CodeBuild failed to validate the manifest:

ERROR - validation.invalid
ERROR -  --- All found errors ---
ERROR - ["Enum '2020-01-01' does not exist. Path: '/version'"]
...
Phase complete: BUILD State: SUCCEEDED

The build succeeded, perhaps it should fail ?

In the scripts archive downloaded by the CodeBuild project, we only have the version for v1.0.0 available.

# validation/manifest.schema.yaml:6
  "version":
    type:      date
    required: True
    enum: [2019-12-01]

Can you update the specifications or modify the documentation to remove this error ?

Manifest.yml uses "deploy_to_ou" and after kicking off the CodePipeline, if a listed OU has no accounts, build fails with:

ValueError: The account list must have at least 1 valid account id. Please check the manifest under CloudFormation resource

Fuller output from log:

{"time_stamp": "2020-10-07 17:37:39,390","log_level": "ERROR","log_message": Unhandled Exception: The account list must have at least 1 valid account id. Please check the manifest under CloudFormation resource: CcoeIamRoles. 
 Account List: [] 
 OU list: ['XXX']}
Traceback (most recent call last):
  File "state_machine_trigger.py", line 50, in main
    sm_input_list = get_stack_set_inputs()
  File "state_machine_trigger.py", line 78, in get_stack_set_inputs
    return get_stack_set_input.parse_stack_set_manifest()
  File "/codebuild/output/src406650435/src/manifest/manifest_parser.py", line 120, in parse_stack_set_manifest
    raise ValueError("The account list must have at least 1 "
ValueError: The account list must have at least 1 valid account id. Please check the manifest under CloudFormation resource: XXX. 
 Account List: [] 
 OU list: ['XXX']
Traceback (most recent call last):
  File "state_machine_trigger.py", line 102, in <module>
    main()
  File "state_machine_trigger.py", line 50, in main
    sm_input_list = get_stack_set_inputs()
  File "state_machine_trigger.py", line 78, in get_stack_set_inputs
    return get_stack_set_input.parse_stack_set_manifest()
  File "/codebuild/output/src406650435/src/manifest/manifest_parser.py", line 120, in parse_stack_set_manifest
    raise ValueError("The account list must have at least 1 "
ValueError: The account list must have at least 1 valid account id. Please check the manifest under CloudFormation resource: XXX. 
 Account List: [] 
 OU list: ['XXX']

Manifest_parser.py or such should have logic to handle a null account list for empty OUs.

botocore 1.18.0 removed AWS CLI specific doc files. Those were already migrated to the CLI in version 1.18.140.

This is failing codebuild stage.

Please add following awscli upgrade command install_stage_dependencies.sh

pip install --upgrade pip

https://github.com/awslabs/aws-control-tower-customizations/blob/master/source/bin/codebuild_scripts/install_stage_dependencies.sh

Is your feature request related to a problem? Please describe.

Ability to customize the customization pipeline using readily available CDK constructs.

Describe the feature you'd like

Would like to be able to add additional steps and stages and leverage CDK constructs.

Additional context

For customers that are unable to use cdk, you can always just synthesize and share the cfn as is being done today.