Terraform Deployment and Configuration Templates

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
L2 Linker

Objectives

 

The objective of this blog is to describe and demonstrate the use of Terraform deployment and configuration templates to build out CI / CD workflows.

 

Executive Summary

 

Application developers working in agile teams have the need to push and deploy code numerous times a day. The agility of the dev teams puts a lot of pressure on the infrastructure and security teams to keep pace. Consequently, quite often this results in security teams slowing down the deployment of apps into production environments.

 

However, Palo Alto Networks has built out a slew of automation capabilities that provide security teams with the capabilities and tools to demonstrate the same agility as the app teams.  These capabilities enable enterprises as a whole to succeed by deploying the line of business application in a timely and more importantly, a secure manner.

 

The following sections describe:

  • How app teams and security teams can leverage code repositories such as github to store both application artifacts and security policies as code.
  • How security teams can leverage ```Terraform``` and the Palo Alto Networks ```Terraform provider``` to leverage CI / CD workflows to keep pace with line of business requirements.

 

CI / CD Workflow Overview

 

Application teams leverage repositories such as github and others,  to not only store and backup the code-base, but also for the purpose of change management. Additionally, CI / CD workflows are put in place to track code commit to trigger build, deploy and test phases. The key point to note is that the whole process is automated and configuration flags determine which environments (test, staging or production) to target.

 

Security teams have typically not had the luxury of tools and capabilities which have allowed them to adopt workflows as described above, up till now! The availability of the Terraform Provider from Palo Alto Networks allows security teams to:

 

  • define security policy and configuration as code.
  • store security as code in a code repository (such as github).
  • enable CI / CD workflows using tools such as Jenkins that will automatically trigger “builds” which will result in the configuration of the policies on either Panorama or the VM-Series firewalls.

 

 

Deployment / Architecture Overview

 

The first part of the deployment leverages the AWS two tier architecture templates to deploy:

 

  • all the infrastructure components (VPC, subnets, network interfaces etc)
  • a VM-Series FW on AWS with 3 interfaces (management, untrust and trust).
  • a backend web server in the trust zone.
  • bootstrap the VM-Series FW with zero trust security policies.

 

Demo Flow and CI / CD Process

 

Figure 1. below illustrates the workflow and actions performed by both app and security teams resulting in dramatic productivity gains and achieving line of business goals.

 

Screen Shot 2018-06-28 at 2.52.27 PM.png

 

Step 1: Deploy the two tier application on AWS with a zero trust access policy configured on the

             VM-Series firewall.

 

Step 2: Security teams push the required configuration and security policies into github for the

             first application deployed.

 

Step 3: The code commit from the security team triggers a CI / CD pipeline on Jenkins, which

              automatically pushes the security policy on to the VM-Series firewall.

 

At this point we have demonstrated how the security teams can keep pace with application teams to secure line of business applications.

 

The next steps further demonstrate the agility and productivity gains by adopting this workflow for the frequent and subsequent deployment of line of business applications. Frequent application deployments into production require security teams have to once again react quickly to ensure the application is appropriately secured.

 

Step 4: Application team #2 pushes / deploys a new application onto the AWS infrastructure

             using a deployment tool such as AWS code deploy.

 

Step 5: The security team now creates a new terraform template using the ```panos``` provider

              in order to secure the new application.

 

Step 6: The Jenkins pipeline described in Step 3 above triggers the automatic configuration of

              security policies defined as code onto either the VM-Series firewalls or indirectly

              through Panorama.

 

Summary / Conclusion

 

The primary takeaways from this article is that the combination of the Terraform templates and the ```panos``` terraform provider:

 

  • enable security teams to be proactive.
  • leverage automation to dramatically increase the speed and security of line of business applications deployed on public cloud platforms.
  • define and store security as code.
  • security teams never have to “touch” or access the firewall directly. All interaction is facilitated by the ```panos``` terraform provider.

 

Demo

 

Please view the attached video which demonstrates this process. 

 

 

[1] Terraform Cloud Deployment Templates

[2] Palo Alto Networks “panos” provider

 

  • 11970 Views
  • 0 comments
  • 3 Likes
Register or Sign-in