Zscaler Private Access - Ansible Collection Module (Unofficial)

Cloud provisioning is a critical element of the modern cloud computing model. We live in the age of microservices, where automation is not a nice-to-have anymore. It became an integral part of everyday operations.

In 2021, I introduced an Unofficial Terraform Provider for ZPA, that allows for the provisioning and configuration of several resources using the available APIs. Luckily, there is a wide variety of automation and orchestration which can save us time while simultaneously increasing the performance and accuracy of provisioning and configuration management processes.

In 2022, I decided to take on a different challenge and expand the use of the ZPA APIs by building a ZPA Ansible Collection Module for provisioning and configuration management of all ZPA resources.
In this article, I will explore the benefits of using cloud automation with Ansible to provision and manage your ZPA infrastructure. I’ll discuss several use cases that illustrate the power of this tool in the areas of provisioning, configuration, and compliance.

Note: The discussion about the differences between Terraform and Ansible is outside of the scope of this article.

Important: :warning: It is important to emphasize that this Ansible Collection Module is not in any way supported or maintained by Zscaler engineering, product or support teams; hence, it is provided “AS IS” as a community effort.

Ansible role in cloud automation

Ansible is, first and foremost, an automation tool similar to Terraform. With the right content (roles, modules, and other plugins), Ansible can automate almost anything. And cloud management is no exception, which means that we can automate our provisioning processes in a relatively easy way.
With a little help from continuous integration and continuous deployment (CI/CD) products, Ansible can be transformed into a mighty orchestration tool. We can start combining standalone tasks into complex workflows that automate complex IT processes.

Furthermore, if you bind workflow executions to events from your monitoring systems, you can take some serious steps towards a self-healing infrastructure.
However, none of the previously described tasks are possible without integrating Ansible with a cloud provider, in this case ZPA.

Why should cloud providers have Ansible integrations?

The traditional model for many businesses is to separate infrastructure provisioning processes from configuration management workflows. While configuration management is often (at least partially) automated, it is not uncommon for system administrators to manage infrastructure manually, which is slow, laborious, and error-prone.

By provisioning your ZPA cloud tenant with Ansible, system administrators can perform day one and day two operations using a modern and reliable tool. And the Ansible playbooks used to manage the ZPA resources also serve as human-readable and machine-executable documentation.

Many organizations already use Ansible for their non-infrastructure automation needs. Thus, having a high-quality Ansible integration, offers a seamless transition for such organizations, by unifying their management tools.

Benefits of using Ansible for ZPA cloud automation

Ansible is not the only tool that we can use to manage cloud resources like ZPA. But because of its simplicity and flexibility, it does offer quite a few advantages compared to similar tools like Puppet or Chef.

  • No need for a separate configuration management tool: Ansible is so powerful, that you can provision any ZPA cloud resource, and at the same time provision App connectors at scale very easily and in a matter of minutes. Furthermore, all you need is a single Ansible playbook, although chaining multiple Ansible playbooks together is a more flexible alternative.

  • Less vendor lock-in: Ansible modules serve as a thin abstraction layer over the ZPA application programming interface (API). Abstraction gives the freedom and flexibility to switch between different cloud providers at any time with minimal effort. And it enables us to work with multiple clouds simultaneously without risking the cloud-specific tools overload.

  • User-friendly automation layer: Ansible playbooks are YAML files that describe the desired state of the system we want to manage. Writing Ansible playbooks requires no prior development or programming experience. As there is a plethora of online resources to help you learn how to author your own Ansible Playbooks. To facilitate the use of this ZPA Ansible Collection, I also developed multiple playbooks that can be used to configure and manage any of the available ZPA resources.

Ansible use cases for ZPA cloud


As previously mentioned, Ansible can help manage almost anything. But in this section, we will look at three different ZPA related use cases that benefit significantly from integrating with Ansible.

Creating new ZPA cloud resources

Creating a new application segment does not sound too complicated. All we need is to click a few buttons, and that’s it. Right? In reality, it is never this simple. Before you create a new application segment, you need to create a server group, with dynamic discovery enabled. If dynamic discovery is disabled, then you must list the application servers hosting the defined applications and a segment group that will allow you to configure user access policies based on application segments or segment groups. That server group must be associated with an App Connector Group. The list goes on and on.

