Migrating to the cloud offers organizations greater scale and agility for deploying applications. But with that agility comes greater complexity and a higher volume of manual tasks. These challenges prevent operators from taking full advantage of the benefits the cloud offers and increases strain on their teams. To address these challenges, operators need a way to automate and optimize their existing processes to move at the speed that cloud networking demands.
The complexity of managing the security policies and compliance for those applications, exacerbated by the technical difficulties faced by security teams who use manual processes for change management, may lead to delays in implementation and operations, as well as security risks.
An application can be made both continuously secure and reliable, with closer collaboration between the DevOps and DevSecOps teams, via practices that reinforce security at every stage of the development pipeline.
Transparent security promotes expedited application deployment and makes the DevOps and Platform team an equal stakeholder in producing highly resilient and secure applications.
The DevOps Promise and Reality
The promise of DevOps is to deliver a fully automated continuous integration, delivery, and deployment all the way to the point where users can consume those services.
However, the reality in many organizations is that they still are not able to implement a fully automated process when deploying applications into their production environment.
Instead, many organizations still rely on manual processes and multiple teams to fully manage their day-N operations, which hinder the progress of making those applications available to the end user quickly, consistently, and securely.
Application developers that need to scale their applications are typically required to create new change management tickets that flow through multiple teams in the organization such as system admins, network admins, and security operations. All of which have their own timelines and requirements to ensure a change can be deployed. This is a process that in some cases, may require multiple change requests, and in the end, there’s still the need to manually configure the required changes for the final consumption.
All these promises and challenges, increase the risk of mistakes, slow the process, and prevent a standardized deployment model.
Network Infrastructure Automation is how HashiCorp Consul addresses the complexities of cloud-based services and enables dynamic updates across a multi-cloud environment to ensure consistent security and compliance at the speed applications are developed, deployed, and made available for user consumption.
One way that Consul provides infrastructure automation is through Consul-Terraform-Sync (CTS). Consul-Terraform-Sync runs a daemon that watches Consul state changes at the application layer (based on service health changes, new instance deployed, etc) and forwards the data to the Zscaler Terraform modules that are then automatically triggered.
CTS uses Terraform as its underlying automation tool and leverages the Terraform Provider ecosystem to drive relevant changes. All these capabilities combined allow organizations to automate their day-N operations, so that the infrastructure is in constant alignment with the application state, while at the same time, the entire process is abstracted into a declarative model, as displayed in the picture below:
In addition to all the benefits mentioned thus far, CTS guarantees that your automation process across the Zscaler platform is easily repeatable with consistent results.
Zscaler + Consul-Terraform-Sync (CTS)
Many organizations leveraging Zscaler to secure their cloud environment and control their user’s access via zero trust policies are adopting more of a DevOps mindset every day. These organizations require agility and tools that will enable their teams to deploy applications fast and securely regardless of the environment where those applications will be hosted.
Zscaler’s integration with Consul-Terraform-Sync (CTS) provides 3 different modules for complete automation of day-N operations.
- Manage ZPA Application Segments: With the CTS module for ZPA, you can automate application segments and application server creation based on access requirements originating from the Consul Services Catalog.
- Orchestrate Firewall Management: Dynamically automate IP source group changes in the ZIA Cloud Firewall with the CTS module for ZIA to ensure strict adherence to security and compliance policies.
Using Consul-Terraform-Sync (CTS), Zscaler and HashiCorp Consul can facilitate day-N dynamic updates across the Zscaler platform based on application and security teams' demands. This joint solution was designed with scalability in mind while at the same time maintaining a zero-trust model.
As new services are registered or deregistered from the Consul catalog, Consul-Terraform-Sync updates application segments or application server IP addresses, FQDNs, and TCP ports for the relevant applications in the Zscaler Private Access platform.
The module is also designed to update Zscaler Internet Access Cloud Firewall module IP Source Groups to ensure only authorized IP addresses monitored by Consul are filtered via predefined Cloud Firewall rules.
Zscaler Private Access with Consul-Terraform-Sync (CTS)
Zscaler Private Access provides 2 CTS automation modules, which leverages the ZPA Terraform Provider
- ZPA Application Segments: From a ZPA perspective, an application is a fully qualified domain name (FQDN), local domain name, or IP address, that is defined by an administrator on a standard set of ports. An application segment resource groups a set of defined applications based on access type or user privilege. This CTS module is designed to add, update, or delete application entries in an application segment as new applications are registered in the Consul catalog.
- ZPA Application Servers: Although Zscaler Private Access can dynamically discover each application in the environment as users access them, there are specific cases in which organizations may want to individually define each application server construct. The Application Server CTS module will add, update, or delete individual application server objects based on Consul catalog updates.
Zscaler Internet Access with Consul-Terraform-Sync (CTS)
Zscaler Internet Access CTS module utilizes the ZIA Terraform Provider, to create, update, or delete Source IP Group entries. The Source IP Groups allow you to group and control source IP addresses within the Zscaler Cloud Firewall, by specifying individual IP addresses.
This CTS module will dynamically add, update, or delete individual application IP addresses within a Source IP Group.
Eliminate manual ticketing processes
Consul-Terraform-Sync is designed to automate many different tasks across different cloud environments that are traditionally handled manually by DevOps teams.
For example, updating entries at scale in a Zscaler Private Access application segment or updating IP source group entries in the Zscaler Internet Access that can automatically reflect in a cloud firewall rule.
Native Integration Between CTS and Terraform Cloud
Organizations leveraging Consul Enterprise and Terraform Cloud can integrate Consul-Terraform-Sync via its native “terraform-cloud” driver. By leveraging Terraform cloud with CTS, there are multiple benefits such as creating different project folders and workspaces for different requirements, as well as moving workspaces in between projects.
Terraform Cloud provides the ability to configure notifications to external systems such as webhooks, Teams, email, and Slack. If the organization requires a review of a particular configuration before they are applied to the production environment, customers can configure these notification capabilities to send a webhook notification to an ITSM system such as ServiceNow for incident creation and approval.
Adopt Best Practices and Reduce Risk
Minimize impact from misconfiguration errors across multiple ZPA application segments and ZIA IP Source Groups. This CTS integration will not only help organizations to reduce their risk but also ensure that their ZPA and ZIA constructs are kept up to date according to the state of their real application environment, and as changes are performed.