search

hashicorp / terraform-provider-azurerm

Terraform provider for Azure Resource Manager
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs
Mozilla Public License 2.0
4.59k stars 4.63k forks source link

App Service & Azure Functions Easy Auth - Support Auth v2 #12928

Closed dr-dolittle closed 1 year ago

dr-dolittle commented 3 years ago

Community Note

Current Terraform Version

Terraform v1.0.4
azurerm v2.71.0

Description

Using auth in azurerm_function_app enables Easy Auth v1, now v2 is available. Please upgrade.

image

In this context please also allow to set Unauthenticated requests.

image

dr-dolittle commented 3 years ago

@tombuildsstuff Do you plan to add that? And if yes, until when? Thanks

schwarzzz commented 3 years ago

Having the same need for the azurerm_app_service resource.

dr-dolittle commented 2 years ago

@tombuildsstuff

image

I really need the update. Is there a plan to support it?

Thanks

aristosvo commented 2 years ago

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

jackofallops commented 2 years ago

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.

dr-dolittle commented 2 years ago

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

jackofallops commented 2 years ago

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.

drdamour commented 2 years ago

anyone get this working with the beta resources yet?

RSteeno commented 2 years ago

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

rellis-of-rhindleton commented 2 years ago

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

shibayan commented 2 years ago

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.

dougan001 commented 2 years ago

Can anyone confirm if this is fixed in AzureRM 3.0 and the new webapp / function resources?

peepeepopapapeepeepo commented 2 years ago

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:

Divya1388 commented 2 years ago

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

jackofallops commented 2 years ago

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!

jackofallops commented 2 years ago

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.

Satak commented 2 years ago

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.

Ricky-G commented 2 years ago

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

petetnt commented 2 years ago

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]

Remigijus-D commented 2 years ago

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.

ObiWanKenobi commented 2 years ago

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?

ObiWanKenobi commented 2 years ago

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.

image 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 :)

justcallmetrell commented 2 years ago

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]

@petetnt When you do this, this is also revert changes made while it was v2? Or, are the changes still applied when reverted?

mgopez commented 2 years ago

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
  ]
}
jespernohr commented 2 years ago

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

jespernohr commented 2 years ago

I see the same issue as @peepeepopapapeepeepo using the resource azurerm_windows_function_app

Terraform v1.1.7 azurerm v3.12.0

mgopez commented 2 years ago

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
dr-dolittle commented 2 years ago

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

ehsan1503 commented 2 years ago

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

mgopez commented 2 years ago

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"
          }
        }
      }
    }
  })
}
ehsan1503 commented 2 years ago

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

mgopez commented 2 years ago

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.

dr-dolittle commented 2 years ago

@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

Quixotical commented 2 years ago

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

tuxmanu commented 2 years ago

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" { }

kichan commented 1 year ago

Hello dears, Do you know how to enable the web app authenticator? problem

thenecroscope commented 1 year ago

Any update on this please

pythonmonty commented 1 year ago

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

seplee commented 1 year ago

He is stuck until Azure addresses this issue. It seems the Azure team has not looked at it since it was posted in May.

pythonmonty commented 1 year ago

@seplee thanks for the info, hopefully they get to it soon

pk27734 commented 1 year ago

I'm also waiting for this to be fixed.

khurrambilalaurecon commented 1 year ago

We'll appreciate if this gets resolved, As the workaround has some steps which bypass security guidelines..

infogulch commented 1 year ago

This appears to have been solved with the PR linked above.

Does it also address #13833 ?

thenecroscope commented 1 year ago

Also relates to: https://github.com/hashicorp/terraform-provider-azurerm/issues/20820

Dinky7NZ commented 1 year ago

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

katbyte commented 1 year ago

closing as this has been released

github-actions[bot] commented 6 months ago

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.