Terraform-provider-azurerm: Azure Disk Encryption with VM Extensions vs. Using Managed Disks

Created on 6 Dec 2019  ยท  5Comments  ยท  Source: terraform-providers/terraform-provider-azurerm

Community Note

  • Please vote on this issue by adding a ๐Ÿ‘ reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.12.7
+ provider.azurerm v1.33.1

Affected Resource(s)

  • azurerm_managed_disk
  • azurerm_virtual_machine_extension

Terraform Configuration Files

I created several VMs with managed (data) disks a few month ago according to the following resource :

resource "azurerm_managed_disk" "md" {
    count                   = "${var.md_count}"
    name                    = "${var.md_name}-disk${count.index}"
    location                = "${var.md_location}"
    resource_group_name     = "${var.md_rg_name}"
    storage_account_type    = "${var.md_storage_account_type}"
    create_option           = "${var.md_create_option}"
    source_uri              = "${var.md_create_option == "Import" ? var.md_source_uri : null}"
    source_resource_id      = "${var.md_create_option == "Copy" || var.md_create_option == "Restore" ? var.md_source_resource_id : null}"
    image_reference_id      = "${var.md_create_option == "FromImage" ? var.md_image_reference_id : null}"
    os_type                 = "${var.md_create_option == "Copy" || var.md_create_option == "Import" ? var.md_os_type : null}"
    disk_size_gb            = "${var.md_disk_size_gb != "" ? var.md_disk_size_gb : null}"
    tags                    = "${merge(local.default_tags, var.md_tags)}"
}

I configured all VMs already (Software, Services, etc) and now the customer has the requirement to encrypt the disks using BitLocker. So I created the following resource to encrypt 'All' disk of a VM, and it worked fine so far:

resource "azurerm_virtual_machine_extension" "vm_encry_win" {
  count                         = "${var.vm_encry_os_type == "Windows" ? 1 : 0}"
  name                          = "${var.vm_encry_name}"
  location                      = "${var.vm_encry_location}"
  resource_group_name           = "${var.vm_encry_rg_name}"
  virtual_machine_name          = "${var.vm_encry_vm_name}"
  publisher                     = "${var.vm_encry_publisher}"
  type                          = "${var.vm_encry_type}"
  type_handler_version          = "${var.vm_encry_type_handler_version == "" ? "2.2" : var.vm_encry_type_handler_version}"
  auto_upgrade_minor_version    = "${var.vm_encry_auto_upgrade_minor_version}"
  tags                          = "${var.vm_encry_tags}"

  settings = <<SETTINGS
                {
                    "EncryptionOperation":      "${var.vm_encry_operation}",
                    "KeyVaultURL":              "${var.vm_encry_kv_vault_uri}",
                    "KeyVaultResourceId":       "${var.vm_encry_kv_vault_id}",
                    "KeyEncryptionKeyURL":      "${var.vm_encry_kv_key_url}",
                    "KekVaultResourceId":       "${var.vm_encry_kv_vault_id}",
                    "KeyEncryptionAlgorithm":   "${var.vm_encry_key_algorithm}",
                    "VolumeType":               "${var.vm_encry_volume_type}"
                }
             SETTINGS
}

Debug Output

Panic Output

Expected Behavior

The disks are encrypted and a re-run of terraform plan or terraform apply does NOT cause any changes.

Actual Behavior

I have now a bigger issue regrading the encryption of managed Disks. When I re-run terraform using terraform plan or terraform apply, it wants to replace all my data disks I have already created, like the following screenshot illustrates.

2019-12-06 19_48_58-Window

I know that the problem is the encryption_settings section of the managed disk setting, but I do not know how to solve it. And my already created disks should not be replaces.

Does anyone has an idea? Appreciate it!

question servicvirtual-machine-extensions

Most helpful comment

Hi @ArcturusZhang,
thanks for your reply.
The problem is solved. I found the following solution on #486
The following code works fine:

lifecycle {
        ignore_changes = [encryption_settings]
    }

Thx! ๐Ÿ‘

All 5 comments

@tombuildsstuff : Any idea why the encryption_settings of the managed disk force a replacement, if I use the azurerm_virtual_machine_extension with Microsoft.Azure.Security? Normally the azurerm_managed_diskshould not do a replacement as I did not configure the encryption_settingsfor managed disk, as the code above shows. Is there a workaround? Thx.

By the definition of go sdk, the encryption setting enable of managed disks should be updatable (code). But I found a comment in the terraform code here:

// Azure can change enabled from false to true, but not the other way around, so
//   to keep idempotency, we'll conservatively set this to ForceNew=true

Therefore I suppose that this ForceNew is only a temporary workaround to solve some other issues here.
Could the ignore_changes attribute work? You can find description of this here. Maybe you can use this attribute to tell terraform to ignore the diff on encryption_settings, if this works, terraform will not try to replace the disk.

Hi @ArcturusZhang,
thanks for your reply.
The problem is solved. I found the following solution on #486
The following code works fine:

lifecycle {
        ignore_changes = [encryption_settings]
    }

Thx! ๐Ÿ‘

hey @stefan-rapp

Glad to hear this is now working for you - since this is working as intended (as Terraform should detect these changes not present in the config) - I'm going to close this issue for the moment.

Thanks!

I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error ๐Ÿค– ๐Ÿ™‰ , please reach out to my human friends ๐Ÿ‘‰ [email protected]. Thanks!

Was this page helpful?
0 / 5 - 0 ratings