terraform-provider-azurerm: Front Door: Upgrade 2.57 -> 2.58 breaks on existing FD instances with inline HTTPS configuration

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

AzureRM: 2.57 & 2.58 Terraform: 0.14.11

Affected Resource(s)

  • azurerm_frontdoor
  • azurerm_frontdoor_custom_https_configuration

Terraform Configuration Files

For 2.57

resource "azurerm_frontdoor" "fd" {
  name                                         = "sample-frontdoor-brc"
  resource_group_name                          = azurerm_resource_group.rg.name
  enforce_backend_pools_certificate_name_check = true
  tags = {
    "Version" = "4.0.2"
  }

  backend_pool {
    health_probe_name   = "health-probe"
    load_balancing_name = "backend-lb"
    name                = "backend"
    backend {
      address     = "www.bing.com"
      host_header = "www.bing.com"
      http_port   = 80
      https_port  = 443
    }
  }

  backend_pool_load_balancing {
    name = "backend-lb"
  }

  backend_pool_health_probe {
    <snipped for brevity>
  }

  frontend_endpoint {
    name      = "default"
    host_name = "sample-frontdoor-brc.azurefd.net"
  }

  frontend_endpoint {
    name      = "custom"
    host_name = "sample-frontdoor-brc.sandbox.provider.engineering"

    custom_https_provisioning_enabled = true
    custom_https_configuration {
      certificate_source = "FrontDoor"
    }
  }

  routing_rule {
     <snipped for brevity>
  }
}

For 2.58

resource "azurerm_frontdoor" "fd" {
  name                                         = "sample-frontdoor-brc"
  resource_group_name                          = azurerm_resource_group.rg.name
  enforce_backend_pools_certificate_name_check = true
  tags = {
    "Version" = "4.0.2"
  }

  backend_pool {
    <snipped for brevity>
  }

  backend_pool_load_balancing {
    name = "backend-lb"
  }

  backend_pool_health_probe {
    <snipped for brevity>
  }

  frontend_endpoint {
    name      = "default"
    host_name = "sample-frontdoor-brc.azurefd.net"
  }

  frontend_endpoint {
    name      = "custom"
    host_name = "sample-frontdoor-brc.sandbox.provider.engineering"
  }

  routing_rule {
     <snipped for brevity>
  }
}

resource "azurerm_frontdoor_custom_https_configuration" "fd_custom_url" {
  frontend_endpoint_id              = azurerm_frontdoor.fd.frontend_endpoint[1].id
  custom_https_provisioning_enabled = true

  custom_https_configuration {
    certificate_source = "FrontDoor"
  }
}

Debug Output

Post a comment below if it is needed. I have to make sure that the debug output does not contain any sensitive info before I put it here in the issue or in a paste bin.

Panic Output

N/A

Expected Behaviour

Unsure really. Are we supposed to delete the Front Door first before going from 2.57 to 2.58? Or is it supposed to just ignore the existing certificate on the Front Door.

Actual Behaviour

First error when running terraform apply:

azurerm_frontdoor.fd: Modifying... [id=/subscriptions/[redacted]/resourceGroups/frontdoor-issue-brc/providers/Microsoft.Network/frontDoors/sample-frontdoor-brc]
azurerm_frontdoor.fd: Modifications complete after 3s [id=/subscriptions/[redacted]/resourceGroups/frontdoor-issue-brc/providers/Microsoft.Network/frontDoors/sample-frontdoor-brc]
azurerm_frontdoor_custom_https_configuration.fd_custom_url: Creating...

Error: updating Custom HTTPS configuration for Frontend Endpoint "custom"
(Front Door "sample-frontdoor-brc" / Resource Group "frontdoor-issue-brc"): unable to enable/update Custom Domain HTTPS for Frontend Endpoint "custom" (Resource Group "frontdoor-issue-brc"): enabling Custom Domain HTTPS for Frontend Endpoint: frontdoor.FrontendEndpointsClient#EnableHTTPS: Failure sending request: StatusCode=0 -- Original Error: Code="BadRequest" Message="That action isn’t allowed in this profile."

Second error when running terraform apply:

azurerm_frontdoor_custom_https_configuration.fd_custom_url: Creating...

Error: updating Custom HTTPS configuration for Frontend Endpoint "custom" (Front Door "sample-frontdoor-brc" / Resource Group "frontdoor-issue-brc"): unable to enable/update Custom Domain HTTPS for Frontend Endpoint "custom"
(Resource Group "frontdoor-issue-brc"): enabling Custom Domain HTTPS for Frontend Endpoint:
frontdoor.FrontendEndpointsClient#EnableHTTPS: Failure sending request: StatusCode=0 -- Original Error:
Code="OperationNotAllowed" Message="Frontend endpoint custom is already secured with a managed certificate.
Only the Minimum TLS Version property for a managed certificate configuration can be updated. All other updates are not suppored."

