Weird case with resource names and 502 when hitting the Keycloak

[robedi]

Describe the bug

I manage to write an Bash script to deploy an multi tenant ACA environment. The script runs completely, but I run into an issue with accessing the Keycloak website.

Azure Resource Manager (ARM) API property names (like resourceGroups, customDomains, etc.) are camelCase. But running commands to associate domain to endpoint and route, causes to fail due to incorrect casing of the relevant names. Even manually associating this in the Azure Portal fails. In any case, the certificate is the Microsoft standard and not meant for my domain. The certificate CN refers to swedencentral.compute.inference.ml.azure.com. While the ACA environment is configured and uses AFD Managed (managedCertificate).

Anything else, looks positive in the Azure Portal, even the Domains in the Front Door.

Related command

az afd route update \
    --resource-group "$RESOURCE_GROUP" \
    --profile-name "$AFD_PROFILE_NAME" \
    --endpoint-name "$AFD_ENDPOINT_NAME" -n "route-all" \
    --origin-group "$AFD_ORIGINGROUP_NAME" \
    --supported-protocols Http Https \
    --patterns-to-match "/*" \
    --forwarding-protocol MatchRequest \
    --https-redirect Enabled \
    --custom-domains "$AFD_CUSTOM_DOMAIN_ID" \
    --link-to-default-domain Enabled

Errors

When browsing to the Keycloak website, I get a 502 error message and a mismatch in certificate.

Issue script & Debug output

Force the association with a direct PATCH (canonical way)

AFD_CUSTOM_DOMAIN_ID=$(az afd custom-domain show \
  --resource-group "$RESOURCE_GROUP" \
  --profile-name "$AFD_PROFILE_NAME" \
  --custom-domain-name "$AFD_CUSTOM_DOMAIN_NAME" \
  --query id -o tsv)
  
PATCH_BODY=$(jq -n --arg id "$AFD_CUSTOM_DOMAIN_ID" \
  '{properties:{customDomains:[{id:$id}]}}')

az rest --method patch \
  --url "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Cdn/profiles/$AFD_PROFILE_NAME/afdEndpoints/$AFD_ENDPOINT_NAME/routes/route-all?api-version=2024-02-01" \
  --body "$PATCH_BODY"

Note: I have to assume that "resourceGroups" is the correct spelling and casing.

# Re-check
az rest --method get \
  --url "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Cdn/profiles/$AFD_PROFILE_NAME/afdEndpoints/$AFD_ENDPOINT_NAME/routes/route-all?api-version=2024-02-01" \
  | jq -r '.properties.customDomains'

Note: I have to assume (aagain) that "resourceGroups" is the correct spelling and casing.

Result:

[
  {
    "id": "/subscriptions/469965b0-6d1d-45c1-b9a9-e0befc53bff0/resourcegroups/aca-multi-tenant-dev-rg/providers/Microsoft.Cdn/profiles/mtdev-afd/customdomains/afd-auth-contoso-com",
    "isActive": true
  }
]

But here, as you can see, the "resourcegroups" is different. But also "customdomains" is different from the expected "customDomains".

If route list still shows []

ROUTE_JSON=$(
  az rest --method get \
    --url "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Cdn/profiles/$AFD_PROFILE_NAME/afdEndpoints/$AFD_ENDPOINT_NAME/routes/route-all?api-version=2024-02-01"
)

echo "$ROUTE_JSON" | jq -r '.properties.customDomains'

Result:

[
  {
    "id": "/subscriptions/469965b0-6d1d-45c1-b9a9-e0befc53bff0/resourcegroups/aca-multi-tenant-dev-rg/providers/Microsoft.Cdn/profiles/mtdev-afd/customdomains/afd-auth-contoso-com",
    "isActive": true
  }
]

az rest --method get --url "https://management.azure.com/subscriptions/$(az account show --query id -o tsv)/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Cdn/profiles/$AFD_PROFILE_NAME/customDomains?api-version=2021-06-01"

Result:

