Data source for azurerm_cdn_frontdoor_secret errors on plan since version 3.59.0

[DexterWatson]

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

Terraform Version

1.4.6

AzureRM Provider Version

= 3.59.0

Affected Resource(s)/Data Source(s)

azurerm_cdn_frontdoor_secret

Terraform Configuration Files

data "azurerm_cdn_frontdoor_secret" "cert" {
  name                = var.cert
  profile_name        = var.cdn_frontdoor_profile_name
  resource_group_name = data.azurerm_resource_group.rg.name
}

Debug Output/Panic Output

│ Error: setting 'secret': Invalid address to set: []string{"secret", "0", "expiration_date"}

Expected Behaviour

Plan generated successfully.

Actual Behaviour

Error is thrown for each azurerm_cdn_frontdoor_secret data source.

Steps to Reproduce

1. Use the azurerm provider version 3.59.0 or 3.60.0.
2. Run a plan with a azurerm_cdn_frontdoor_secret data source block.

Important Factoids

No response

References

No response

[rcskosir]

@DexterWatson Thank you for opening this issue. I was unable to reproduce this error in v3.59.0 nor v3.61.0 with the given configuration. Are you able to provide more of your configuration so that I may be able to reproduce the issue?

[DexterWatson]

Hey @rcskosir!

Apologies for the late response, I can't send the actual values we are using, but I have extracted the problem code into a small module to simulate the issue. Please see below.

modules/my_module/main.tf

data "azurerm_cdn_frontdoor_secret" "cert" {
  name                = var.cert_name
  profile_name        = var.profile_name
  resource_group_name = var.resource_group_name
}

modules/my_module/variables.tf

variable "resource_group_name" {
  description = "The name of the Azure Resource Group."
  type        = string
}

variable "cert_name" {
  description = "The name of the CDN Front Door secret."
  type        = string
}

variable "profile_name" {
  description = "The name of the CDN Front Door profile."
  type        = string
}

terraform/main.tf

module "my_module" {
  source              = "../modules/my_module"
  resource_group_name = "my-resource-group"
  cert_name           = "my-certificate"
  profile_name        = "my-frontdoor-profile"
}

terraform/providers.tf

provider "azurerm" {
  features {}
  auxiliary_tenant_ids = [var.auxiliary_tenant_id]
  client_id            = var.client_id
  client_secret        = var.client_secret
  subscription_id      = var.subscription_id
  tenant_id            = var.tenant_id
}

I have tested it with just this code, and still get the issue.

│ Error: setting 'secret': Invalid address to set: []string{"secret", "0", "expiration_date"}
│
│ with module.my_module.data.azurerm_cdn_frontdoor_secret.cert,
│ on ..\modules\my_module\main.tf line 1, in data "azurerm_cdn_frontdoor_secret" "cert":
│ 1: data "azurerm_cdn_frontdoor_secret" "cert" {
│

We are using the latest azurerm provider, 3.61.0.

I have tested this on various versions of terraform, including v1.3.5, v1.4.6 and v1.5.0.

If I update terraform/providers.tf and pin the version of azurerm to 3.57.0 the issue no longer occurs and a plan can successfully be generated.

I hope this is enough information to go off.

Kind regards,
Dexter

[ollie-bruce-allica]

Hi @WodansSon,

have you been able to replicate the issue we are seeing in this ticket?

Kind regards
Ollie

[bkasperowicz]

I have a simmilar issue after updating azurerm provider to version 3.59.0.
I needed azurerm_cdn_frontdoor_secret data source to obtain cdn_frontdoor_secret_id to create FrontDoor custom domain.

As a workaround I just created frontdoor secret by concatenation:

locals {
  frontdoor_resource_group_name = "your-frontdoor-rg"
  frontdoor_profile_name = "your-frontdoor-profile"
  frontdoor_secret_name= "your-frontdoor-secret"
}

data "azurerm_subscription" "current" {
}

resource "azurerm_cdn_frontdoor_custom_domain" "fd_custom_domain" {
  ...
  tls {
    certificate_type    = "CustomerCertificate"
    minimum_tls_version = "TLS12"
    # a workaround for https://github.com/hashicorp/terraform-provider-azurerm/issues/22124
    cdn_frontdoor_secret_id = "/subscriptions/${data.azurerm_subscription.current.subscription_id}/resourcegroups/${local.frontdoor_resource_group_name}/providers/Microsoft.Cdn/profiles/${local.frontdoor_profile_name}/secrets/${local.frontdoor_secret_name}"
  }
}

If you don't want to do the concatenation or you need some other attributes, you can use the Azure REST API and wrap it into your own module:
https://learn.microsoft.com/en-us/rest/api/frontdoor/azurefrontdoorstandardpremium/secrets/get

[ollie-bruce-allica]

Any updates @WodansSon on this issue we are still experiencing this issue and look for a fix rather than a workaround?

[Pawel22729]

I've just hit this exact issue using data azurerm_cdn_frontdoor_secret - jut raising hand that interest is still there

[Basel78]

I'm facing same issue while trying to retrieve secret Id from existing AFD to pass it to new custom domain, using data block,, passed all information mentioned in TF documentation below but getting same error
Error: setting 'secret': Invalid address to set: []string{"secret", "0", "expiration_date"}

data "azurerm_cdn_frontdoor_secret" "example" {
name = "example-secret"
profile_name = "example-profile"
resource_group_name = "example-resources"
}

[coopereric]

Seeing the same error using this data call - @WodansSon is there any update on a fix?

[MarcDenman]

This looks to have been resolved by #26982 as part of #24731 and released in 3.116.0.

[rcskosir]

Thanks for taking the time to submit this issue. It looks like this has been resolved as of #26982. As such, I am going to mark this issue as closed. If that is not the case, please provide additional information including the version in which you are still experiencing this issue, thanks!