Steps to Reproduce

  1. Pin your configuration to AzureRM 2.57 (or earlier)
  2. Create a Front Door resource using the custom HTTPS configuration inline resource
  3. terraform apply
  4. DO NOT DESTROY!
  5. Remove the pinned version so that AzureRM 2.58 can be downloaded
    1. You may have to run terraform init -upgrade because of the lock file
  6. Remove the inline configuration in azurerm_frontdoor.
  7. Add the custom HTTPS configuration through azurerm_frontdoor_custom_https_configuration
  8. terraform apply
  9. Change nothing and run terraform apply for the second error

Important Factoids

N/A

References

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 18 (5 by maintainers)

Commits related to this issue

Most upvoted comments

@timja @cpressland

Are you putting the literal string latest in or is that referring to a version? If you want the latest version you should not specify a version (leave out the attribute)

I am seeing this confusion creep in more and more… thinking about putting a check in the code if it sees latest just to ignore it and send an empty string instead or maybe a validation rule that would error out if the word latest was passed as the version field value. 🤔

+2
WodansSon on May 9, 2021

@bcline760, I have updated the azurerm_frontdoor_custom_https_configuration code to support state import:

> terraform import azurerm_frontdoor_custom_https_configuration.custom /subscriptions/XXXXX/resourceGroups/XXXXX-11623-frontdoor-repro/providers/Microsoft.Network/frontDoors/acctest-fd-001-test/customHttpsConfiguration/custom

azurerm_frontdoor_custom_https_configuration.custom: Importing from ID "/subscriptions/XXXXX/resourceGroups/XXXXX-11623-frontdoor-repro/providers/Microsoft.Network/frontDoors/acctest-fd-001-test/customHttpsConfiguration/custom"...
azurerm_frontdoor_custom_https_configuration.custom: Import prepared!
  Prepared azurerm_frontdoor_custom_https_configuration for import
azurerm_frontdoor_custom_https_configuration.custom: Refreshing state... [id=/subscriptions/XXXXX/resourceGroups/XXXXX-11623-frontdoor-repro/providers/Microsoft.Network/frontDoors/acctest-fd-001-test/customHttpsConfiguration/custom]

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

What this means is that once you upgrade your provider with an existing Frontdoor resource to v2.58.0 all you will need to do is to update your configuration file with the new azurerm_frontdoor_custom_https_configuration block stub and import it like this:

Stub example 
resource "azurerm_frontdoor_custom_https_configuration" "custom" {
}
Import command example 
terraform import azurerm_frontdoor_custom_https_configuration.custom /subscriptions/XXXXX/resourceGroups/XXXXX-11623-frontdoor-repro/providers/Microsoft.Network/frontDoors/acctest-fd-001-test/customHttpsConfiguration/custom

Once you do that, the azurerm_frontdoor_custom_https_configuration resource will be written into your state file. Now that it is imported the last step is to add the correct values to your stubs in your configuration file like this:

Update configuration stub values example 
resource "azurerm_frontdoor_custom_https_configuration" "custom" {
  frontend_endpoint_id              = "${azurerm_frontdoor.test.id}/frontendEndpoints/${local.custom_frontend_name}"
  custom_https_provisioning_enabled = true

  custom_https_configuration {
    certificate_source = "FrontDoor"
  }
}

Once you update your configuration file to include the correct values that exist in azure for your azurerm_frontdoor_custom_https_configuration resource all you need to do now is run terraform plan:

> terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

azurerm_resource_group.test: Refreshing state... [id=/subscriptions/XXXXX/resourceGroups/XXXXX-11623-frontdoor-repro]
azurerm_frontdoor.test: Refreshing state... [id=/subscriptions/XXXXX/resourceGroups/XXXXX-11623-frontdoor-repro/providers/Microsoft.Network/frontDoors/acctest-fd-001-test]
azurerm_frontdoor_custom_https_configuration.default: Refreshing state... [id=/subscriptions/XXXXX/resourceGroups/XXXXX-11623-frontdoor-repro/providers/Microsoft.Network/frontDoors/acctest-fd-001-test/customHttpsConfiguration/default]
azurerm_frontdoor_custom_https_configuration.custom: Refreshing state... [id=/subscriptions/XXXXX/resourceGroups/XXXXX-11623-frontdoor-repro/providers/Microsoft.Network/frontDoors/acctest-fd-001-test/customHttpsConfiguration/custom]

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.
+1
WodansSon on May 10, 2021

Right so appears to be a front door managed cert issue, if you’re providing your own cert it works

I am not sure that is a true statement, I can not test that scenario as I can not create my own cert. 😞

Well I’ve upgraded ~15 frontdoors with 100s of endpoints using my own cert with the above scenario and no issues.

for the record I used this when testing frontdoor to create my own certs that were valid: https://github.com/shibayan/keyvault-acmebot

