Native vs. Add-on Support and the Implications of Each
Security administrators, like everybody else managing resources in the cloud, are using Terraform to help achieve consistency and scalability in the public cloud. Hence, when looking for a cloud network security product, one of the critical requirements is the support of Terraform. Legacy next-generation firewalls (NGFW) like Palo Alto Networks, Checkpoint, and Fortinet claim support for Terraform, but Terraform support was added as an afterthought – decades after their legacy appliance approaches were built.
Because it was not in their original design, the NGFWs had to retrofit their products to newer technology tools like Terraform, creating a disjoint workflow with separate orchestration and configuration mechanisms.
A cloud-native approach like Valtix, built with cloud-native constructs in mind, makes using Terraform much simpler and easier. In this blog, the differences between legacy and cloud-native approaches will be reviewed, along with the reasons why a cloud-native product is necessary to protect cloud workloads.
Terraform Ecosystem – Not All Terraform Integration is Equal
To understand the difference, one must first examine the two integration components in the Terraform ecosystem: Terraform Provider and Terraform Module.
Terraform Providers are plugins that each vendor provides to interact with their product. A user would use the vendor’s Terraform Provider to define resource blocks which in turn creates the resource based on the resource block defined.
Terraform Modules are built upon Terraform Providers. Terraform Modules would use Terraform Providers (could be multiple providers) to deploy a group of resources dependent on each other and share the same lifecycle. This is useful if you have a fixed set of resources that needs to be provisioned repeatedly.
Traditional NGFW vs. Valtix Terraform Support – It’s Different
The main difference between Valtix and traditional NGFW is orchestration – as it relates to the use of Providers vs. Modules. Traditional NGFW Terraform support uses Terraform Modules for orchestration, and Valtix uses Terraform Providers directly.
What results from the NGFW Terraform Module approach to orchestration is much more complex, brittle, and hard to maintain. In addition, with any of the NGFWs, you get a set of templates – it’s on you to modify them to fit your architecture. These templates are provided with ‘best effort support,’ and we all know how difficult it can be to get help from the NGFW vendors (and potentially expensive). Each Terraform Module is also different for each cloud, which makes multi-cloud scenarios even more challenging and costly to deploy and maintain – I’ll cover this and other deficiencies in the next section.
Valtix publishes a Terraform Provider that interacts with the Valtix Controller. The Valtix Controller then performs the orchestration and configuration management. The Valtix Controller abstracts the orchestration complexity and allows users to deploy security and protect workloads within minutes quickly in a consistent way across clouds.
Figure1: The NGFW approach to Terraform Modules based on partially-supported, complex templates that differ per each cloud
Figure 2: The Valtix approach to Terraform Providers – simple to maintain, standardized, and unified across clouds
The Traditional NGFW Approach – Complexity, Inflexibility, and Blind Spots
Traditional NGFW Terraform integration actually consists of 2 parts: Terraform Modules for orchestration (as we’ve discussed) and additionally Terraform Providers for configuration management. Modules are treated like a black box: you know your input, and it generates an output, but what happens in between is a mystery. Let’s look at the potential issues with orchestration using Terraform Modules
- Fixed deployment model – A module assumes a specific deployment model is used and deploys a fixed set of resources, even if they are not used. The deployment model may not be what a user is looking for.
- Modules create complexity in Terraform scripts – Terraform Modules contain many resource blocks, increasing the script’s complexity. For example, looking at one Terraform Module from Palo Alto Networks, we see 97 resource blocks vs. 7 with Valtix Terraform Provider.
- Modules create an out-of-band workflow – The modules that the security incumbent provides typically use the cloud provider’s Terraform Provider to orchestrate the topology. This creates a discontinued workflow when securing workloads. As a result, the security team cannot translate the change made in the network to security policies.
- Different modules for each cloud platform – Each cloud platform requires a separate Terraform Module, which means more scripts to maintain.
- Separate management plane to maintain – To manage a large number of NGFWs, vendors (such as Palo Alto Networks, Fortinet, and Checkpoint) suggest a separate management tool that provides them for policy management. This requires the IT team to manage yet another device or a fleet of devices (for large-scale deployment, the management tool will also need to scale).
- Community Tier support – Modules are community support tier, which means it is as-is and best effort. Palo Alto Networks even put out a support notice stating that they “do not provide technical support or help in using or troubleshooting the components of the project.”
Source: Publicly Available Palo Alto Networks Terraform Provider Documentation https://registry.terraform.io/providers/PaloAltoNetworks/panos/latest/docs
Valtix’s Approach – Cloud Native, Unified, and Agile
Valtix uses the Terraform Provider to create a simple approach to support both orchestration and configuration management. The benefits of using Terraform Provider are:
- Consistent approach between the Valtix Console and Terraform – Users can easily map UI action with Terraform resource block. This allows users to start easily with the UI and migrate to Terraform. Customers can use Valtix’s Terraform Export feature to export Terraform equivalent resource blocks through the UI.
- Deployment model flexibility – Valtix does not assume deployment models. Customers can choose the deployment model that fits their needs and deploy what’s needed. For example, customers can choose between a centralized or distributed model or a hybrid one.
- Consistent across multi-cloud environments – you can use the same Terraform script for all cloud platforms to standardize multi-cloud deployments.
- Terraform Partner Tier support – Valtix Provider is a verified partner in the Terraform ecosystem, which means customers have dedicated support from Valtix to address any issues or enhancements needed for your use case.
- Zero Maintenance on the Valtix Controller – Valtix maintains the Controller which is offered as a SaaS, so there is less burden on the IT team.
Figure 3: Valtix provides a best-in-class Terraform Provider vs. the disjointed NGFW Terraform approach
Conclusion: Cloud Native Approaches Like Valtix Offer Simplicity and Agility – Traditional NGFWs Can’t
Traditional NGFWs use Terraform Modules because the cloud is an afterthought. Their solution was meant for on-prem data centers where apps, workloads, and infrastructures are more static, and perimeters are well-defined. However, as organizations move to the cloud, and grow their cloud deployments, a cloud-native solution with a unified approach for IaC tools is needed. Use the product the way it was designed. Legacy NGFW was intended for the on-prem datacenter, so leave it in the datacenter. Valtix is a cloud-native product designed for the cloud to address the unique challenges organizations face when securing the cloud.
