The objective of this blog is to describe and demonstrate the use of Terraform deployment and configuration templates to build out CI / CD workflows.
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:
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:
Deployment / Architecture Overview
The first part of the deployment leverages the AWS two tier architecture templates to deploy:
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.
Step 1: Deploy the two tier application on AWS with a zero trust access policy configured on the
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
Summary / Conclusion
The primary takeaways from this article is that the combination of the Terraform templates and the ```panos``` terraform provider:
Please view the attached video which demonstrates this process.