Managing Palo Alto Policies with STRUCTURA.IO - Part 2
In Part 1 of this series of articles we move away from using the Panorama GUI and CLI and instead replaced that process with Infrastructure as Code which was managed and built using STRUCTURA.IO. This was the first step that had to happen to get closer to full automation for the Firewall policies. The Infrastructure as Code was now in source control, but applying the changes to Panorama was still a manual process, albeit a more streamlined process than using the GUI and CLI.
The Git Repository was already stored in Azure DevOps so it made sense to utilize Azure DevOps Pipelines to automate the change window. However, before the pipelines were built we needed to expand on how Git was used. We had a simple repo and updates were continuously pushed to the main branch (the master branch). To better use Git and gain some of its additional benefits, we knew that we wanted to use Pull Requests for the final line of defense to catch any errors in interpreting the ticket requirements into IaC. For this to happen the team needed to use branches. As many members of the team were new to using Git we needed to keep it simple but effective. The process became; Create a branch using the ticket ID as the name, Update the IaC using STRUCTURA.IO to reflect the requirements of the ticket, Commit and push the changes to the Azure DevOps Repository, and finally create a Pull Request for review. Other team members are now able to see exactly what was added, modified, or removed from the source files, review, suggest changes, and once ready approve the change. This is also where the first pipeline was introduced. We added a “Plan” pipeline that was executed on all Pull Requests when created or updated, the pipeline would run a Terraform Plan on the branch and return the results to the Pull Request with a count for Resources added, modified, and Deleted along with the more in-depth plan output Terraform provides. This gave the team members another avenue to review what would happen if the proposed changes were eventually pushed to the firewall.
The next step in the process is the Merge action. Once the Pull Request was approved, it was then merged into the Master Branch. This is when the second Pipeline entered into the process. This pipeline was to validate the code, apply the master branch (now containing all the merged tickets) to the Panorama and then commit the changes on the Panorama to make them live. The pipeline was scheduled to run during the change windows, and would report back to the team on the results.