0

Duplicate Question?

I don't believe it is. As stated, this is working using my user from a local deployment and all (as I understand it) permissions have been granted to the Service Principal and the test user that also fails locally.

I have an ARM template that provisions and deploys a web app, part of that is to apply a certificate binding to the webapp. That part of the template looks like this:

{
  "type": "Microsoft.Web/sites",
  "kind": "api",
  "name": "[parameters('name')]",
  "apiVersion": "2015-08-01",
  "location": "[resourceGroup().location]",
  "properties": {
    "name": "[parameters('name')]",
    "serverFarmId": "[resourceId(parameters('servicePlanGroup'), 'Microsoft.Web/serverFarms', parameters('servicePlanName'))]"
  },
  "resources": [
    {
      "name": "[parameters('certificateName')]",
      "apiVersion": "2014-04-01",
      "type": "Microsoft.Web/certificates",
      "location": "[resourceGroup().location]",
      "dependsOn": [
        "[resourceId('Microsoft.Web/Sites', parameters('name'))]"
      ],
      "properties": {
        "keyVaultId": "[parameters('keyVaultId')]",
        "keyVaultSecretName": "[parameters('keyVaultSecretName')]"
      }
    }
   ]
  }

When I run this locally from my PC it works fine, when I run it from the VSTS the deployment fails, and look like this:

enter image description here

Where the error is:

"operationName": {
    "localizedValue": "Microsoft.Web/certificates/write",
    "value": "Microsoft.Web/certificates/write"
},
"properties": {
    "statusCode": "Unauthorized",
    "statusMessage": "{\"error\":{\"code\":\"BadRequest\",\"message\":\"\"}}"
}

The SSL certificate and the KeyVault both have permissions added for the Service Principal that VSTS runs under for this release.

The Release Principal user has Read,List for keys and secrets in the KeyVault and is a Contributor in the subscription. My account which works locally is co-admin.

Any ideas on what permissions need to be added?

Update

I added another user testuser which has the same rights as the Service Principal and it now fails locally. I guess it will be some trial and error to add permissions and see what works.

Rich Randall
  • 1,972
  • 13
  • 17
click2install
  • 980
  • 9
  • 23
  • Possible duplicate of [Issue with KeyVault reference in ARM template](http://stackoverflow.com/questions/42134416/issue-with-keyvault-reference-in-arm-template) – Manfred Radlwimmer Feb 21 '17 at 10:31

1 Answers1

1

This is not a duplicate question - as mentioned it was pointing to strange permission issue across accounts, even though the permissions were set. It turns out that for some reason the co-admin will work despite the below issue - a potential bug in the ARM/permission infrastructure, maybe?

This works for co-admin user but not anyone else.

enter image description here

Whereas this works for a lesser privileged user/principal.

enter image description here

Note the schema version change. The original schema of 2014-04-01 doesn't actually include anything about Microsoft.Web/Certificates whereas the updated schema 2015-08-01 does include this information.

Local testing using the testuser with same privileges as the VSTS service principal is working fine with this change.

Side Note for anyone else trying to achieve SSL bindings:

The location of resources in my example is all the same. I suspect if the vault is in a different location, then its resource group may also need to be specified for this to work the same - I haven't tested that theory though.

click2install
  • 980
  • 9
  • 23