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

r/app_service_certificate - support for app_service_environment_id #7756

Closed
andydkelly-ig opened this issue Jul 15, 2020 · 5 comments
Closed

Comments

@andydkelly-ig
Copy link

andydkelly-ig commented Jul 15, 2020

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

Description

It would be useful to be able to pass in the serverFarmId (App Service Plan) to the azurerm_app_service_certificate resource as this is causing an issue for me. The issue arises if you move your App Service between Resource Groups at any point. The webspace used by the App Service can change. When importing a certificate from Key Vault into a location you cannot select the Webspace this goes into. In my case we have ended up with 2 webspaces in both North Central US (d3s-ui-NorthCentralUSwebspace and northcentraluswebspace) and Central India (d3s-ui-pune-CentralIndiawebspace and d3s-ui-CentralIndiawebspace) and we have no control over which webspace the certs get imported to. As it happens for both these App Services the certs are imported into the "wrong" app service when we use Terraform (or the API) and so cannot be seen by the App Service. Microsoft workaround for this is to pass in the serverFarmId when creating the certificate which will ensure it gets put in the correct webspace. This parameter is documented in the API (https://docs.microsoft.com/en-us/rest/api/appservice/certificates/createorupdate) under setting
properties.serverFarmId.

New or Affected Resource(s)

  • azurerm_app_service_certificate

Potential Terraform Configuration

resource "azurerm_app_service_certificate" "newCert" {
  name                = "test-certificate"
  resource_group_name = "testGroup"
  location            = "North Central US"
  key_vault_secret_id = "bd700dce11f6207bb420e02e6db43205"
  server_farm_id = "/subscriptions/ab4c26b1-XXXX-165b-9657-894d862fXXXX/resourceGroups/testGroup/providers/Microsoft.Web/serverFarms/usCentralAppServicePlan"
}

References

https://docs.microsoft.com/en-us/rest/api/appservice/certificates/createorupdate
https://dotnetdevlife.wordpress.com/2019/08/21/add-certificate-to-azure-appservice-from-keyvault/
https://dotnetdevlife.wordpress.com/2020/07/13/import-certificate-using-rest-apis/

@tombuildsstuff
Copy link
Member

This wants to be named app_service_environment_id rather than server_farm_id since ServerFarm refers to one of the older names for this functionality

@tombuildsstuff tombuildsstuff changed the title Support for serverFarmId property in azurerm_app_service_certificate resource r/app_service_certificate - support for app_service_environment_id Jul 15, 2020
@andydkelly-ig
Copy link
Author

thanks Tom

@tombuildsstuff
Copy link
Member

hey @andydkelly-ig

I've just noticed that this is a duplicate of #5115 - which has been fixed via #7087 and so this field is available as hosting_environment_profile_id. Whilst we should probably rename this in a future version of the Azure Provider - it appears this functionality is available and as such I'm going to close this issue for the moment - but please let us know if that doesn't work for you and we'll take another look.

Thanks!

@andydkelly-ig
Copy link
Author

Thanks Tom - i'd checked that but didn't realise that's what that variable was... Will give it a whirl and see how i go. Will be great to be able to close out this last manual process 👍

@ghost
Copy link

ghost commented Sep 27, 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 👉 hashibot-feedback@hashicorp.com. Thanks!

@hashicorp hashicorp locked and limited conversation to collaborators Sep 27, 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

2 participants