Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Azure Disk Encryption with VM Extensions vs. Using Managed Disks #5102

Closed
rapster83 opened this issue Dec 6, 2019 · 5 comments
Closed

Azure Disk Encryption with VM Extensions vs. Using Managed Disks #5102

rapster83 opened this issue Dec 6, 2019 · 5 comments

Comments

@rapster83
Copy link

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!

@rapster83
Copy link
Author

@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_disk should not do a replacement as I did not configure the encryption_settings for managed disk, as the code above shows. Is there a workaround? Thx.

@ArcturusZhang
Copy link
Contributor

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.

@rapster83
Copy link
Author

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! 👍

@tombuildsstuff
Copy link
Contributor

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!

@ghost
Copy link

ghost commented Jul 25, 2020

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!

@ghost ghost locked and limited conversation to collaborators Jul 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants