`azurerm_mssql_server_transparent_data_encryption: support for Key Vault Keys from a Managed HSM

[baaym]

Is there an existing issue for this?

• I have searched the existing issues

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 and review the contribution guide to help.

Terraform Version

1.5.5

AzureRM Provider Version

3.69.0

Affected Resource(s)/Data Source(s)

azurerm_mssql_server_transparent_data_encryption

Terraform Configuration Files

resource "azurerm_mssql_server" "sql-server" {
  name                          = "sql-server"
  resource_group_name           = "resource-group"
  location                      = "location"
  version                       = "12.0"
  connection_policy             = "Proxy"
  administrator_login           = "a_username"
  administrator_login_password  = "a_password"

  identity {
    type = "SystemAssigned"
  }
}

# Depends on an existing HSM
resource "azurerm_mssql_server_transparent_data_encryption" "sql-server-key" {
  server_id        = azurerm_mssql_server.sql-server.id
  key_vault_key_id = "https://XXX.managedhsm.azure.net/keys/KEY_NAME/KEY_VERSION"
}

Debug Output/Panic Output

Error: parsing "https://XXX.managedhsm.azure.net/keys/KEY_NAME/KEY_VERSION": internal-error: Managed HSM IDs are not supported as Key Vault Nested Items

Expected Behaviour

With AzureRM version 3.38.0 this works fine, and our SQL Server uses a HSM key for TDE. It should still be possible to set a HSM key as the TDE key on Azure MSSql.

Actual Behaviour

Terraform throws an error:

Error: parsing "https://XXX.managedhsm.azure.net/keys/KEY_NAME/KEY_VERSION": internal-error: Managed HSM IDs are not supported as Key Vault Nested Items

Steps to Reproduce

1. terraform plan

Important Factoids

No response

References

I traced back the change to Pull Request #22162, where nested_item.go now explicitly checks for the presence of .managedhsm. in the key ID. When the related parse function is called from mssql_server_transparent_data_encryption_resource.go, it trips over the presence of .managedhsm. and throws the error mentioned above.

Direct link to the diff: https://github.com/hashicorp/terraform-provider-azurerm/pull/22162/files#diff-47ee3cc88d70fdbce65e1d87a4f46810d37aab7ed4a292f2224273c9cd7b6d8d

[tombuildsstuff]

hey @baaym

Unfortunately despite some documentation to the contrary, there's already behavioural differences between a Key Vault Key and a Key backed by a Managed HSM - and unfortunately at this point in time Keys backed by a Managed HSM aren't supported in all cases.

Whilst this may have worked in some places in previous versions of the Provider, unfortunately that was unintentional and so the PR #22162 has fixed this validation issue such that we clarify this isn't supported at this time. That said, I can see the requirement for this - and from our side we'd look to add support for this via a separate field, managed_hsm_key_id - to allow for the difference in behaviours to be handled as needed.

Unfortunately the domain suffix (managedhsm.azure.net [in Azure Public]) isn't a sufficient differentiator to detect that this is a Managed HSM in all cases, whilst this is the case today - taking Storage Accounts as an example there are different (as well as regional) endpoints available.

As such, I'm going to label this an enhancement rather than a bug, since whilst I appreciate this is a regression in your case - given the subtle nuances between a Key Vault Key and a Managed HSM Key, we want to ensure that we're exposing this in a means where we can provide validation to account for this.

Thanks!

[gautetk]

FYI:
This issue also seems to occur when trying to use managed HSM customer managed key on a storage account or for an encryption scope.

[katbyte]

fixed by #26496

[github-actions]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.