{
  "value": [
    {
      "id": "/subscriptions/<Subscription ID>/resourcegroups/<RG name>/providers/Microsoft.Cdn/profiles/<Profile name>/customdomains/afd-auth-contoso-com",
      "name": "afd-auth-contoso-com",
      "properties": {
        "azureDnsZone": null,
        "deploymentStatus": "Succeeded",
        "domainValidationState": "Approved",
        "hostName": "auth.contoso.com",
        "preValidatedCustomDomainResourceId": null,
        "provisioningState": "Succeeded",
        "tlsSettings": {
          "certificateType": "ManagedCertificate",
          "minimumTlsVersion": "TLS12",
          "secret": {
            "id": "/subscriptions/<Subscription ID>/resourceGroups/<RG name>/providers/Microsoft.Cdn/Profiles/<Profile name>/secrets/0--b8aa0cda-4bf1-4367-a6ec-3361e72c0efe-auth-contoso-com"
          }
        },
        "validationProperties": {
          "expirationDate": "2025-09-10T18:42:02.8604038+00:00",
          "validationToken": "_8da7u58zle94cnis0xp7hr2a67y2y9t"
        }
      },
      "type": "Microsoft.Cdn/profiles/customdomains"
    }
  ]
}

Extract from my script

run "Associate AFD custom domain with route" -- \ 
  az afd route update --resource-group "$RESOURCE_GROUP" --profile-name "$AFD_PROFILE_NAME" --endpoint-name "$AFD_ENDPOINT_NAME" -n "route-all" --origin-group "$AFD_ORIGINGROUP_NAME" --supported-protocols Http Https --patterns-to-match "/*" --forwarding-protocol MatchRequest --https-redirect Enabled --custom-domains "$AFD_CUSTOM_DOMAIN_ID" --link-to-default-domain Enabled

az afd route list --resource-group "$RESOURCE_GROUP" --profile-name "$AFD_PROFILE_NAME" --endpoint-name "$AFD_ENDPOINT_NAME"

[
  {
    "customDomains": [],
    "deploymentStatus": "NotStarted",
    "enabledState": "Enabled",
    "forwardingProtocol": "MatchRequest",
    "httpsRedirect": "Enabled",
    "id": "/subscriptions/<Subcription ID>/resourcegroups/<RG name>/providers/Microsoft.Cdn/profiles/<Profile name>/afdendpoints/<Endpoint name>/routes/route-all",
    "linkToDefaultDomain": "Enabled",
    "name": "route-all",
    "originGroup": {
      "id": "/subscriptions/<Subscription ID>/resourceGroups/<RG name>/providers/Microsoft.Cdn/profiles/<Profile name>/originGroups/<OG name>",
      "resourceGroup": "<RG name>"
    },
    "patternsToMatch": [
      "/*"
    ],
    "provisioningState": "Succeeded",
    "resourceGroup": "<RG name>",
    "ruleSets": [],
    "supportedProtocols": [
      "Http",
      "Https"
    ],
    "type": "Microsoft.Cdn/profiles/afdendpoints/routes"
  }
]

debug.log

Expected behavior

When I run the commands to create the variables, I expect to have the "resourceGroups" and "customDomains" correctly written.

Environment Summary

{
  "azure-cli": "2.76.0",
  "azure-cli-core": "2.76.0",
  "azure-cli-telemetry": "1.1.0",
  "extensions": {
    "ml": "2.38.0",
    "ssh": "2.0.6"
  }
}

Additional context

No response

[azure-client-tools-bot-prd]

Hi @robedi,

2.76.0 is not the latest Azure CLI(2.77.0).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

[yonzhan]

Thank you for opening this issue, we will look into it.

[robedi]

az upgrade
This command is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
Your current Azure CLI version is 2.76.0. Latest version available is 2.77.0.
Please check the release notes first: https://learn.microsoft.com/cli/azure/release-notes-azure-cli
Do you want to continue? (Y/n): y
Not able to upgrade automatically. Instructions can be found at https://aka.ms/doc/InstallAzureCli
CLI upgrade failed or aborted.

[robedi]

Update:

Ran this command from the script

if ! az identity show --name "$APPGW_UAMI_NAME" --resource-group "$RESOURCE_GROUP" >/dev/null 2>&1; then
  run "Create UAMI $APPGW_UAMI_NAME" -- \
    az identity create --name "$APPGW_UAMI_NAME" --resource-group "$RESOURCE_GROUP" --location "$LOCATION" --tags "Environment=Development" -o none
fi
APPGW_UAMI_ID="$(az identity show --name "$APPGW_UAMI_NAME" --resource-group "$RESOURCE_GROUP" --query id -o tsv)"

Resulted in:
Resolved AppGW UAMI ID: /subscriptions/<Subcription ID>/resourcegroups/<RG name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/appgw-identity

Same issue with resourcegroups.

[Ptnan7]

The case is a historical issue, but in fact our service is case-insensitive, so I think this problem should still be related to the certificate settings.