My use case should be fairly common I guess: I want to manage a Google Cloud SQL instance using the Terraform PostgreSQL provider. I don’t want to open my instance to the whole world though, so I’d like to whitelist a range of addresses or networks from which Terraform Cloud runs originate.
I know it’s not top notch security: there’ll be nothing stopping an informed attacker from deploying their hits on Terraform Cloud. I just want to avoid the bots.
I wanted to follow-up and confirm the answer. Currently, Terraform Cloud does not run on a predefined range of IP addresses. I understand that the ability to whitelist is important, there is a possibility we may have a solution for this in the future. At this time, the runners are fairly dynamic.
too bad. this is kind of a dealbreaker for using terraform cloud. Was in touch with hashicorp support, the the suggesting is to move to terraform enterprise.
Wasn’t this one of the selling features of the Business Tier, announced back near the end of the summer? It’s only for certain Terraform Cloud features, though; maybe that’s the bit I’m missing.
Note that those IP ranges are for Version Control Systems, Sentinel, and Notifications only. HashiCorp Terraform Cloud Business Tier allows for agents that solve the remainder of this scenario by providing the ability to use Terraform Cloud Agents which allow Terraform Cloud to communicate with isolated, private, or on-premises infrastructure.
Please let us know if that answers your questions, and if you have any other concerns!
@onlydole could you please tell me what IP addresses should I whitelist for Terraform Cloud runs which connect to public Vultr API using official Vultr provider?
I tried all the addresses which I can find here https://app.terraform.io/api/meta/ip-ranges, but I get an error {"error":"Unauthorized IP address.","status":401}. I’m sure I use the correct access token, also I contacted Vultr support and they said there were no problems on their side.
Thank you for providing those screenshots and additional information! That makes a lot more sense to me now what was going on.
Your screenshots helped show that the issue is occurring due to the runner IP not having access to Vultr.
The IPs you’re listing are correct, BUT those IPs are for the Terraform Cloud API, and for Terraform Cloud Notifications. There are IPs for Sentinel and VCS, though those won’t fix this issue.
The IPs for the runners are not shared publicly at this time as a means to protect users of Terraform Cloud and allow for optimizations that we can make for hosting runners on the SaaS platform.
You are able to guarantee IPs for runners if you utilize the Terraform Cloud for Business tier, which allows for you to self-host Terraform Cloud Agents and this would be my recommendation for more control over your IP space utilization and network access control.
Please let me know if there’s anything more I can clarify to that end, and I hope that helps shed more light on why those issues arose when working with the Vultr provider and Terraform Cloud runs!
Not the best option but you could modify the firewall rules on the fly using something like this but adapted to your needs and creating a dependency so the rule is changed before access is needed.