The Concept<\/h2>\n
Hold on, because there’s a bunch of things to understand!<\/p>\n
DevSecOps<\/h3>\n
The DevSecOps methodology is more than just IaC. It’s a combination of people, processes, and technology to enable a fail-fast agile delivery of workloads\/applications to the business. I discussed here<\/a> how DevSecOps can be used to remove the friction of IT to deliver on the promises of the Cloud.<\/p>\n The Azure features that this design is based on are discussed in concept here<\/a>. The idea is that we want to enable Devs\/Ops\/Security to manage firewall rules in the workload’s Git repository (repo). This breaks the traditional model where the rules are located in a central location. The important thing is not the location of the rules, but the processes that manage the rules (change control through Git repo pull request reviews) and who (the reviewers, including the architects, firewall admins, security admins, etc).<\/p>\n So what we are doing is taking the firewall rules for the workload and placing them in with the workload’s code. NSG rules are probably already there. Now, we’re putting the Azure Firewall rules for the workload in the workload repo too. This is all made possible thanks to changes that were made to Azure Firewall Policy (Azure Firewall Manager) Rules Collection Groups – I use one Rules Collection Group for each workload and all the rules that enable that workload are placed in that Rules Collection Group. No changes will make it to the trunk branch (deployment action\/pipelines look for changes here to trigger a deployment) without approval by all the necessary parties – this means that the firewall admins are still in control, but they don’t necessarily need to write the rules themselves … and the devs\/operators might even write the rules, subject to review!<\/p>\n This<\/em> is the killer reason to choose Azure Firewall over NVAs – the ability to not only deploy the firewall resource, but to manage the entire configuration and rule sets as code, and to break that all out in a controlled way to make the enterprise more agile.<\/p>\n If you’ve read my posts on Azure routing (How to Troubleshoot Azure Routing?<\/a> and BGP with Microsoft Azure Virtual Networks & Firewalls<\/a>) then you’ll understand that there’s more going on than just firewall rules. Packets won’t magically flow through your firewall just because it’s in the middle of your diagram!<\/p>\n The spoke or workload will also need to deploy:<\/p>\n In this section, I’ll explain the code layout and placement.<\/p>\n You can find my public repo, containing all the Bicep code here<\/a>. Please feel free to download and use.<\/p>\n You will have two Git repos:<\/p>\n I have written a more detailed update on this section, which can be found here<\/a>.\u00a0<\/em><\/p>\n Each Git repo needs to authenticate with Azure to deploy\/modify resources. Each repo should have a service principal in Azure AD<\/a>. That service principal will be used to authenticate the deployment, executed by a GitHub action or a DevOps pipeline. You should restrict what rights the service principal will require. I haven’t worked out the exact minimum permissions, but the high-level requirements are documented below:<\/p>\n <\/p>\n Some of you might be worried now – what’s to stop a developer\/operator working on Workload A from accidentally creating rules that affect Workload X?<\/p>\n This is exactly why you implement standard practices on the Git repos:<\/p>\n Now, I can only submit a suggested set of rules (and route\/peering) changes that must be approved by the necessary people. I can still create my code without delay, but a change control and rollback process has taken control. Obviously, this means that there should be SLAs on the review\/approval process and guidance on pull request, approval, and rejection actions.<\/p>\n Now you have the design and the Bicep code to enable DevSecOps with Azure Firewall.<\/p>\n","protected":false},"excerpt":{"rendered":" In this post, I will share how you can implement DevSecOps with Azure Firewall, with links to a bunch of working Bicep files to deploy the infrastructure-as-code (IaC) templates. This example uses a “legacy” hub and spoke – one where the hub is VNet-based and not based on Azure Virtual WAN Hub. I’ll try to … Continue reading “Enabling DevSecOps with Azure Firewall”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":19553,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"_wpcom_ai_launchpad_first_post":false,"footnotes":""},"categories":[5],"tags":[170,306,482,480,242,484,433,483,431,325,434,485,289,281,437],"class_list":["post-22495","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","tag-azure","tag-azure-firewall","tag-bicep","tag-devsecops","tag-firewall","tag-gatewaysubnet","tag-hub","tag-iac","tag-infrastructure-as-code","tag-route-table","tag-spoke","tag-user-defined-route","tag-virtual-network","tag-vnet","tag-vnet-peering"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tOther Bits<\/h3>\n
\n
The IaC<\/h2>\n
My Code<\/h3>\n
The Git Repo Design<\/h3>\n
![\"\"](\"https:\/\/aidanfinn.com\/wp-content\/uploads\/2021\/12\/Repos-And-Resources.png\")
<\/a><\/p>\n\n
\n
\n
Action\/Pipeline Permissions<\/h3>\n
![\"\"](\"https:\/\/aidanfinn.com\/wp-content\/uploads\/2021\/12\/Service-Principal-Permissions-Expanded.png\")
<\/a><\/p>\nTrunk Branch Protection &\u00a0 Pull Request<\/h2>\n
\n
And There You Have It<\/h2>\n