Azure.AppService.WebProbe failing while healthCheckPath being set.

[vinhent]

Description of the issue

I am getting a failed on healthCheckPath while it's set to a path.

To Reproduce

Steps to reproduce the issue:

1. Create a module that defines an app service plan and web apps.
2. Add a parameter for healthCheckPath.
3. Create a parameter file with a value for healthCheckPath.

param healthCheckPath string = ''

resource webApps 'Microsoft.Web/sites@2021-03-01' = [for webAppName in webAppNames: {
  name: webAppName
  location: location
  tags: tags
  properties: {
    enabled: true
    serverFarmId: plan.id
    siteConfig: {
      healthCheckPath: '/api/help'
      autoHealEnabled: true
    }
    clientAffinityEnabled: false
    httpsOnly: true
  }
  identity: {
    type: 'SystemAssigned'
  }
}]

Expected behaviour

Test should pass since a value is set in healthCheckPath.

Error output

[FAIL] Azure.AppService.WebProbe (AZR-000079)
| Template: modules/appService.bicep:258:5
| Parameter: tests/appService.parameters.json:1:0

| RECOMMEND:
| Consider configuring a health probe to monitor instance availability.

| REASON:
| - Path Properties.siteConfig.healthCheckPath: Is set to '/api/help'.

| HELP:
| - https://azure.github.io/PSRule.Rules.Azure/en/rules/Azure.AppService.WebProbe/

[error]AZR-000079: cic-test-app failed Azure.AppService.WebProbe. Configure and enable instance health probes.

[error]AZR-000079: cic-test-app failed Azure.AppService.WebProbe. Configure and enable instance health probes.

Module in use and version:

• Module: PSRule.Rules.Azure
• Version: [e.g. 1.21.2]

Captured output from $PSVersionTable:

Additional context

[yzhu228]

I had the same issue before.

A workaround is to avoid using the siteConfig within Microsoft.Web/sites resource. Instead using the Microsoft.Web/sites/config and set the healthCheckPath under its properties.

This I think it is a bug, on the line

PSRule.Rules.Azure/src/PSRule.Rules.Azure/rules/Azure.AppService.Rule.ps1

Line 115 in f5875a3

return $Assert.HasFieldValue($TargetObject, 'Properties.siteConfig.healthCheckPath', $True);

[BenjaminEngeset]

From what I can see so far, the rule is expecting the value to be boolean true, where actually the healthCheckPath property is expecting a value of type string. So your valid value is not honored currently.

I'll wait for @BernieWhite to confirm that this is the case and I'll put together an PR.

[yzhu228]

I have a double on the necessity of having two rules Azure.AppService.WebProbe and Azure.AppService.WebProbePath of overlapped purpose, one for the healthCheckPath's existence while another is for it's not empty.

Is there any reason we have these 2 rules instead of consolidating them into 1?

[BernieWhite]

@vinhent Thanks for reporting the issue. This is a bug.

@yzhu228 and @BenjaminEngeset are correct, the rule is checking for true instead of a string for the property Properties.siteConfig.healthCheckPath.

PSRule.Rules.Azure/src/PSRule.Rules.Azure/rules/Azure.AppService.Rule.ps1

Line 115 in f5875a3

return $Assert.HasFieldValue($TargetObject, 'Properties.siteConfig.healthCheckPath', $True);

Line 115 should be updated to be:

return $Assert.HasFieldValue($TargetObject, 'Properties.siteConfig.healthCheckPath');

In this rule we are checking that a health probe is configured.

---

@yzhu228 In regard to your question about why is there two rules. This is because while using a dedicated health check path (such as /healthz) is the recommended practise from the WAF, it is not always possible due to third-party applications or legacy code.

Providing two rules give the customer an opportunity to suppress this rule for cases where a dedicated endpoint is not possible but still required a health check to be configured.