hally9k
hally9k

Reputation: 2583

ARM templates regenerate keys if an existing key is not referenced in the template

I find this a little bit counter intuitive and stumbled on this quite badly recently.

If you define your infrastructure in an ARM template and add a Shared Access Key into the template it will create all your infra with the desired key. But then some part of that template gets updated later and the template is run against your infra again. Now that Shared Access Key part of the definition will regenerate your keys because it doesn't directly reference an existing key in the template.

Essentially this means that our Create template is different from our Update template, which feels a bit icky.

The only way to do this currently is with self managed keys in vault or similar. Unfortunately for the resource I'm working with this is only available in some regions: https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-customer-managed-keys

I would prefer to be able to mark the key as immutable so that it will be created but never regenerated on subsequent updates. This means that we don't have to maintain 2 templates for the same infra.

Am I missing something fundamental here or is there a better way to handle this that I'm not seeing?

EDIT:
Here is a sample of the template for clarity:

{
  "type": "Microsoft.Devices/IotHubs",
  "apiVersion": "2018-04-01",
  "name": "[variables('iotHubName')]",
  "location": "[parameters('location')]",
  "dependsOn": [
    "[variables('telemetryEventHubName')]"
  ],
  "properties": {
    "authorizationPolicies": [
      {
        "keyName": "[variables('mobileDeviceAccessPolicyName')]",
        "rights": "deviceconnect, serviceconnect, registryread, registrywrite"
      }
    ]
  },
  "sku": {
    "name": "[parameters('iotHubSkuName')]",
    "capacity": "[parameters('iotHubCapacityUnits')]"
  }
}

Upvotes: 0

Views: 236

Answers (1)

ashita
ashita

Reputation: 56

This behavior is by design. If the ARM template does not explicitly specify “PrimaryKey”: “….” Or “SecondaryKey”: “..” then we will regenerate the keys. We understand your need to not regenerate the key and locking it down. We have added this new ask in our work backlog and will investigate designing this.

Upvotes: 4

Related Questions