How to handle existing NSGs to update securityRules #6416
-
|
Hello, We are setting up a Bicep file that will create network security groups including a set of default securityRules. This works fine the first time. However, it might be manual updates in the NSGs that are ok and that we should not override upon a new deployment from the Bicep template. But as this is an incremental update I was thinking that it will be no problem. Our setup.
We do not specify properties as we do not want to setup any security rules here.
Strategy
I then removed to setup the security rules from the Bicep to only check what if we just did run incremental update on the NSG that only specifies the name (not properties). Result was the same, the custom rules were removed.
|
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 5 replies
-
|
Hi @e-karlsson , You could refer to existing NSGs and only update properties that you need. Check out a Bicep code example with existing key-vault resource resource kv 'Microsoft.KeyVault/vaults@2019-09-01' existing = {
name: kvName
scope: resourceGroup(subscriptionId, kvResourceGroup )
}
module sql '../modules/sqldb.bicep' = {
name: 'deploySQL'
params: {
sqlServerName: sqlServerName
location: 'eastus'
adminLogin: adminLogin
adminPassword: kv.getSecret('ExamplePassword')
}
}Reference to the complete Bicep example code snippet could be found here: |
Beta Was this translation helpful? Give feedback.
-
|
there is really no simple solution here, the best thing to do is to lock down any manual changes from the NSG's and only do configuration as code deployments. In saying that, there is a complicated workaround. I would even say, that i recommend the method above as a preference to this method, based on it's complexity. Here is a template that deploys a website. https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/AppServiceWebSite.bicep part of it uses the following resource appsettingsCurrent 'Microsoft.Web/sites/config@2021-03-01' existing = [for (ws, index) in WebSiteInfo: if (WSInfo[index].match) {
name: '${Deployment}-ws${ws.Name}/appsettings'
}]https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/AppServiceWebSite.bicep#L157 module websiteSettings 'x.appServiceSettings.bicep' = [for (ws, index) in WebSiteInfo: if (WSInfo[index].match) {
name: 'dp${Deployment}-ws${ws.Name}-settings'
params: {
ws: ws
appprefix: 'ws'
Deployment: Deployment
appConfigCustom: myAppConfig[ws.stack]
appConfigCurrent: appsettingsCurrent[index].list().properties
appConfigNew: {
APPINSIGHTS_INSTRUMENTATIONKEY: AppInsights.properties.InstrumentationKey
APPLICATIONINSIGHTS_CONNECTION_STRING: 'InstrumentationKey=${AppInsights.properties.InstrumentationKey}'
}
}
dependsOn: [
website[index]
]
}]The first time you deploy that it will fail... because the website does not exist as yet. So there is a feature flag to disable that running the very first time OR you can just let it error the very first time, it doesn't cause any issue, except that part will error out. That Module calls this file: https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/x.appServiceSettings.bicep param ws object
param appprefix string
param Deployment string
param appConfigCustom object
@secure()
param appConfigCurrent object
@secure()
param appConfigNew object
resource WS 'Microsoft.Web/sites@2021-01-01' existing = {
name: '${Deployment}-${appprefix}${ws.Name}'
}
resource appSettings 'Microsoft.Web/sites/config@2021-01-15' = {
name: 'appsettings'
parent: WS
properties: union(appConfigCustom,appConfigCurrent,appConfigNew)
}That performs a fairly simple task, which uses a So in theory you can do the same with NSG rules. You don't need a list() just the resource reference and then you can get access to the NSG resource NSGCurrent 'Microsoft.Network/networkSecurityGroups@2021-05-01' existing = {
name: 'ACU1-BRW-AOA-T5-nsgSNWAF01'
}
output nsgRulesArray array = NSGCurrent.properties.securityRulesThis is not something that I have specifically tested, so I couldn't specifically recommend this, however it could most likely work. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @brwilkinson ! Thank you for your reply. I tested out this setup and got it to work sometimes, and sometimes not. For example, one common error we saw: So when we have applied a default rule before through IaC, and then redeployed it the union functionality was not working as expected. Think we need to solve it by PowerShell or similar. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I think this is perhaps one of the problems to be solved, with app settings, it's key value pairs, so easy to union. With NSGs you have other considerations, since they are objects that could have duplicates in names or rules Etc. So rather than just merging, there should likely be some audit process to refine the rules etc, ensure you don't have duplicates and overlaps etc. resource NSG 'Microsoft.Network/networkSecurityGroups@2021-05-01' existing = {
name: 'NSG1'
}
output test array = NSG.properties.securityRules
output test2 array = NSG.properties.defaultSecurityRulesdid you do union the securityRules or defaultSecurityRules? |
Beta Was this translation helpful? Give feedback.
-
|
so I confirmed that securityrules only shows your custom rules. resource NSG 'Microsoft.Network/networkSecurityGroups@2021-05-01' existing = {
name: 'ACU1-BRW-AOA-T5-nsgSNWAF01'
}
output test array = NSG.properties.securityRules
output test2 array = NSG.properties.defaultSecurityRules[
{
"name": "WAF_Default_Inbound",
"id": "/subscriptions/b8f402aa-20f7-4888-b45c-3cf086dad9c3/resourceGroups/ACU1-BRW-AOA-RG-T5/providers/Microsoft.Network/networkSecurityGroups/ACU1-BRW-AOA-T5-nsgSNWAF01/securityRules/WAF_Default_Inbound",
"etag": "W/\"b46e1101-726c-4c32-88f1-7d0133edecdf\"",
"type": "Microsoft.Network/networkSecurityGroups/securityRules",
"properties": {
"provisioningState": "Succeeded",
"protocol": "Tcp",
"sourcePortRange": "*",
"destinationPortRange": "65200-65535",
"sourceAddressPrefix": "GatewayManager",
"destinationAddressPrefix": "*",
"access": "Allow",
"priority": 1000,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [],
"sourceAddressPrefixes": [],
"destinationAddressPrefixes": []
}
},
{
"name": "WAF_Web_Inbound",
"id": "/subscriptions/b8f402aa-20f7-4888-b45c-3cf086dad9c3/resourceGroups/ACU1-BRW-AOA-RG-T5/providers/Microsoft.Network/networkSecurityGroups/ACU1-BRW-AOA-T5-nsgSNWAF01/securityRules/WAF_Web_Inbound",
"etag": "W/\"b46e1101-726c-4c32-88f1-7d0133edecdf\"",
"type": "Microsoft.Network/networkSecurityGroups/securityRules",
"properties": {
"provisioningState": "Succeeded",
"protocol": "Tcp",
"sourcePortRange": "*",
"sourceAddressPrefix": "Internet",
"destinationAddressPrefix": "VirtualNetwork",
"access": "Allow",
"priority": 1010,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [
"80",
"443"
],
"sourceAddressPrefixes": [],
"destinationAddressPrefixes": []
}
}
]So if you use that property I am not sure where the e.g. {
"name": "DenyAllInBound",
"id": "/subscriptions/b8f402aa-20f7-4888-b45c-3cf086dad9c3/resourceGroups/ACU1-BRW-AOA-RG-T5/providers/Microsoft.Network/networkSecurityGroups/ACU1-BRW-AOA-T5-nsgSNWAF01/defaultSecurityRules/DenyAllInBound",
"etag": "W/\"b46e1101-726c-4c32-88f1-7d0133edecdf\"",
"type": "Microsoft.Network/networkSecurityGroups/defaultSecurityRules",
"properties": {
"provisioningState": "Succeeded",
"description": "Deny all inbound traffic",
"protocol": "*",
"sourcePortRange": "*",
"destinationPortRange": "*",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*",
"access": "Deny",
"priority": 65500,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [],
"sourceAddressPrefixes": [],
"destinationAddressPrefixes": []
}
} |
Beta Was this translation helpful? Give feedback.
-
|
was there an actual way around this? trying to get to the bottom of this? we may have things added manually and each time it removes those extra rules. Any ideas? |
Beta Was this translation helpful? Give feedback.
-
|
The answer was to read the current rules with and That is if you cannot log down your environment from having manual settings changed. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to dig this up again.. I've tried this and it seems to have issue when doing the union, I've got inbound/outbound rules that I'm trying to union with the current rules, but it appears the current rules have a few extra values causing the union to not work correctly. my scenario is, platform team is deploying the bicep ALZ, workload teams have permission to create nsg rules (but not the NSG) when the spoke networking pipeline is run, it does not retain the current workload team implemented nsg rules. forcing them to run their pipelines to resolve the nsg's being removed as they are not in the lz param file the platform team are deploying. Here are some details if you can point me in the right direction that would be amazing @brwilkinson code: output of 'securityRulesAllFirstUnion': output of 'uniqueSecurityRuleNames': |
Beta Was this translation helpful? Give feedback.
there is really no simple solution here, the best thing to do is to lock down any manual changes from the NSG's and only do configuration as code deployments.
In saying that, there is a complicated workaround. I would even say, that i recommend the method above as a preference to this method, based on it's complexity.
Here is a template that deploys a website.
https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/AppServiceWebSite.bicep
part of it uses the following
existingresource reference... which is later used to list app config settings.