Luckily, you can describe all those steps in a reusable Ansible playbook once, and then run them as many times as needed. We can also parameterize our Ansible playbook. Parameterization allows us to modify the deployment process without having to edit the Ansible playbook. And with a little help from [Ansible Tower](Ansible Tower — Ansible Documentation, we can package our parameterized Ansible playbook into a self-service catalog item anyone can use.

Below is a sample Ansible playbook configuration to programmatically create an application segment:

App Connector Group

    - name: Create First App Connector Group Example1
      zpa_app_connector_groups:
        name: "Example1"
        description: "Example1"
        enabled: true
        city_country: "California, US"
        country_code: "US"
        latitude: "37.3382082"
        longitude: "-121.8863286"
        location: "San Jose, CA, USA"
        upgrade_day: "SUNDAY"
        upgrade_time_in_secs: "66600"
        override_version_profile: true
        dns_query_type: "IPV4"
      register: app_connector_id

Create Server Group

    - name: Create/Update/Delete a Server Group
      zpa_server_group:
        name: "Example"
        description: "Example"
        enabled: true
        dynamic_discovery: true
        app_connector_groups:
          - id: "{{ app_connector_id.data.id }}"
      register: server_group_id

Create Segment Group

    - name: Create/Update/Delete a Server Group
      zpa_segment_group:
        name: ”Example”
        description: ”Example”
        enabled: true
        tcp_keep_alive_enabled: "1"
      register: segment_group_id

Create Application Segment

Finally, now we can create the actual application segment, by referencing the previously created resources, which the application segment depends on.

    - name: Create an Application Segment
      zpa_application_segment:
        name: Example Application Test
        description: Example Application Test
        enabled: true
        health_reporting: ON_ACCESS
        bypass_type: NEVER
        is_cname_enabled: true
        tcp_port_range:
          - from: "80"
            to: "80"
        domain_names:
          - crm1.example.com
          - crm2.example.com
        segment_group_id: "{{ segment_group_id.data.id }}"
        server_groups:
          - id: "{{ server_group_id.data.id }}"
      register: application_segment

This is just one example of what this ZPA Ansible Collection can do. In addition to creating application segments, server groups and segment groups, you can also create playbooks and roles to manage the following resources:

  • App Connector Groups
  • App Connector Controllers
  • Service Edge Groups
  • Service Edge Controllers
  • LSS Controllers
  • Browser Access
  • Access Policy Rules
  • Access Policy Timeout Rules
  • Access Policy Forwarding Rules

Managing existing cloud resources

Ansible can use a cloud provider as a source of information about existing resources. This dynamic approach makes manual inventory management a thing of the past. We can now manage hundreds of ZPA resources without breaking a sweat.

Combining dynamic inventory with Ansible’s ability to execute operations in batches, we get a potent tool for performing rolling updates of multiple resources.

Ensuring compliance

By following the best practices when authoring our ZPA Ansible playbooks, we will produce a concise description of the desired state. We already know that Ansible will, when executing the instructions, robustly enforce this state on the managed resource.

But we can reuse the same description to detect unauthorized or unintentional configuration changes, commonly referred to as configuration drift. Running Ansible in check mode will produce a list of deviations from the desired state. For example, we can detect changes that may have been performed manually outside of the Ansible playbook to an access policy or timeout policy rule and bring those policies back to its correct definition.

Wrap Up

Ansible is probably the only widely-used automation tool that allows us to describe the whole deployment uniformly: from the provisioning phase to the holistic configuration of the applications that run on top of the cloud resources.

Ansible Collections play a central role in Ansible’s flexibility. They provide, among other things, integrations with cloud providers that unlock cloud-management capabilities. To make the utilization easier, I have also developed series of playbooks to allow for the provisioning of the several ZPA resources. Over time, the plan is to develop additional modules as further APIs become available, along with its respective playbooks.

Interested in exploring the ZPA Ansible Collection? To get started check out the project in the GitHub repository here.

Want to contribute or open an issue? Find the project here.
Check out the part 2 of this article, to learn how to install the ZPA Ansible collection using Ansible Galaxy or from a local file that can be downloaded from the project GitHub page.

Additional Resources and Documentation

2 Likes