Azure Resource - overview for configuring App Services Introduction

Introduction

Azure App Services are small footprint web applications that must be configured properly to improve the developer experience and reduce operational engineering overhead.

The following guidelines includes information on the settings for the Terraform defined app_services data structure, so that there are fewer exceptions.

 

A sample app_service definition would look something like this in a Terraform variables file:

```

  App-projectx-nonprod-1 = {

    name                 = "app-projectx-nonprod-1"

    tags                 = {

      Category = "analytical"

    }

    resource_group_key   = "rg-projectx-nonprod-01"

    app_service_plan_key = "ASP-projectx-nonprod-01"

    https_only           = true

    identity = {

      type         = "SystemAssigned"

      identity_ids = null

    }

    mi_access = {

      keyvault_key = "kv-projectx-nonprod-01"

    }

    app_settings = {

    }

  }

```

 

Attributes

Notice the tags are inherited from global and merged with what's defined in the section above. The costcenter and environment are set globally. The cradle is best determined by the app author and is good to be called out specifically in this app_service resource.

 

The resource group should be chosen such that app_service has the same lifespan as those of the other resources in the resource group. Choosing a new resource group for every app_service is not advisable. If the resource group is shared, your application will likely linger long after it has served its purpose.

 

The App Service plan are the computing resources you pay for hosting your app_service. You save money by putting multiple apps into one app service plan. If there are resources to handle the load, app_services can be added to the same app_service plan and when one app_service_plan is full, it can spill over to another. The SKU of the app_service plan determines the maximum number of applications to add as 8, 16, 32 and so on. It is safe to put multiple applications into the same application plan if the vCPU usage is regular. This is true for both non-production and production environment. If you do not want the app_service to share the same fate as others in the plan, a new app_service_plan can be created. You could also isolate your app into a new plan when the app is resource-intensive or has different scalability from those in the existing plan.

 

Secure the traffic to be https_only. This does not change even when the app_service is accessed only through an application gateway. It is also preferable to have a custom domain common to both the application gateway and the app_service and the hostname of the app_service is passed through. Application Gateways have concerns beyond the app_service, so your settings must not have any overrides to the default to begin with and once the gateway is functional, the URL for your application will be made available. App services making calls to other app_services via the azurewebsites.net URL will likely use this new custom domain name when it is made available by the gateway.

 

Your network for the app_service does not need to be made private or require private links and virtual networks integration. Unlike other resources, the IP address allocated to the app_service is not part of the subnets defined for the infrastructure. An app service that is reachable by public IP address can be fully secured with access restrictions such that the only IP address allowed for calls is that of the gateway. Please refrain from changing network settings for unreachability or for specifying in your certificates. Your default certificates and address for your app_service is sufficient until gateway consolidates the traffic.

 

You do not need to request certificates specific to your application name. It is usually a concern for the application gateway and not the app_service.  Also, the default provisioning of the TLS over the azurewebsites.net is sufficient for ensuring encrypted traffic regardless of the origin.

 

The connections that your applications make to data sources are optimally routed by the network regardless of whether your app is the source or the sink. No additional steps are necessary to be taken at the network level. On the other hand, access control via identity helps to secure the connections that the application makes with data stores and other Azure resources. Please do not use security principals. The identity block in the section above generates a managed identity that is granted access to resources such as Key Vaults. A role such as Key Vault Secrets User is used to assign the role-based access to the managed identity of the app_service. No new credentials or connections need to be made by the app_service and it can read the secrets directly without passing any credentials. The keyvault_key specified in the mi_access section above determines the specific keyvault to which the app_service will have access to.

 

Some app_settings are customizable for the app_service but the use of environment variables is discouraged as much as possible. Specifically, client ids, credentials, passwords, and environment do not need to be passed in. These are available to be read dynamically and, in many cases, not required at all.

Alerts for your application have been included with your app_service and sample dashboards are available in the DSI IaC Common repository so that your application is observable and the time for troubleshooting is reduced.

 

Conclusion

With the above guidelines, we remove the unnecessary inclusions that creep up into the app_service configuration and call out the essentials so that there can be more focus on the business logic.