azure-pipelines-tasks: AzureRmWebAppDeployment fails due to missing permission to perform joinViaServiceEndpoint/action on subnet
Required Information
Entering this information will route you directly to the right team and expedite traction.
Question, Bug, or Feature?
Type: Bug
Enter Task Name: AzureRmWebAppDeploymentV4
list here (V# not needed):
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks
Environment
Private agent, current version, running on Windows 2019 VM in Azure
Issue Description
During deployment, the build prints a warning and fails: ##[warning]Failed to update App Service configuration details. Error: Error: Failed to update App service ‘web-…’ configuration. Error: The client ‘5ef…0af’ with object id ‘5ef…0af’ has permission to perform action ‘Microsoft.Web/sites/config/write’ on scope ‘/subscriptions/3fe…e61/resourceGroups/rg-…/providers/Microsoft.Web/sites/web-…/config/web’; however, it does not have permission to perform action ‘joinViaServiceEndpoint/action’ on the linked scope(s) ‘/subscriptions/3fe…e61/resourceGroups/rg-…/providers/Microsoft.Network/virtualNetworks/vnet-…/subnets/snet-…’ or the linked scope(s) are invalid. (CODE: 403)
yaml for step:
- task: AzureRmWebAppDeployment@4
inputs:
azureSubscription: $(Subscription)
ConnectionType: 'AzureRM'
appType: 'webApp'
WebAppName: $(AppServiceName)
package: '$(System.DefaultWorkingDirectory)/**/*.zip'
The DevOps service principal has contributor access to the resource group of the webapp.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 27 (6 by maintainers)
We are using the pipeline task AzureRmWebAppDeployment to deploy an app service via a self-hosted agent from Azure DevOps.
At the end of the AzureRmWebAppDeployment task (source) there is an attempt to to set the scmType to “VSTSRM” in case it is empty (source). This triggers the PUT request to /config/web that ultimately fails and produces the warning described above.
Our workaround was to set the scmType of the app service preemptively:
Afterwards, new deployments did not produce the warning anymore.