Help understanding how ecs-deploy-runners clones repos inside _envcommon
I'm a little confused regarding the service catalog around the _[envcommon source](https://github.com/gruntwork-io/terraform-aws-service-catalog/blob/master/examples/for-production/infrastructure-live/_envcommon/services/ecs-cluster.hcl#L15) cloning source repos When the ecs-deploy-runner is grabbing the source, how is it cloning the repo? `git::git@github.com:gruntwork-io/terraform-aws-service-catalog.git//modules/services/ecs-cluster?ref=v0.82.0` That makes me believe it's ssh just by looking at it... But when looking at the [regional/container_images](https://github.com/gruntwork-io/terraform-aws-service-catalog/blob/master/examples/for-production/infrastructure-live/shared/us-west-2/_regional/container_images/build_deploy_runner_image.sh) build process, it's only putting in a [GITHUB_OAUTH_TOKEN](https://github.com/gruntwork-io/terraform-aws-service-catalog/blob/master/examples/for-production/infrastructure-live/shared/us-west-2/_regional/container_images/build_deploy_runner_image.sh#L43) which means it's doing https cloning and I do remember there are parts where the code is forcing https clones instead of ssh clones. And that's only initially allowed by cloud based source repos because of some embedded telling whenever cloning bitbucket/gitlab.com/github.com, use https... But there's the secrets manager to put in a private ssh key for git... So I'm just kinda spinning in circles a bit. The reason why i'm bringing this up is because I made changes to instead of using a cloud based source repo, im using an internal only one. I got passed the host key adding with the ecs-deploy-runner and adding in our host key so it feels like it's trying to do ssh clones. But I get errors like this now: ``` [ecs-deploy-runner][2022-04-07T01:10:42+0000] * error downloading 'ssh://redacated/iac/packer.git?ref=v0.0.6': /usr/bin/git exited with 128: Cloning into '/tmp/tmp9u8kcimr/dev/us-west-2/dev/ec2-instance/nginx/.terragrunt-cache/uJVUnMadxFV_mFg5T5Q4w1NIoBI/sifUfbkg2MEiCFB7ugmhdKj3uQk'... [ecs-deploy-runner][2022-04-07T01:10:42+0000] git@REDACATED: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). [ecs-deploy-runner][2022-04-07T01:10:42+0000] fatal: Could not read from remote repository. [ecs-deploy-runner][2022-04-07T01:10:42+0000] Please make sure you have the correct access rights [ecs-deploy-runner][2022-04-07T01:10:42+0000] and the repository exists. ``` I'm gonna keep digging into my issue, but understanding how ecs-deploy-runners does clones inside _envcommon for the source in the terraform blocks would help out. --- wow i think it's the chicken vs the egg problem, mainly stemming from the fact that in our implementation, we have an internal gitlab and we don't use the kaniko container builds at all, which means that our deploy runner is based off whatever we build it with the first time.... Which means the ecs-deploy-runner container gets a github_oauth_token, but then never gets updated with kaniko and the docker_image_builder, which then would load in the SSH key from secrets manager. I could either get around it by: 1. forking the infrastructre-deploy-script to add in our internal gitlab to force the HTTPS global url. https://ourgitlab.com/.insteadOf [git@OURGITLAB.com](mailto:git@OURGITLAB.com) so it would use a PAT... but I would also have to add in another argument for that PAT in the future. 2. Or by figuring out how to add in the private ssh key to the ecs-deploy-runner image when I first make it, so it can use SSH clones Since its a private source repo and I can lockdown my vpcs with network ACLs for ssh traffic and that our resource is internal only, and I can log those connections, i think it would still pass CIS benchmarks in the future.
The `ecs-deploy-runner` can also support SSH-key based clones via the [repo_access_ssh_key_secrets_manager_arn](https://github.com/gruntwork-io/terraform-aws-service-catalog/blob/master/modules/mgmt/ecs-deploy-runner/variables.tf#L217) arg in the `terraform_planner_config` and `terraform_applier_config` objects. This secrets manager entry should contain the contents of a passwordless SSH private key, which then gets loaded at runtime into an `ssh-agent` prior to calling `git clone`. This would be option (2) in your list of workarounds, which is probably the path of least resistance (since you won't have to maintain a fork). Note that this only applies to the infrastructure deployment scripts (`terragrunt`/`terraform` calls) of the pipeline, and does not work with the AMI builder or the docker builders, as those only support HTTPS based clones.