Suggest forking the repo before use

[JDiPierro]

Including an externally-controlled terraform module as part of your infrastructure feels like a huge security concern. If a malicious actor somehow got write access to this repository they could add an instance to the module with their own SSH key and some startup script to report to a control server, then next time someone updates their infrastructure the hacker would have direct access to a host inside your network.

Instead of recommending people use the module with:

module "dynamodb_autoscaler" {
  source = "git::https://github.com/cloudposse/terraform-aws-dynamodb-autoscaler.git?ref=master"
  ...
}

IMO it'd be better to suggest something like:

• Fork the repo into your own namespace and use that git URL
• Copy the module source directly into your repo
• Add this repository as a submodule of your own (Least secure but still more secure as you have to manually update it)

[osterman]

@JDiPierro thanks for reaching out.

So, I think this is a security concern with all software -- open source or commercial. It's not restricted to terraform code. Anything you inject into your environment can be tainted. A modern web app written in NodeJS, Golang, Java, or pretty much any other language often pulls in a litany of external code in the forms of libraries or plugins. If that code runs on an EC2 instance with an IAM instance profile which allows for the creation of EC2 instances, the same could happen, should a bad actor compromise the dependency.

Terraform modules often nest other modules, so forking is not enough. It would mean all the other references (recursively) also need to be updated, which will be difficult to scale and keep up to date.

That said, all of our modules are licensed under the permissive APACHE2 license, so if an organization needs to take this extreme course of action, it's possible and permitted; however, I cannot recommend that as a general "best practice". We have 110+ modules, and add more every week. Instead, I would recommend pinning to a release which will reduce some of the attack surface.

What I would love to see in terraform is the ability to define/override in the global scope an alternative source for any module. This would then make it easier to "localize" modules in an organization's own source control system.

---

Cloud Posse takes security seriously. All of our repos have strict branch protections on master, and require Pull Requests with approvals to merge to master. Any push to a branch after an approval, dismisses the approvals. We tag every merge to master with a release, which lets you do strict version pinning. Additionally, we require all users in the organization to have MFA enabled on their Github accounts and their accounts are immediately evicted from our organization if MFA is disabled.

[aknysh]

@JDiPierro thanks you for your suggestions.
@osterman explained very well why what you said is a valid concern and how we deal with it.
will close the issue for now.

[krystan]

@JDiPierro thanks for reaching out.

So, I think this is a security concern with all software -- open source or commercial. It's not restricted to terraform code. Anything you inject into your environment can be tainted. A modern web app written in NodeJS, Golang, Java, or pretty much any other language often pulls in a litany of external code in the forms of libraries or plugins. If that code runs on an EC2 instance with an IAM instance profile which allows for the creation of EC2 instances, the same could happen, should a bad actor compromise the dependency.

Terraform modules often nest other modules, so forking is not enough. It would mean all the other references (recursively) also need to be updated, which will be difficult to scale and keep up to date.

That said, all of our modules are licensed under the permissive APACHE2 license, so if an organization needs to take this extreme course of action, it's possible and permitted; however, I cannot recommend that as a general "best practice". We have 110+ modules, and add more every week. Instead, I would recommend pinning to a release which will reduce some of the attack surface.

What I would love to see in terraform is the ability to define/override in the global scope an alternative source for any module. This would then make it easier to "localize" modules in an organization's own source control system.

Cloud Posse takes security seriously. All of our repos have strict branch protections on master, and require Pull Requests with approvals to merge to master. Any push to a branch after an approval, dismisses the approvals. We tag every merge to master with a release, which lets you do strict version pinning. Additionally, we require all users in the organization to have MFA enabled on their Github accounts and their accounts are immediately evicted from our organization if MFA is disabled.

Great to know, the code here is high quality but there is always the "not written here" attitude of some which completes