You just need a sub-domain you own and then it’s trivial to setup more certs

+1
timja on May 10, 2021

Normally the issue would be pinned for a few weeks if there’s action for people to take.

but it only happens in some edge case, my setup appears to be the same as above and I didn’t need to do anything outside moving the resource from inline to separate resource

You did the exact setup I did and yours didn’t break at all? I’m curious as to why mine broke.

+1
bcline760 on May 8, 2021

Are you putting the literal string latest in or is that referring to a version? If you want the latest version you should not specify a version (leave out the attribute)

+1
timja on May 8, 2021

So far, I’ve had mixed success with this version, we’ve not been able to configure Front Door in Terraform for nearly a year now, so its had lots of Azure Portal modifications. On the plus side, Terraform can now manage the Front Door object itself just fine, but custom HTTPS resources are completely broken for us.

We began with a front door sub resource as follows:

     frontend_endpoint {
         name = "api-staging-gb-bink-com"
         host_name = "api.staging.gb.bink.com"
         custom_https_provisioning_enabled = true
         custom_https_configuration {
             certificate_source = "AzureKeyVault"
             azure_key_vault_certificate_vault_id = azurerm_key_vault.frontdoor.id
             azure_key_vault_certificate_secret_name = "gb-bink-com"
             azure_key_vault_certificate_secret_version = "latest"
         }
         web_application_firewall_policy_link_id = azurerm_frontdoor_firewall_policy.policy.id
     }

this was modified to:

     frontend_endpoint {
         name = "api-staging-gb-bink-com"
         host_name = "api.staging.gb.bink.com"
         web_application_firewall_policy_link_id = azurerm_frontdoor_firewall_policy.policy.id
     }

and then an additional resource added:

resource "azurerm_frontdoor_custom_https_configuration" "api_staging_gb_bink_com" {
    frontend_endpoint_id = azurerm_frontdoor.frontdoor.frontend_endpoints["api-staging-gb-bink-com"]
    custom_https_provisioning_enabled = true

    custom_https_configuration {
        certificate_source = "AzureKeyVault"
        azure_key_vault_certificate_vault_id = azurerm_key_vault.frontdoor.id
        azure_key_vault_certificate_secret_name = "gb-bink-com"
        azure_key_vault_certificate_secret_version = "latest"
    }
}

On the initial Terraform apply the Front Door object itself was modified and all Custom HTTPS Certificates were deprovisioned as expected. However, when attempting to add the new resource type we get the following error:

Error: updating Custom HTTPS configuration for Frontend Endpoint "api-staging-gb-bink-com" (Front Door "bink-frontdoor" / Resource Group "frontdoor"): unable to enable/update Custom Domain HTTPS for Frontend Endpoint "api-staging-gb-bink-com" (Resource Group "frontdoor"): waiting to enable Custom Domain HTTPS for Frontend Endpoint: Code="None" Message=""

The above led me here, and I attempted to remove all associated records completely as per the recommendations in “The Hard Way” from @WodansSon - unfortunately after completing this we still had the same error:

Error: updating Custom HTTPS configuration for Frontend Endpoint "api-staging-gb-bink-com" (Front Door "bink-frontdoor" / Resource Group "frontdoor"): unable to enable/update Custom Domain HTTPS for Frontend Endpoint "api-staging-gb-bink-com" (Resource Group "frontdoor"): waiting to enable Custom Domain HTTPS for Frontend Endpoint: Code="None" Message=""

Checking the JSON payload in resources.azure.com showed that above resource didn’t change all that much between applies, obviously it disappeared, but when it came back it was identical beyond a slight ordering difference.

I then attempted to create this resource with:

    custom_https_configuration {
        certificate_source = "FrontDoor"
    }

Which worked! As such, I still think we have an issue here when using Azure Key Vault with a azurerm_frontdoor_custom_https_configuration resource. Any suggestions on this @WodansSon?

+1
cpressland on May 8, 2021

Delete your custom HTTPS endpoint and your inline custom HTTPS configuration settings from your configuration file. Terraform apply, this will remove the custom HTTPS settings and reference and avoid the errors after upgrading. Upgrade to v2.58.0 of the Terraform provider Manually migrate your custom HTTPS settings to the dedicated azurerm_frontdoor_custom_https_configuration resource and add your custom HTTPS endpoint back into your configuration file. Terraform apply

I didn’t have to do anything migrating have an azurerm_frontdoor (from 2.41.0) with inline custom_https_configuration to the separate resource, the first apply just worked

+1
timja on May 7, 2021
Read more comments on GitHub
← terraform-provider-azurerm: Failed to destroy azurerm_key_vault and associated azurerm_key_vault_access_policy (30 minute timeout)
terraform-provider-azurerm: function_app_resource can't deploy a function app with a backing storage account protected via private endpoint →