This Update<\/h2>\n
There were two things I wanted to add to the design:<\/p>\n
- \n
- Detailed permissions for the service principal used by the workload DevOps pipeline, limiting the scope of change that is possible in the hub.<\/li>\n
- DevOps pipelines so I could test the above.<\/li>\n<\/ul>\n
The Code<\/h2>\n
You’ll find 3 folders in the Bicep code<\/a> now:<\/p>\n
- \n
- hub<\/strong>: This deploys a (legacy) VNet-based hub with Azure Firewall.<\/li>\n
- customRoles<\/strong>: 4 Azure custom roles are defined. This should be deployed after the hub.<\/li>\n
- spoke1<\/strong>: This contains the code to deploy a skeleton VNet-based (spoke) workload with updates that are required in the hub to connect the VNet and route ingress on-prem traffic through the firewall.<\/li>\n<\/ul>\n
DevOps Pipelines<\/h2>\n
The hub and spoke1 folders each contain a folder called .pipelines. There you will find a .yml file to create a DevOps pipeline.<\/p>\n
The DevOps pipeline uses Azure CLI tasks to:<\/p>\n
- \n
- Select the correct Azure subscription & create the resource group<\/li>\n
- Deploy each .bicep file.<\/li>\n<\/ul>\n
My design uses 1 sub for the hub and 1 sub for the workload. You are not glued to this bu you would need to make modifications to how you configure the service principal permissions (below).<\/p>\n
To use the code:<\/p>\n
- \n
- Create a repo in DevOps for (1 repo) hub and for (1 repo) spoke1 and copy in the required code.<\/li>\n
- Create service principals in Azure AD.<\/li>\n
- Grant the service principal for hub owner rights to the hub subscription.<\/li>\n
- Grant the service principal for the spoke owner rights to the spoke subscription.<\/li>\n
- Create ARM service connections in DevOps settings that use the service principals. Note that the names for these service connections are referred to by azureServiceConnection in the pipeline files.<\/li>\n
- Update the variables in the pipeline files with subscription IDs.<\/li>\n
- Create the pipelines using the .yml files in the repos.<\/li>\n<\/ol>\n
Don’t do anything just yet!<\/p>\n
Service Principal Permissions<\/h2>\n
The hub service principal is simple – grant it owner rights to the hub subscription (or resource group).<\/p>\n
![\"\"](\"https:\/\/aidanfinn.com\/wp-content\/uploads\/2021\/12\/Service-Principal-Permissions-Expanded.png\")
<\/a><\/p>\nThe workload is where the magic happens with this DevSecOps design. The workload updates the hub suing code in the workload repo that affects the workload:<\/p>\n
- \n
- Ingress route from on-prem to the workload in the hub GatewaySubnet.<\/li>\n
- The firewall rules for the workload in the hub Azure Firewall (policy) using a rules collection group.<\/li>\n
- The VNet peering connection between the hub VNet and the workload VNet.<\/li>\n<\/ul>\n
That could be deployed by the workload DevOps pipeline that is authenticated using the workload’s service principal. So that means the workload service principal must have rights over the hub.<\/p>\n
The quick solution would be to grant contributor rights over the hub and say “we’ll manage what is done through code reviews”. However, a better practice is to limit what can be done as much as possible. That’s what I have done with the customRoles folder<\/a> in my GitHub share.<\/p>\n
Those custom roles should be modified to change the possible scope to the subscription ID (or even the resource group ID) of the hub deployment. There are 4 custom roles:<\/p>\n
- \n
- customRole-ArmValidateActionOperator.json<\/strong>: Adds the CUSTOM – ARM Deployment Operator role, allowing the ARM deployment to be monitored and updated.<\/li>\n
- customRole-PeeringAdmin.json<\/strong>: Adds the CUSTOM – Virtual Network Peering Administrator role, allowing a VNet peering connection to be created from the hub VNet.<\/li>\n
- customRole-RoutesAdmin.json<\/strong>: Adds the CUSTOM – Azure Route Table Routes Administrator role, allowing a route to be added to the GatewaySubnet route table.<\/li>\n
- customRole-RuleCollectionGroupsAdmin.json<\/strong>: Adds the CUSTOM – Azure Firewall Policy Rule Collection Group Administrator role, allowing a rules collection group to be added to an Azure Firewall Policy.<\/li>\n<\/ul>\n
Deploy The Hub<\/h2>\n
The hub is deployed first – this is required to grant the permissions that are required by the workload’s service principal.<\/p>\n
Grant Rights To Workload Service Principals<\/h2>\n
The service principals for all workloads will be added to an Azure AD group (Workloads Pipeline Service Principals in the above diagram). That group is nested into 4 other AAD security groups:<\/p>\n
- \n
- Resource Group ARM Operations<\/strong>: This is granted the CUSTOM – ARM Deployment Operator role on the hub resource group.<\/li>\n
- Hub Firewall Policy<\/strong>: This is granted the CUSTOM – Azure Firewall Policy Rule Collection Group Administrator role on the Azure Firewalll Policy that is associated with the hub Azure Firewall.<\/li>\n
- Hub Routes<\/strong>: This is granted the CUSTOM – Azure Route Table Routes Administrator role on the GattewaySubnet route table.<\/li>\n
- Hub Peering<\/strong>: This is granted the CUSTOM – Virtual Network Peering Administrator role on the hub virtual network.<\/li>\n<\/ul>\n
Deploy The Workload<\/h2>\n
The workload now has the required permissions to deploy the workload and make modifications in the hub to connect the hub to the outside world.<\/p>\n","protected":false},"excerpt":{"rendered":"
In this post, I will share the details for granting the least-privilege permissions to GitHub action\/DevOps pipeline service principals for a DevSecOps continuous deployment of Azure Firewall. Quick Refresh I wrote about the design of the solution and shared the code in my post, Enabling DevSecOps with Azure Firewall. There I explained how you could … Continue reading “Azure Firewall DevSecOps in Azure DevOps”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":22524,"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":[488,161,170,383,306,482,489,384,480,386,483,431,80,430,324,190,485],"class_list":["post-22525","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","tag-action","tag-arm","tag-azure","tag-azure-devops","tag-azure-firewall","tag-bicep","tag-custom-rbac-roles","tag-devops","tag-devsecops","tag-github","tag-iac","tag-infrastructure-as-code","tag-networking","tag-pipeline","tag-routing","tag-security","tag-user-defined-route"],"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\t
- Hub Firewall Policy<\/strong>: This is granted the CUSTOM – Azure Firewall Policy Rule Collection Group Administrator role on the Azure Firewalll Policy that is associated with the hub Azure Firewall.<\/li>\n
- customRole-PeeringAdmin.json<\/strong>: Adds the CUSTOM – Virtual Network Peering Administrator role, allowing a VNet peering connection to be created from the hub VNet.<\/li>\n
- customRole-ArmValidateActionOperator.json<\/strong>: Adds the CUSTOM – ARM Deployment Operator role, allowing the ARM deployment to be monitored and updated.<\/li>\n
- customRoles<\/strong>: 4 Azure custom roles are defined. This should be deployed after the hub.<\/li>\n
- hub<\/strong>: This deploys a (legacy) VNet-based hub with Azure Firewall.<\/li>\n