Provide SSH keys for cloning tf modules about terraform-aws-atlantis

[brunsgaard]

A solution for the problem can be found here #63 (comment)

[statwoodland]

This would be ideal. I'm having to move away from using this module solely because I can't inject an SSH key.

[antonbabenko]

I understand. PR is welcome if anyone has time.

[eupestov]

@antonbabenko I'm wondering what would be the best way to implement this?

• Add another input parameter for the private ssh key and save it in a SSM parameter as it is done for tokens currently.
• Generate a key pair within the module, store in SSM and return the public key in output params.
• Use an existing SSM parameter for fetching the private key.
• Something else?

Please, advise.

[Vlaaaaaaad]

@eupestov that's along the lines of what we did, but we used a custom wrapper Docker image that at startup gets the key from SSM.

@bmihaescu is working on a blog post detailing all this.

[antonbabenko]

I think that this module should not be very smart and generate keys or save them in SSM but instead, it should either:

1. Control the URL or SSM parameter where secret should be fetched when the container starts and set an environment variable to instruct Git to use SSH key. See comment by Paul (Hi there :))
2. Alternatively, which is a more popular solution (according to my knowledge), as @Vlaaaaaaad has mentioned - customize Docker image, get secret at startup from S3 or SSM.

I recommend that we add description of this process in README and include code-snippets there.

Also, it is important to avoid handling of the secret using Terraform to keep it outside of terraform.tfstate.

@psalaberria002 Do you have any ideas about this? Or objections?

[eupestov]

Thanks! I'll try the method described by @Vlaaaaaaad first as I already use a custom docker image. But I think I will still need to extend the policy granting the fargate task rights to read specific parameters from SSM.

[trebidav]

@antonbabenko Why do you think it's important to not keep the SSH key in .tfstate file? Other secrets are also kept there. The bigger problem is that you need a custom docker image with SSH config and mechanism of importing SSH key on startup. This would need to get official support from atlantis server. I don't think that this feature should be part of this module. @Vlaaaaaaad @bmihaescu However a blog post would be nice!

[antonbabenko]

It is a private key, not public. This is a bit too much to keep in tfstate.

I think if we can get a process (eg, a script) which creates necessary adjustments it would be handy to have it in this repository at least.

[jkodroff]

If it helps, you can reference the work that I did in creating the public Helm chart for Atlantis: https://github.com/helm/charts/tree/master/stable/atlantis

We add trickery to .gitconfig to force HTTPS over SSH and substitute the supplied user token in the URL:
https://github.com/helm/charts/blob/master/stable/atlantis/values.yaml#L41-L52

Unfortunately, I'm not sure to what extent Fargate allows mounting secrets as files. I suppose it could always be done via the CLI at startup.

[smiller171]

Unfortunately, I'm not sure to what extent Fargate allows mounting secrets as files. I suppose it could always be done via the CLI at startup.

It only supports secrets as environment variables and files (link), but you could use custom workflows to access that environment variable, or you could use a custom container to get the environment variable and save it to a file.

[lindehoff]

One quick fix would be to expose the command input variable for the container_definition_github_gitlab definition. Then you could add the following run cmd ["sh", "-c", "git config --system url.https://oauth2:[email protected] ssh://[email protected] && atlantis server"] to the container and it will configure git to use https with token instead of ssh key. You of course need to add the environment variable YOUR_GITLAB_TOKEN also.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.