The ZPA Terraform provider enables customers to manage all aspects of their usage of ZPA using automation in a manner that is fast, efficient, repeatable, and secure.
You can configure, manage, and update your ZPA infrastructure easily with Terraform. Instead of using the ZPA Admin UI, you define your ZPA infrastructure in Terraform configuration files using HashiCorp Configuration Language (HCL).
HCL is a declarative language that operators use to define the desired resources. Terraform then makes the necessary API calls to Zscaler Private Access cloud to build the requested state, enabling you to automate the provisioning and deployment processes of your ZPA organization. Some of the key benefits to using Terraform and ZPA together include the following:
- It makes your ZPA infrastructure more predictable, easier to maintain, and deterministic.
- Less time is spent managing ZPA when onboarding new application.
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.
0:00:22;07 – 0:00:46;11 – Pre-Requisites
0:48:00;00 – 0:01:42;17 – Creating API Key in the ZPA Portal
0:01:44;18 - 0:02:23;19 – ZPA Provider Documentation Portal
0:02:26;23 – 0:04:00;00 - ZPA Provider Authentication Methods
0:04:02;21 – 0:04:30;00 - ZPA Cloud Environments
0:04:35;20 – 0:05:33;00 - Summary
Hello, my name is William Guilherme, and I am a Solutions Architect with the Zscaler Technology Alliances team.
In this video we’ll introduce the pre-requisites and resources available to get you started with the Zscaler Private Access Terraform Provider.
The first pre-requisite is that you must have an administrator account in the ZPA admin portal, with rights to create an API key.
Which leads to the next requirement. You must generate an API key in the ZPA portal. This API key will be used by the ZPA provider to authenticate.
Finally, you must have Terraform 0.13 or higher installed on your local computer.
To create an API key in ZPA, First, login to the ZPA administration portal with your administrator credentials.
Navigate to the administration menu
Scroll down to Public APIs and click in API Keys.
Then click in Add API Key
Provide a name to the API key and change the session interval according to your needs. The default is 3600 seconds or 60 mins.
Then click Save.
Your client secret will be displayed. Copy and save it in a secure location. Notice that this client secret is displayed only once, and you won’t be able to retrieve it.
Then copy your client ID and save in a secure location as well.
Finally, you need to copy your customer ID, which is required as part of the ZPA provider authentication.
One of the most important resources to get started with the ZPA provider, is the terraform registry documentation. To find the ZPA provider documentation, type Zscaler in the search bar and click in the documentation tab.
As you can see the Terraform registry contain all the ZPA provider documentation, including authentication methods available.
On the left-hand side, you can find examples on how you can configure specific resources, such as app connector groups, application segments, policies and much more.
Make sure to always refer to the documentation to get clarification on how to configure specific resources.
The ZPA provider provides 3 different authentication methods, which are checked in this specific order during the authentication attempt by the provider plugin.
The first method are Environment variables, which are considered best practices and hence, Zscaler’s recommended method.
You can set environment variables in Linux and MacOS by using the command export followed by the following parameters: ZPA_CLIENT_ID, ZPA_CLIENT_SECRET, ZPA_CUSTOMER_ID.
If you are on a Windows system, you can set environment variables by using the command $env in Powershell.
The second method is via static credentials. In this method, the credentials are hard-coded within your terraform .tf file.
The 3rd and final method is via JSON Configuration file. In this method, you must create a JSON file with your credential parameters. This file must be stored locally on a specific path within your local machine or server where Terraform will be executed.
Notice that Zscaler does not recommend the last two methods, and they should be used only in specific scenarios.
The ZPA cloud provides different cloud environments for specific purposes.
The production cloud is the most common and used for most production-based workloads.
The Beta environment is traditionally used for testing and development use cases. For organizations that are starting with the ZPA Terraform provider and wish to test their configuration in an isolated environment, this environment is extremely useful.
Finally, Zscaler provides the ZPA GOV cloud, which supports Zscaler’s government customers.
Regardless of the ZPA Cloud environment you decide to manage, the ZPA terraform provider got you covered.
In summary, to get started with the ZPA Terraform provider, you must have:
Administrator credentials, to generate API Keys. Also having Terraform installation 0.13 or above are core pre-requisites
When generating ZPA API keys, the client secret is displayed only once, and must be safely stored.
The Customer ID is required as part of the authentication method.
The documentation portal should always be used as guidance to build your Terraform configuration.
- The ZPA provider supports three authentication methods with Environment variables being the primary recommended option; however, static credentials and configuration files are also supported.
The ZPA Terraform Provider supports 3 different ZPA Cloud environments
- Production – Used for production-based workloads.
- Beta – Used mostly for development and test scenarios
- GOV – For government customers.