Azure-pipelines-tasks: AzureRmWebAppDeploymentV4 Invalid IpSecurityRestriction Error

[droessmj]

Required Information

Entering this information will route you directly to the right team and expedite traction.

Type: Bug
Enter Task Name: AzureRmWebAppDeploymentV4

Environment

• Server - Azure Pipelines or TFS on-premises?
  
  
  
  • If using Azure Pipelines, provide the account name, team project name, build definition name/build number: Azure Pipelines, Windows-2019 hosted agent
  
  

Issue Description

Warning message is displayed showing an inability to update App Service configuration. Existing configuration for the ipSecurityRestrictions section is as follows:

    "ipSecurityRestrictions": [
      {
        "ipAddress": "52.254.1.12/32",
        "action": "Allow",
        "tag": "Default",
        "priority": 65000
      }
    ],

The actual IP address has been modified but is a valid Azure IP denoted as a CIDR /32.

Error logs

2019-10-17T13:20:57.7144066Z ##[warning]Failed to update App Service configuration details. Error: Error: Failed to update App service 'RemovedAppServiceName' configuration. Error: BadRequest - IpSecurityRestriction.IpAddress is invalid. It must be in CIDR format. (CODE: 400)

[droessmj]

I've been able to recreate this bug in a non-corporate subscription and can therefore provide any additional information necessary to triage on your end.

It is also worth noting that this is recreated with no additional Configuration settings supplied in the App Service release task.

[droessmj]

I've been able to track the cause of the bug to this method updateScmTypeAndConfigurationDetails.

Manually tuning the scmType metadata on the resource to be something custom (e.g., "LemmeBe") shows that the issue no longer occurs.

At this point, my understanding is that root cause is here: https://github.com/microsoft/azure-pipelines-tasks/blob/dd3cc454ffa296ce8ebd13ac2a69bbc6707cc684/Tasks/AzureRmWebAppDeploymentV4/operations/AzureAppServiceUtility.ts#L23, and my guess would be because the underlying ARM provider is using an older API version (2016-08-01) which may be leading to a typing error during serialization and deserialization of the payload? Just a guess at this point.

[droessmj]

So there's definitely a difference between the formatting of this object between API version 2016-08-01 and 2018-02-01 (shocker).

I guess the only thing I can't figure out is why the resource cannot be appropriately modified using the 2016-08-01 API. I'm guessing this object within the config section isn't backward compatible?

object $a below is a 2016-08-01 while $b is a 2018-02-01 object

[wronda]

Is there a current workaround for this? And if not, is there a fix on the way?

[droessmj]

Internally, our workaround has been just to live with it for the time being.

[eaarora-ms]

@droessmj Please share pipeline logs with system.debug set as true. Meanwhile, I am trying to repro the issue.

[droessmj]

@eaaror Do you have an email I can PM you the logs? Or do you have a specific section you're interested in? I'm not looking to redact the entire log file before posting directly.

[eaarora-ms]

@droessmj You can mail us the logs at RM_Customer_Queries at microsoft dot com
Entire logs would be of more help.

[shunkino]

Hi, I'm also interested in this warning. I've repro the problem and found workaround.

Repro steps

This warning only occurs when "scmType" property is set to "none".

Executing "AzureRmWebAppDeploymentV4" task after changing the property to "none" like below reproduced the problem.

az resource update --ids  /subscriptions/[Sub-id]/resourceGroups/PaaSTest/providers/Microsoft.Web/sites/[Site-name]/config/web --set properties.scmType="none"

Workaround

As this routine will only be executed when "scmType" is defined as "none", workaround is to change the value to updated one. From the source code, the task updates "scmType" to "VSTSRM". Command below will do the trick.

az resource update --ids  /subscriptions/[Sub-id]/resourceGroups/PaaSTest/providers/Microsoft.Web/sites/[Site-name]/config/web --set properties.scmType="VSTSRM"

Cause

From the investigation by @droessmj, I found API versions used by "getConfiguration()" and "updateConfiguration()" are actually different.

https://github.com/microsoft/azure-pipelines-tasks/blob/8cf83d49f8c66c93a890d700095e56c9e88d472e/Tasks/Common/azure-arm-rest-v2/azure-arm-app-service.ts#L326

https://github.com/microsoft/azure-pipelines-tasks/blob/8cf83d49f8c66c93a890d700095e56c9e88d472e/Tasks/Common/azure-arm-rest-v2/azure-arm-app-service.ts#L350

So, what's happening here is that, agent first get the configurations using '2016-08-01' API and modifies it as scmType="VSTSRM" and then sends configurations using '2018-02-01' API. I assume some kind of compatibility issues happens here.

After changing "getConfiguration()" to use '2018-02-01' API in my self-hosted agent, the warning was eliminated. This also suggest API version is involved in this problem.

I'm not familiar with this project and not sure why API versions are different in those functions. But I hope this helps the further investigation.

[eaarora-ms]

@shunkino @droessmj Thankyou for all your help. We checked that the recent API changes have some back-compatibility problems due to which these issues are arising. It's good to know that it is not a blocker. I have raised a PR and the bug should be fixed by the end of next week.

[shunkino]

@eaarora-ms
Thank you for submitting the PR. It seems like the PR is still under the review.
This isn't an urgent issue, but hope the fix will be merged soon :)

[eaarora-ms]

@shunkino Hi, the PR is under review because the changes might cause some back-compatibility issues. Hence, we are finding a best way to make the changes. The changes will be merged soon and I will update you with an ETA soon. Thanks for the patience.

[robs]

Thanks for fixing this one.
Do we need to do anything to get the fix once it's available?
Anything like remove and re-add the task or is it something that will just update automatically?

[eaarora-ms]

@robs Nothing is required from your side, the fix will work on it's own once it is deployed. Thanks for the patience :)

[bel-from-nz]

@eaarora-ms I am seeing this same error on the AzureFunctionAppV1. Has anyone reported this as an error yet?

[eaarora-ms]

@bel-from-nz Hi, yes the fix will also be applicable for all the tasks. 
The deployment is still under progress. Please wait until the end of next week, Thankyou for your patience. 

[bel-from-nz]

@eaarora-ms Great. Thanks so much.

[Kenneth-Abrams]

@eaarora-ms have you deployed the fix yet? I am seeing the same error described when deploying to premium function apps from Azure Devops, app service deploy task.

[warning]Failed to update App Service configuration details. Error: Error: Failed to update App service 'XYZ' configuration. Error: BadRequest - IpSecurityRestriction.IpAddress is invalid. It must be in CIDR format. (CODE: 400)

[eaarora-ms]

@Kenneth-Abrams The fix was deployed last week but has not reached all the regions yet. Please wait until the end of this week. Thank you for your patience.

[Kenneth-Abrams]

@eaarora-ms thanks for the amazingly prompt response! I'll keep waiting!

[eaarora-ms]

@Kenneth-Abrams The fix should be available by now.

[robs]

This was definitely fixed on the agent our last release used on 2020-02-11.

[zeeshan-aym]

@eaarora-ms is the fix in place because we are seeing the same error in our app services which are restricted through VNET/SN.
IpSecurityRestriction is invalid. Etiher IpAddress or VnetSubnetResourceId property must be specified.