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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Application Gateway still not working with versionless key vault secretId #16816

Open
1 task done
lotaezhao opened this issue May 17, 2022 · 7 comments
Open
1 task done

Comments

@lotaezhao
Copy link

lotaezhao commented May 17, 2022

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.1.7

AzureRM Provider Version

3.5.0

Affected Resource(s)/Data Source(s)

azurerm_application_gateway

Terraform Configuration Files

data "azurerm_key_vault_secret" "certificate_secret" {
  name         = var.custom_domains.certificate_name
  key_vault_id = var.custom_domains.keyvault_id
}

resource "azurerm_application_gateway" "network" {
  name                = "example-appgateway"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location

  ssl_certificate {
    name                = "sslcertificate"
    key_vault_secret_id = trimsuffix(data.azurerm_key_vault_secret.certificate_secret.id, "/${data.azurerm_key_vault_secret.certificate_secret.version}")
  }
}

Debug Output/Panic Output

N/A

Expected Behaviour

The versionless keyvault certificate should be added to the application gateway as support for this is supposed to have been added in: #7095.
If I add the ssl certificate with a versioned secret id it works but if I use the same config with the versionless id (by trimming the version suffix from the secret id) I receive a 'SecretIdSpecifiedIsInvalid' error as below.

I know secret id is valid because if I add the ssl certificate using the same versionless id as terraform via Az CLI it works. I think this proves that the functionality is broken in the provider.

Actual Behaviour

'SecretIdSpecifiedIsInvalid' error is returned:

Error: updating Application Gateway: (Name "my-appgw" / Resource Group "rg-my-app"): network.ApplicationGatewaysClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="SecretIdSpecifiedIsInvalid" Message="SecretId 'https://my-app-kv-secrets.vault.azure.net/certificates/wildcard-myapp-com' specified in '/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-my-app/providers/Microsoft.Network/applicationGateways/my-appgw/sslCertificates/wildcard-myapp-com' is invalid." Details=[]

Steps to Reproduce

Deploy an application gateway configured with a versionless ssl certificate keyvault secret id.

Important Factoids

No response

References

This was supposedly fixed under the following issues but still appears to be broken:
#6188
#7095

@lotaezhao lotaezhao added the bug label May 17, 2022
@github-actions github-actions bot removed the bug label May 17, 2022
@lotaezhao
Copy link
Author

lotaezhao commented May 17, 2022

OK I've resolved this, it's not the provider. It was actually a subtle issue with the certificate secret id returned from azurerm_key_vault_secret. The value that is needed is 'secret_id' not 'id'. Also found that data source for azurerm_key_vault_secret actually exports 'versionless_secret_id' directly so specifying the versionless secret id is even easier.

id - The Key Vault Certificate ID.
secret_id - The ID of the associated Key Vault Secret.
versionless_secret_id - The Base ID of the Key Vault Secret.

ssl_certificate {
    name                = "sslcertificate"
    key_vault_secret_id = data.azurerm_key_vault_secret.certificate_secret.versionless_secret_id
}

It is not easy to spot as the keyvault certificate id value is almost identical to the secret_id:

id                    = 'https://my-app-kv-secrets.vault.azure.net/certificates/wildcard-myapp-com/xxxxxxx'
secret_id             = 'https://my-app-kv-secrets.vault.azure.net/secrets/wildcard-myapp-com/xxxxxxx'
versionless_secret_id = 'https://my-app-kv-secrets.vault.azure.net/secrets/wildcard-myapp-com'

Application gateway requires the secret_id value which is different to the keyvault certificate id.

I'd suggest the azurerm_application_gateway documentation should be updated with a note about how to use the versionless secret id given that certificate rotation in an important issue.

@kitarp29
Copy link

@aristosvo @lotaezhao I would like to work on it

@JustinGalbraith
Copy link

OK I've resolved this, it's not the provider. It was actually a subtle issue with the certificate secret id returned from azurerm_key_vault_secret. The value that is needed is 'secret_id' not 'id'. Also found that data source for azurerm_key_vault_secret actually exports 'versionless_secret_id' directly so specifying the versionless secret id is even easier.

id - The Key Vault Certificate ID. secret_id - The ID of the associated Key Vault Secret. versionless_secret_id - The Base ID of the Key Vault Secret.

ssl_certificate {
    name                = "sslcertificate"
    key_vault_secret_id = data.azurerm_key_vault_secret.certificate_secret.versionless_secret_id
}

It is not easy to spot as the keyvault certificate id value is almost identical to the secret_id:

id                    = 'https://my-app-kv-secrets.vault.azure.net/certificates/wildcard-myapp-com/xxxxxxx'
secret_id             = 'https://my-app-kv-secrets.vault.azure.net/secrets/wildcard-myapp-com/xxxxxxx'
versionless_secret_id = 'https://my-app-kv-secrets.vault.azure.net/secrets/wildcard-myapp-com'

Application gateway requires the secret_id value which is different to the keyvault certificate id.

I'd suggest the azurerm_application_gateway documentation should be updated with a note about how to use the versionless secret id given that certificate rotation in an important issue.

I've been struggling with this for over a week. Your post just solved my problem with broken certificate rotations.

It should also be mentioned that versionless_secret_id != versionless_id

Instead of updating the documentation, I'd suggest that the ssl_certificate block in azurerm_application_gateway should be update to replace key_vault_secret_id with versionless_secret_id.

@sdubey-optum
Copy link

Indeed, unless versionless_secret_id is allowed. You can't leverage auto rotation feature

The instances poll Key Vault at four-hour intervals to retrieve a renewed version of the certificate if it exists. If an updated certificate is found, the TLS/SSL certificate that's currently associated with the HTTPS listener is automatically rotated.

https://docs.microsoft.com/en-us/azure/application-gateway/renew-certificates#certificates-on-azure-key-vault
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/application_gateway#key_vault_secret_id

@aravinthraja
Copy link

it would be great application gateway allow the versionless_secret_id we have to leverage the auto rotation Feature, othere wise we need to write some automation script to update the latest certificate version.

@aristosvo
Copy link
Collaborator

aristosvo commented Mar 22, 2023

it would be great application gateway allow the versionless_secret_id we have to leverage the auto rotation Feature, othere wise we need to write some automation script to update the latest certificate version.

@aravinthraja We have been using this feature for a few months now, so as far as I know it should also work for you to put the versionless_secret_id in ssl_certificate.key_vault_secret_id.

@kitarp29 Would you still like to work on this issue? It only requires an update of the docs.

@kitarp29
Copy link

Sure I would like to work on it during the weekend

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants