CloudFormationManagedUploadInfrastructure stack Company resource restrictions

while trying to run cfn submit creating the CloudFormationManagedUploadInfrastructure stack fails as my companies enforced role boundaries require a specific PermissionBoundary and ManagedPolicy be present. If i manually create the stack it attempts to align it which would not be allowed in my circumstance.

the breakage for me occurs on the following resource where i need permissionBoundary set and a managed policy added. https://github.com/aws-cloudformation/cloudformation-cli/blob/85dba80439e044f65e294af65d36fa0934151bad/src/rpdk/core/data/managed-upload-infrastructure.yaml#L99

I have a local version of this repository working with the changes i needed and i am wondering if this kind of issue is something worth addressing, i am not sure what mechanism would be most appropriate to allow someone in my situation to control that stack and/or keep a modified version of the stack without forking this repo.

[atheiman]

I need this as well, is there any recommended work around? I don’t see a path forward to use the CFN CLI in any kind of regulated account other than to fork this project and change the cloudformation template? Any kind of tagging requirements in a tagging policy or configuration requirements for resources in an SCP (both very common and AWS best practices) prevent the use of the managed-upload-infrastructure.yaml template in its current form.

I dont see a way to support every user’s needs in the template, so I’d propose an argument to provide a custom cloudformation template and a note in documentation about how to customize the existing template.

cfn submit ... --custom-managed-upload-infrastructure-template ./my-custom-template.yml

Edit: I suppose a workaround (tho nasty) is to manually overwrite the file in the user’s Python package installation. For example on the maven:3-openjdk-11 Docker image I’m using in a deployment pipeline, the file could be overwritten at /usr/local/lib/python3.7/dist-packages/rpdk/core/data/managed-upload-infrastructure.yaml. Leaving this here for anyone that runs into this before this issue is resolved - but this is a pretty bad practice and I’d only recommend doing it if 1) you know what youre doing and 2) if youre doing it in a disposable environment (like a Docker container in a deployment pipeline).

# example to overwrite the cloudformation template in a pipeline
mv ./my-custom-template.yaml "$(find / -type f -name 'managed-upload-infrastructure.yaml')"

[pgdad]

The outputs of the managed-upload-infrastructure.yaml template are:

Outputs:
  CloudFormationManagedUploadBucketName:
    Value: !Ref ArtifactBucket
  LogAndMetricsDeliveryRoleArn:
    Value: !GetAtt LogAndMetricsDeliveryRole.Arn

Presumably that means that the role arn and the s3 bucket are used by the rest of the tooling for the actual resource type/module registration process. The process, as used by the ‘cfn’ command, should provide parameters where the required values can be specified, by passing the need for creation of the template (and associated resources). This would enable a more ‘corporate’ user to implement the required resources in a manner that adheres to the security standards of the corporation. This would also enable the user to reduce cost, such as using ‘bucket key’, and ‘aws provided default key’ for the S3 SSE.