For Private Terraform Enterprise (PTFE) to function properly, it requires the following network access.
Inbound and Internal Traffic
Additionally, the installer framework requires access to certain hostnames when in online mode.
Deprecation warning: The AMI is longer be actively developed as of Private Terraform Enterprise v201808-1, and was fully decommissioned on November 30, 2018. Please see the Migration Guide for instructions to migrate to the Private Terraform Enterprise Installer.
When using the AMI-based installation, the Terraform configuration that ships with PTFE will by default create Security Groups (SGs) that make the necessary ports available. For the load balancer and instance SGs, it’s also possible to specify custom security groups.
Load Balancer SG: Applied to the Elastic Load Balancer (ELB). Controls incoming HTTP traffic from users.
- Port 443 must be accessible to users for basic functionality. It must also be accessible from the VPC itself, as certain internal services reach over the ELB to access cross-service APIs. This means that the calls are being made to the instance’s public hostname, so a check like
curl -v https://<TFE HOSTNAME>/_health_checkshould succeed from inside the instance itself.
- Port 80 is recommended to leave open for convenience. The system is set up to force SSL by redirecting users who visit Private Terraform Enterprise over HTTP to the equivalent HTTPS URL. If this port is not available, users who mistakenly visit the site over HTTP will see hanging requests in their browser.
Instance SG: Applied to the EC2 Instance running the application.
- Port 8080 must be accessible to the ELB to serve traffic.
- Port 22 must be accessible to operators to perform diagnostics and troubleshooting over SSH.
There are also two internal SGs that are not currently user-configurable:
Database SG: Applied to the RDS instance. Allows the application to talk to PostgreSQL. Redis SG: Applied to the ElastiCache instance. Allows the application to talk to Redis.
Outbound Traffic (Installer and AMI)
Terraform Enterprise makes several categories of outbound requests during normal operation: data stores, VCS integrations, Terraform execution, Terraform version updates, and other communications.
In external services mode (installer) and for the AMI, access to S3 or S3-compatible object storage is required.
Version Control System Integrations
Private Terraform Enterprise workspaces can be linked to a number of Version Control System (VCS) providers, some supporting both SaaS and private-network installations (more at VCS Integration).
In order to perform ingress of Terraform configuration from a configured VCS, PTFE will need to be able to communciate with that provider’s API, and webhooks from that provider will need to be able to reach PTFE.
For example, an integration with GitHub would require Private Terraform Enterprise to have access to https://github.com, and GitHub’s webhooks to be able to route back to Terraform. Similarly, an integration with GitHub Enterprise would require PTFE to have access to the local GitHub instance.
As a part of its primary mode of operation, Terraform makes API calls out to infrastructure provider APIs. Since Private Terraform Enterprise runs Terraform on behalf of users, it will therefore need access to any provider APIs that your team wants to manage with PTFE.
Terraform Release Downloads and Version Notifications
By default, Private Terraform Enterprise downloads the versions of Terraform that it executes from https://releases.hashicorp.com/, though this behavior can be customized by specifying different download locations. See Managing Tool Versions.
Private Terraform Enterprise uses the configured SMTP endpoint for sending emails.
Twilio can optionally be set up for for SMS-based 2FA. Virtual TOTP support is available separately, and does not make external API calls.