Account Customisations - private terraform modules

[andiempett]

Using public terraform modules with AFT is easy. It would be great if there was some documentation or an enhancement to facilitate pulling private modules from git or s3.
For git modules i think there would need to be some changes to the AFT codebuild jobs to inject credentials into the job to allow pulling from the private repo
s3 would be easier - setting one up can be done outside AFT. IAM Policy guidence here would also be a nice touch

[stumins]

Hi, thank you for the feedback. We've added a item to our backlog to explore this more.

[mathewmoon]

@androidwiltron you can put your credentials in secrets manager of the AFT account, give the AFT execution role permission to read them and retrieve them in your TF code. Alternatively, I configured my build pipelines for our internal modules to push to s3 in the AFT account with a bucket policy that allows the execution role in AFT and target accounts access. Hope this helps.

[andiempett]

@mathewmoon the s3 method - i used the below bucket policy and it fails on the account customisations codebuild job when downloading the module:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::1111111111111111:role/AWSAFTExecution",
                    "arn:aws:iam::222222222222:root"
                ]
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::my-aft-terraform-modules"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::1111111111111111:role/AWSAFTExecution",
                    "arn:aws:iam::222222222222:root"
                ]
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::my-aft-terraform-modules/*"
        }
    ]
}

can you share the policy you used or any suggestions
thanks

[nitrocode]

@stumins @balltrev can we keep this ticket open until it's complete ? I'm also looking to use private repositories for our customizations and it's unclear how to do this easily

[mathewmoon]

@androidwiltron

Your resource in the policy should be the bucket arn and the bucket arn with a slash and splat. For instance

"Resource":  [
    "arn:aws:s3:::my-aft-terraform-modules",
    "arn:aws:s3:::my-aft-terraform-modules/*"
]

[hsdp-smulford]

Bump - This should not be closed. The context of this issue is that the modules are in a source control, like github, not sync changes to s3.

[marcofranssen]

Some examples of severe shortcomings in code pipelines:

• Bash scripting involving the Git repository

  • fetch the most recent commit
  • check if there are newer commits on top of the tag
  • We use that to inject tags on our terraform modules that will be attached to the resources

• Terraform modules

  • We have a bunch of terraform modules hosted in private Git repositories.
  • We can't change to fetch them from s3 as that will break existing usecases on where these modules are used.
  • Our AFT needs to reuse those modules so we don't have to duplicate and maintain multiple codebases.

Currently it seems there is now way to inject the credentials to be used for those private git repositories. In other CI/CD systems we simply add following piece of shell script. This configures Git fetch the terraform resources via HTTPS using the personal access token that gives access to those repositories. While on local development environments our developers can authenticate via their SSH keys and clone them via SSH.

git config --global url."https://${{ secrets.TERRAFORM_PAT }}:x-oauth-basic@github.com".insteadOf ssh://git@github.com

as we define our module references like.

module "our-terraform-module" {
  source = "git::git@github.com:our-org/our-terraform-module?ref=v1.8.0
  …
}

The S3 workaround is not a feasible workaround as we would have to change the whole architecture, even of modules used outside of the AFT.

[v-rosa]

@balltrev from my understanding this issue is addressed by v1.5.0 right?

[balltrev]

@v-rosa, yes, we flattened the pipeline steps into a single container for per-account customizations, and a single container for global customizations. This should allow you to add your authentication steps to the pre-api-helpers.sh and that configuration will persist to both the terraform apply, and post-api-helpers.sh executions.

[andiempett]

I think some docs with examples for this would be very welcome. It brings a core piece of terraform functionality back into play (using modules from S3, git etc.) But at a glance this would not be very obvious to a new adopter.

…

On Wed, 22 Jun 2022, 6:07 pm Trevor Ball, ***@***.***> wrote: @v-rosa <https://github.com/v-rosa>, yes, we flattened the pipeline steps into a single container for per-account customizations, and a single container for global customizations. This should allow you to add your authentication steps to the pre-api-helpers.sh and that configuration will persist to both the terraform apply, and post-api-helpers.sh executions. — Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABL3CPEKQYCGP5SUMV55IQLVQNB3LANCNFSM5MXYKYPQ> . You are receiving this because you were mentioned.Message ID: <aws-ia/terraform-aws-control_tower_account_factory/issues/42/1163392378@ github.com>

[v-rosa]

@androidwiltron @balltrev

Here it goes my approach to make this work for GitHub hosted terraform modules with AFT v1.5.1

https://gist.github.com/v-rosa/aa9c8afd44d66c3a81b9920a1bc90e42