Infrastructure as Code (IaC)
The security world understands the value of automation. Eliminating manual tasks and automatically updating policies based on environmental changes reduces administrative effort and improves your security posture. Automation also improves how quickly the organization adapts to changes created from adopting new technology, updating or expanding environments, and revising best practices. Combining native template technologies with third-party tools (like Terraform) easily embeds security into your application development framework.
Writing the configuration in code also keeps the settings consistent, reduces the chance of introducing errors, and mitigates deviations between deployments.
Think of the last time a single engineer in your organization was the only source of knowledge about your deployment process. How frustrating it was when that engineer left and took that knowledge with them? Chances are, the rest of the team had to scramble to figure out the missing pieces.
By defining infrastructure as code, the process is documented for the entire team. Engineers can look at the centralized code and read how the services and processes are tied together-minimizing the risk of losing valuable knowledge. While the information could be documented separately (for example, in a wiki), we all know how difficult it can be trying to find the right information. Infrastructure as Code (IaC) addresses these concerns, and more importantly, provides a strategy for increased efficiency.
Why Terraform?
HashiCorp’s Terraform is one of the most popular and extensible open-source tools for defining and creating repeatable cloud infrastructure through code. It allows you to configure your infrastructure and services using HashiCorp Configuration Language (HCL).
A provider interacts with the various APIs required to create, update and delete resources. Terraform is used to manage infrastructure through providers such as AWS, GCP, and Azure, but also can be used to manage platform as a service (PaaS) and Software as a service (SaaS) resources.
The general idea of using Terraform to manage your Zscaler environment is to use it as a single source for creating, editing, and deleting resources in your Zscaler platform. For organizations using Terraform as their tool of choice for defining other parts of their cloud infrastructure, it’s only natural that they would also prefer to configure their Zscaler environment to keep all of their resource configurations defined in a single location.
Each time Terraform is executed, it stores information about your service configuration. By default, this information is stored locally in a file named terraform.tfstate, or it can also be stored remotely for use in a team environment.
What can Terraform providers do for your Zscaler environment?
Organizations using ZPA and ZIA as their zero trust platform can easily integrate one or both of these products into their continuous integration (CI), continuous delivery (CD), and development pipelines.
The Zscaler platform gives administrators the flexibility to configure several settings via a friendly admin UI and API. But managing configurations at scale is always challenging—a change made via the API can overwrite a setting made in the admin UI, and vice versa. This creates conflict between teams that want to manage configuration settings with an IaC approach, and the administrative, security, and IT teams that want the autonomy to quickly check and modify settings through the admin UI without the need to write code.
Rather than choosing one approach over the other, any changes made via Terraform are immediately visible in the ZPA and/or ZIA consoles. Conversely, if the ZPA and ZIA admin dashboards are intentionally (or accidentally) used to change a setting that is managed by Terraform, that change is caught and flagged by Terraform the next time it’s run—providing an extra layer of protection against unanticipated configuration changes within your Zscaler environment.
Introducing Zscaler Terraform providers
That’s why we are very excited to announce that HashiCorp has verified both Zscaler Private Access (ZPA) and Zscaler Internet Access (ZIA) Terraform providers! The providers are publicly available in the Terraform Registry and can be referenced in your Terraform configuration file.
These two newly-available Terraform providers for ZPA and ZIA automate and enforce your zero trust policies, cloud best practices, deployment, and configuration of ZPA app connectors.
The latest version of Terraform is available here. You will need to download the appropriate binaries and have Terraform installed before using the provider.
You can learn more about Terraform and providers at the HashiCorp website.
Zscaler + Terraform use cases
Use case 1: using Terraform instead of the Zscaler admin UI
Terraform automates the provisioning and deployment processes of your Zscaler tenants by building the requested state with API calls to the ZPA and ZIA API endpoints. Some of the key benefits of using Terraform and Zscaler together include:
- Reducing maintenance by making the ZPA and ZIA infrastructure more predictable and deterministic based on the state file configuration.
- Minimizing ZPA/ZIA management overhead when onboarding new applications or enforcing new security policies.
- Lowering the ZPA and ZIA infrastructure bus factor risk by defining and employing source files rather than relying on a sysadmin’s memory.
Below is a sample ZPA and ZIA Terraform configuration to perform common tasks via the ZPA admin UI.
ZPA provider - application segment
In addition to creating application segments, server groups, segment groups, and app connector groups, you can also use the ZPA provider to manage:
- Application server controllers
- Browser access application segments
- Access policy rules
- Access policy timeout rules
- Access policy forwarding rules
- Access policy inspection rules
ZIA provider – cloud firewall rule
In addition to managing ZIA cloud firewall policies, the provider also supports the management of:
- Admin users and roles
- User accounts
- URL filtering rules
- URL categories
- URL allowed and disallowed lists via advanced threat protection (ATP)
- DLP web rules
- DLP dictionaries
- . . . and more.
Use case 2: eliminate configuration drift
Over time, several different teams and administrators might edit ZPA and ZIA configuration policies, making it difficult to keep track of all the various configuration changes. By using Terraform as a single source of truth, any changes to your ZPA or ZIA infrastructure—whether intentional or by accident—are immediately detected based on Terraform’s drift management capabilities.
This allows for:
- Reduced need to analyze audit logs to find any changed configuration.
- Improved security in case unauthorized configuration changes are detected.
A key consideration when using Terraform is that the state file acts as the source of truth for your most recent infrastructure configuration. Operators can use the necessary state files when making updates or changes by employing the Remote State Storage feature from Terraform Cloud. This provides secure storage and access to your organization’s state files, reducing the risk of misconfigurations or errors.
These types of changes are traditionally hard to identify, but Terraform can identify any undesired changes the next time it is executed.
For more information on the risks associated with configuration drift, read our article: Securing Infrastructure by Embedding Infrastructure as Code (IaC) into Developer Workflows.
Use case 3: policy compliance and management
Terraform helps enforce policies covering which teams can provision and use certain types of resources. By leveraging ZPA or ZIA providers, organizations can govern and scale the Zscaler platform using automation.
- ITSM: ticket-based review processes are a bottleneck that can slow down development. Instead, you can use an integration workflow such as the one described in our guide: Zscaler Private Access and HashiCorp Terraform with ServiceNow Approval Workflow Deployment.
- Workspace management: if your organization leverages the ZIA Terraform provider to configure the Cloud Firewall module managed by the security team, you can restrict them to their specific workspace so that they cannot configure other features or resources not associated with their function. The same applies if your organization is leveraging the ZPA Terraform provider: you can set specific teams to perform changes to an application segment, while other teams can create or change access policies.
Terraform enables Zscaler customers to more easily automate security, and ensure security is consistently incorporated into all aspects of the application environment when adopting IaC as part of their CI/CD pipelines. This shift-left approach reduces friction between development and security teams, and provides rapid application deployment and better security posture.
For more information on what the ZPA and ZIA providers have to offer, look over the provider documentation on HashiCorp’s Terraform site. To ask questions, post issues, or submit contributions to the ZPA/ZIA provider project, head over to the repositories on GitHub.
Additional Resources
