Closed dr-dolittle closed 1 year ago
@tombuildsstuff Do you plan to add that? And if yes, until when? Thanks
Having the same need for the azurerm_app_service
resource.
@tombuildsstuff
I really need the update. Is there a plan to support it?
Thanks
@jackofallops Do you mind if I give this a try this week?
@dr-dolittle It this possibly already fixed in the new appservice
resources which will replace the current app service
resources in 3.0 and which are available to test, like here. Would you mind taking a look at that? You'd need to take a look at the 3.0-app-service-beta guide how to enable/use them.
At this moment this is only available yet for the web apps, but azurerm_linux_function_app
is in for the release of this week, azurerm_windows_function_app
will follow soon I believe.
Hi @aristosvo & @dr-dolittle
I've extended auth somewhat in the beta resources, but the service is a moving target to complete coverage so this isn't in there yet.
The Portal Experience linked above is only loosely coupled to the available configuration options, rather than the settings being deprecated, so I believe we'll just need to adapt the new resources to cover the new authv2 request instead of the current one (most of the data is the same). Our intent is to feature-freeze the existing resources due to the repeated regressions experienced when we/anyone attempts to update/enhance them. This is a non-trivial change for those resources, since it means migrating to a completely different structure in the SDK for the request (though I don't think there's any breaking change at first glance). If you still want to give it some attention, we'll give it fair (and cautious) review, but I'll be making the change to authv2 in the beta resources soon.
Thanks for your responses.
Unfortunately I can't use beta as this is about productive systems. And we use functions apps (Linux).
Is my understanding correct that you will then not update the not-beta version but include it in the upcoming version? When do you expect the beta version to become general available?
If it is possible it would be great if the not-beta version can be updated to support authv2.
Please let me know how you plan to proceed and with which timeline.
Thanks
Hi @dr-dolittle - Apologies if I was unclear. To the best of my understanding the change is only the Portal Blade, the Terraform resource will continue to work as previously. The V2 settings are an extension of the current properties, and where they overlap they are configuring the same properties on the resource. Whilst they won't support the additional options, such as the extra unauthenticated request
actions, settings should be correctly represented in the new blade from the original configuration. The migration to v2 is problematic in the existing resource, due to the brittle nature of the existing code, and that the SDK exposes this as an entirely different structure. At this time we feel this effort should be spent on the new resources, that are intended to remove this implementation challenge.
The new beta resources will be being migrated to the V2 config in the next week or two.
The release of 3.0, including promoting these new resources out of beta, is detailed in the pinned issue, which we'll be keeping updated as development proceeds.
anyone get this working with the beta resources yet?
@jackofallops I'm particularly interested in the support for custom OIDC providers that V2 delivers. My current workaround is to use the az webapp auth openid-connect
command to add a custom provider.
I'm open to helping out with testing this aspect of the V2 implementation if you need it.
@jackofallops -- If I understand this correctly (no promises there) then I'm not sure this is quite right:
To the best of my understanding the change is only the Portal Blade, the Terraform resource will continue to work as previously. The V2 settings are an extension of the current properties, and where they overlap they are configuring the same properties on the resource. Whilst they won't support the additional options, such as the extra unauthenticated request actions, settings should be correctly represented in the new blade from the original configuration.
I can set the authentication on an app service using the Terraform 2.x (non-beta) resource, and it works, and the app service's authentication performs as expected. But the settings are no longer manageable or viewable from the Azure portal blade. If I use the blade to migrate to auth v2, Terraform's current resource is no longer able to manage the authentication (or the app service) and any attempt to do so will produce an error.
So basically I have to leave authentication at the deprecated version and just hope it keeps working until TF v3 is production. Maybe it will, but it makes me uneasy.
I totally understand the reluctance to update the old resources. Just wanted to make sure we're clear on all this. If for some reason the current TF resource stops working with app service authentication then we will be stuck.
Thanks and apologies if I missed the point.
In my opinion, considering the affinity with Azure AD Provider and the structure of ARM API, the best solution is to separate Auth Settings as a sub-resource.
The subresource we are considering now is roughly defined as follows. It may be similar to the azurerm_subnet relationship.
resource "azurerm_auth_settings" "example" {
app_service_id = azurerm_functionapp.example.id
enabled = true
active_directory {
client_id = "***"
client_secret = "***"
}
open_id_connect {
}
forwarded_proxy {
convention = "Standard"
}
}
The biggest advantage of separating the authentication configuration as a sub-resource is that it is not affected by differences such as azurerm_app_service and azurerm_windows_webapp. You can adopt a modern design since you only need to link them by resource ID.
In addition, since the parent resource is executed after it is created, you can use the URI required to create the application in Azure AD, thus avoiding circular references.
I really need Auth V2 now and would like to implement a new resource to solve this problem if possible.
Can anyone confirm if this is fixed in AzureRM 3.0 and the new webapp / function resources?
It is still not work in AzureRM 3.0.2 with linux_function_app
I tested by setting runtime_version
in auth_settings
block to "~2"
.
resource "azurerm_linux_function_app" "main" {
. . .
auth_settings {
. . .
runtime_version = "~2"
. . .
}
}
In the portal still show that authentication setting in my function app is still a classic version (v1).
I try to convert to v2 in portal and then add another authentication provider then I got this error
Error: updating Auth Settings for Linux Function App: (Site Name "func-testmodule-az-asse-sbx-001" / Resource Group "rg-azurefunction-az-asse-sbx-001"): web.AppsClient#UpdateAuthSettings: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="BadRequest" Message="Cannot execute the request for site func-testmodule-az-asse-sbx-001 because the site is running on auth version v2." Details=[{"Message":"Cannot execute the request for site func-testmodule-az-asse-sbx-001 because the site is running on auth version v2."},{"Code":"BadRequest"},{"ErrorEntity":{"Code":"BadRequest","ExtendedCode":"04534","Message":"Cannot execute the request for site func-testmodule-az-asse-sbx-001 because the site is running on auth version v2.","MessageTemplate":"Cannot execute the request for site {0} because the site is running on auth version {1}.","Parameters":["func-testmodule-az-asse-sbx-001","v2"]}}]
It seem like the authentication setting in my function became v2 already but terraform still try to talk to ARM with v1
I debug and found that azurerm provider is still call to authsettings
rather than authsettingsv2
v1 : POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/config/authsettings/list?api-version=2021-02-01
v2 : GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/config/authsettingsV2/list?api-version=2021-02-01
REF:
I see the same issue as @peepeepopapapeepeepo using the resource azurerm_windows_web_app in azurerm 3.0.2
Any clarity on the time frame for this release will be helpful to plan our deployments
Hi all 👋
Just a quick note here to clarify where "things" are at.
The rewrite of the resources was a significant undertaking, and we had to be pragmatic about some decisions on what changed and what we retained/added based on time available and our expectations on how difficult it might be to migrate to the replacement resources. One of the items postponed was the inclusion of "authv2". For what it's worth, it's high on the todo list, so one of the team will be picking it up for an upcoming release in the not-too-distant future.
Thanks!
Hi All - Good news / bad news... I have this as a work in progress, however, I've run into an SDK/API bug that's blocking progress. I've opened an issue to track this here: https://github.com/Azure/azure-rest-api-specs/issues/18888
As soon as we have a resolution to this I'll pick this straight back up.
We noticed that if you upgrade the auth runtime to V2 from Azure console and try to run again terraform against that azure function the terraform run will fail to error message:
Cannot execute the request for site <funtion name> because the site is running on auth version v2."
Someone opened issue about this same problem here: https://github.com/hashicorp/terraform-provider-azurerm/issues/13795 but it was closed for some reason. This is a very valid bug report and should be fixed.
For anything the current Terraform provider doesn't support, there is the new AzAPI https://docs.microsoft.com/en-us/azure/developer/terraform/overview-azapi-provider
This should give you full access to all preview and missing features in the AzArm provider.
So in this case for adding the auth-settings-v2, you can do something like below
terraform {
required_providers {
azapi = {
source = "Azure/azapi"
}
}
}
resource "azapi_resource" "example" {
name = "example"
parent_id = data.azurerm_functionapp.example.existing.id
type = "Microsoft.Web/sites/config@2021-03-01"
location = "eastus"
body = jsondecode({
properties = {
identityProviders = {
azureActiveDirectory = {
enabled = true
isAutoProvisioned = false
login = {
disableWWWAuthenticate = true
loginParameters = [
'string'
]
}
registration = {
clientId = 'string'
clientSecretCertificateIssuer = 'string'
clientSecretCertificateSubjectAlternativeName = 'string'
clientSecretCertificateThumbprint = 'string'
clientSecretSettingName = 'string'
openIdIssuer = 'string'
}
}
}
}
})
}
For reference to all the properties supposed for auth refer to https://docs.microsoft.com/en-us/azure/templates/microsoft.web/sites/config-authsettingsv2?tabs=bicep
For those that have upgraded to Auth v2
and now regret it, you can downgrade back to v1
with az cli `az webapp auth config-version revert --name --resource-group [--slot]
Hello Terraform devs, wouldn't be nice to have this as a warning note on top of the documentation for resource that does not support v2 auth? That would save some peoples time while they're trying to figure out. Just a heads up would be appreciated. Thank you.
Hi,
I'm having the same problem with azurerm_linux_function_app
. I can run terraform "locally", but when I'm trying to run it from Azure Pipelines I get the same error as mentioned above:
Error: updating Auth Settings for Linux Function App: (Site Name "SITENAME-X" / Resource Group
"RESOURCEGROUP-X"): web.AppsClient#UpdateAuthSettings: Failure responding to request: StatusCode=400
-- Original Error: autorest/azure: Service returned an error. Status=400 Code="BadRequest"
Message="Cannot execute the request for site FUNCTIONAPP-X because the site is running on auth
version v2." Details=[{"Message":"Cannot execute the request for site FUNCTIONAPP-X because the site is
running on auth version v2."},{"Code":"BadRequest"},{"ErrorEntity {"Code":"BadRequest","
ExtendedCode":"04534","Message":"Cannot execute the request for site FUNCTIONAPP-X because the site
is running on auth version v2.","MessageTemplate":"Cannot execute the request for
site {0} because the site is running on auth version {1}.","Parameters":["FUNCTIONAPP-X","v2"]}}]
I also tried with the runtime_version
setting:
resource "azurerm_linux_function_app" "X" {
...
auth_settings {
enabled = true
token_store_enabled = true
unauthenticated_client_action = "RedirectToLoginPage"
token_refresh_extension_hours = 0
runtime_version = "~1"
active_directory {
client_id = X
client_secret_setting_name = "X"
}
}
But I still get the v2-error.
It seems that I have to update the agents in Azure Devops to get it to work with v.2 due to that it works locally and not in devops. Unfortunately I don't have the rights to do that. So that is not an option.
So, any news on a workaround for azurerm_linux_function_app
?
Hi,
I'm having the same problem with
azurerm_linux_function_app
. I can run terraform "locally", but when I'm trying to run it from Azure Pipelines I get the same error as mentioned above: ... ... ...
I tried to remove the resource completely and changed it to azurerm_windows_function_app
in the terraform file instead with the same settings I had on the azurerm_linux_function_app
. Then my pipeline worked.
Then it looks like this in the func app.
But it is not sustainable to have to do it like that to be able to downgrade the auth version.
I would gladly receive any better suggestions on how to solve this :)
For those that have upgraded to
Auth v2
and now regret it, you can downgrade back tov1
with az cli `az webapp auth config-version revert --name --resource-group [--slot]
@petetnt When you do this, this is also revert changes made while it was v2? Or, are the changes still applied when reverted?
A work around can be to use a local-exec
to run the upgrade command.
Note: This is not great, but works for me in the mean time.
resource "null_resource" "app_auth" {
provisioner "local-exec" {
interpreter = ["/bin/bash", "-c"]
command = <<-EOT
az config set extension.use_dynamic_install=yes_without_prompt
az webapp auth config-version upgrade --name ${var.webapp_name} --resource-group ${var.webapp_resource_group}
EOT
}
}
and to update the siteAuthSettingsV2
config:
resource "azapi_update_resource" "auth_v2_config" {
type = "Microsoft.Web/sites/config@2020-12-01"
resource_id = "${var.webapp_id}/config/web"
body = jsonencode({
properties = {
siteAuthSettingsV2 = {
// Your specific auth v2 configs here
}
}
})
depends_on = [
null_resource.app_auth
]
}
A work around can be to use a
local-exec
to run the upgrade command. Note: This is not great, but works for me in the mean time.resource "null_resource" "app_auth" { provisioner "local-exec" { interpreter = ["/bin/bash", "-c"] command = <<-EOT az config set extension.use_dynamic_install=yes_without_prompt az webapp auth config-version upgrade --name ${var.webapp_name} --resource-group ${var.webapp_resource_group} EOT } }
and to update the
siteAuthSettingsV2
config:resource "azapi_update_resource" "auth_v2_config" { type = "Microsoft.Web/sites/config@2020-12-01" resource_id = "${var.webapp_id}/config/web" body = jsonencode({ properties = { siteAuthSettingsV2 = { // Your specific auth v2 configs here } } }) depends_on = [ null_resource.app_auth ] }
Thanks mgopez. Do i need to login to azure prior running these az config commands? I would like to use my "Service Connection" within Azure DevOps if possible. and not declare tenantid,appid or secret
I see the same issue as @peepeepopapapeepeepo using the resource azurerm_windows_function_app
Terraform v1.1.7 azurerm v3.12.0
A work around can be to use a
local-exec
to run the upgrade command. Note: This is not great, but works for me in the mean time.resource "null_resource" "app_auth" { provisioner "local-exec" { interpreter = ["/bin/bash", "-c"] command = <<-EOT az config set extension.use_dynamic_install=yes_without_prompt az webapp auth config-version upgrade --name ${var.webapp_name} --resource-group ${var.webapp_resource_group} EOT } }
and to update the
siteAuthSettingsV2
config:resource "azapi_update_resource" "auth_v2_config" { type = "Microsoft.Web/sites/config@2020-12-01" resource_id = "${var.webapp_id}/config/web" body = jsonencode({ properties = { siteAuthSettingsV2 = { // Your specific auth v2 configs here } } }) depends_on = [ null_resource.app_auth ] }
Thanks mgopez. Do i need to login to azure prior running these az config commands? I would like to use my "Service Connection" within Azure DevOps if possible. and not declare tenantid,appid or secret
Yes you need to be authenticated prior to running these commands. I also run this within Azure DevOps pipelines, but during an AzCLI task. From there you can then do this to make those credentials available for this resource to run.
Example:
- task: AzureCLI@2
inputs:
azureSubscription: your-service-connection-here
scriptType: 'bash'
scriptLocation: 'inlineScript'
addSpnToEnvironment: true # This is the line that makes the service connection credentials available using the $vars below
inlineScript: |
export ARM_CLIENT_ID=$servicePrincipalId
export ARM_CLIENT_SECRET=$servicePrincipalKey
export ARM_TENANT_ID=$tenantId
# Your Terraform commands here using the above specified service principal
There is also the option to use an ARM template within Terraform: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/resource_group_template_deployment
can you please provide an example of how to define the siteAuthSettingsV2, i could do identityProviders = { azureActiveDirectory = { enabled = true registration = { "clientId" = clinetid } } } but not more @mgopez
can you please provide an example of how to define the siteAuthSettingsV2, i could do identityProviders = { azureActiveDirectory = { enabled = true registration = { "clientId" = clinetid } } } but not more @mgopez
Sure. You can add anything from below to this settings block: https://docs.microsoft.com/en-us/azure/templates/microsoft.web/sites/config-authsettingsv2?tabs=bicep#siteauthsettingsv2properties
An example could be to add a forwardProxy setting which for now can only be done via ARM, resources.azure.com, or this work around.
resource "azapi_update_resource" "set_forward_proxy" {
type = "Microsoft.Web/sites/config@2020-12-01"
resource_id = "${var.webapp_id}/config/web"
body = jsonencode({
properties = {
siteAuthSettingsV2 = {
httpSettings = {
requireHttps = true,
routes = {
apiPrefix = "/.auth"
}
forwardProxy = {
convention = "Custom"
customHostHeaderName = "X-original-host"
}
}
}
}
})
}
can you please provide an example of how to define the siteAuthSettingsV2, i could do identityProviders = { azureActiveDirectory = { enabled = true registration = { "clientId" = clinetid } } } but not more @mgopez
Sure. You can add anything from below to this settings block: https://docs.microsoft.com/en-us/azure/templates/microsoft.web/sites/config-authsettingsv2?tabs=bicep#siteauthsettingsv2properties
An example could be to add a forwardProxy setting which for now can only be done via ARM, resources.azure.com, or this work around.
resource "azapi_update_resource" "set_forward_proxy" { type = "Microsoft.Web/sites/config@2020-12-01" resource_id = "${var.webapp_id}/config/web" body = jsonencode({ properties = { siteAuthSettingsV2 = { httpSettings = { requireHttps = true, routes = { apiPrefix = "/.auth" } forwardProxy = { convention = "Custom" customHostHeaderName = "X-original-host" } } } } }) }
thanks for the quick response, that part works! but the globalValidation and its properties like unauthenticatedClientAction still not working for me @mgopez
can you please provide an example of how to define the siteAuthSettingsV2, i could do identityProviders = { azureActiveDirectory = { enabled = true registration = { "clientId" = clinetid } } } but not more @mgopez
Sure. You can add anything from below to this settings block: https://docs.microsoft.com/en-us/azure/templates/microsoft.web/sites/config-authsettingsv2?tabs=bicep#siteauthsettingsv2properties An example could be to add a forwardProxy setting which for now can only be done via ARM, resources.azure.com, or this work around.
resource "azapi_update_resource" "set_forward_proxy" { type = "Microsoft.Web/sites/config@2020-12-01" resource_id = "${var.webapp_id}/config/web" body = jsonencode({ properties = { siteAuthSettingsV2 = { httpSettings = { requireHttps = true, routes = { apiPrefix = "/.auth" } forwardProxy = { convention = "Custom" customHostHeaderName = "X-original-host" } } } } }) }
thanks for the quick response, that part works! but the globalValidation and its properties like unauthenticatedClientAction still not working for me @mgopez
I haven't played around with those parameters much. What you could do is deploy it manually through the portal. Then use resources.azure.com to manually inspect the configuration. Then copy that configuration for use in your Terraform configs.
@jackofallops Any updates? azurerm_linux_function_app
seems not to support v2, there is also no information in the docs (https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/linux_function_app). Thanks
resources.azure.com
@mgopez THANK YOU for referring to https://resources.azure.com/!!! I had no idea this existed but now it makes using azapi so easy :O
the annoying part for me was understanding exactly what it was I needed to update/create
type = "Microsoft.Web/sites/config@2020-12-01"
resource_id = "${azurerm_windows_function_app.api_users.id}/config/authsettingsV2"
this type/resource_id combo is what worked for me in the end
resources.azure.com
@mgopez THANK YOU for referring to https://resources.azure.com/!!! I had no idea this existed but now it makes using azapi so easy :O
the annoying part for me was understanding exactly what it was I needed to update/create
type = "Microsoft.Web/sites/config@2020-12-01" resource_id = "${azurerm_windows_function_app.api_users.id}/config/authsettingsV2"
this type/resource_id combo is what worked for me in the end
Worked for me as well, after adding the necessary provider:
terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "= 3.28.0" } azapi = { source = "Azure/azapi" } } } provider "azurerm" { features {} } provider "azapi" { }
Hello dears, Do you know how to enable the web app authenticator?
Any update on this please
@jackofallops any news on when azurerm_windows_web_app
and azurerm_linux_web_app
will support auth v2? Updating outside of terraform via az webapp auth config-version upgrade
is not ideal since it adds a secret to app_settings, which terraform knows nothing about.
He is stuck until Azure addresses this issue. It seems the Azure team has not looked at it since it was posted in May.
@seplee thanks for the info, hopefully they get to it soon
I'm also waiting for this to be fixed.
We'll appreciate if this gets resolved, As the workaround has some steps which bypass security guidelines..
This appears to have been solved with the PR linked above.
Does it also address #13833 ?
Also relates to: https://github.com/hashicorp/terraform-provider-azurerm/issues/20820
Feature exists now and release since azurerm v3.46 iirc. There were some bugs tho which have had fixes too. I upgraded to v3.52 and seems stable for what I'm doing
closing as this has been released
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.
Community Note
Current Terraform Version
Description
Using
auth
in azurerm_function_app enables Easy Auth v1, now v2 is available. Please upgrade.In this context please also allow to set
Unauthenticated requests
.