RequireServerNameIndication flag not set on multi-site listeners (hostname/TLS)

[robertprather]

Describe the bug
We are using Application Gateway (v1) Medium WAF SKU, AKS and Ingress Controller v0.7.1 deployed via helm chart.

We recently upgraded to use the multiple watched namespaces feature each namespaced deployment using k8s ingress definition according to the docs "Expose services over HTTPS" -> "With specified hostname".

When ingress controller updates the gateway, all looks OK - multi-site host listeners configured as expected with the correct TLS certificate.

When browsing to one of the sites by hostname I am routed via the wrong listener. Looking at the resource definition, RequireServerNameIndication = false on my multi-site listener and it should be true

(I believe this is because gateway processes requests to multi-site (hostname) listeners in an order I can't determine.)

To Reproduce
Steps to reproduce the behavior:
Configure Ingress controller to watch multiple namespaces (eg. watchNamespace: ).
Deploy pods to multiple namespaces using Ingress defintions with TLS/hostname (e.g. hostname1/cert1, hostname2/cert2).
After gateway update,

• attempt to access one of the sites in a browser (e.g. hostname1) - site loads correctly.
• attempt to access the other site in a browser (e.g. hostname2) - site loads incorrectly and presents incorrect cert from other site (e.g. expected cert2, received cert1).

Workaround
This is not a useful workaround but does point to the root cause of the issue.
After the ingress controller has updated the gateway, use Azure CLI to update all https listeners as below.

az network application-gateway http-listener update -g RG --gateway-name AGW -n fl-hostname1-443 --set RequireServerNameIndication=true --force-string
az network application-gateway http-listener update -g RG --gateway-name AGW -n fl-hostname2-443 --set RequireServerNameIndication=true --force-string

Doing so resolves the issue and gateway routes correctly by SNI. This workaround is not compatible with ingress controller as the next update to the gateway reverts the requireServerNameIndication flag to false.

Ingress Controller details

• Output of kubectl describe pod <ingress controller> . The pod name can be obtained by running helm list.

Name:               ingress-azure-xxxxx-aaa
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               aks-agentpool1-xxxxxx-0/10.240.0.4
Start Time:         Thu, 25 Jul 2019 16:27:44 +1000
Labels:             aadpodidbinding=ingress-azure
                    app=ingress-azure
                    pod-template-hash=xxxxx
                    release=ingress-azure
Annotations:        <none>
Status:             Running
IP:                 10.240.0.24
Controlled By:      ReplicaSet/ingress-azure-xxxxx
Containers:
  ingress-azure:
    Container ID:   docker://978b785fa628e7d0e19d24ef536a10c04d63c59f29f7a4adc7d0008cfb89e4eb
    Image:          mcr.microsoft.com/azure-application-gateway/kubernetes-ingress:0.7.1
    Image ID:       docker-pullable://mcr.microsoft.com/azure-application-gateway/kubernetes-ingress@sha256:7474a032ed48a82105b960844e32fef203067a60e9a46a5c7a298b103c38725c
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Fri, 26 Jul 2019 08:03:54 +1000
    Last State:     Terminated
      Reason:       Error
      Exit Code:    255
      Started:      Thu, 25 Jul 2019 16:27:54 +1000
      Finished:     Fri, 26 Jul 2019 08:03:07 +1000
    Ready:          True
    Restart Count:  1
    Environment Variables from:
      ingress-azure  ConfigMap  Optional: false
    Environment:     <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from ingress-azure-token-v95rp (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  ingress-azure-token-v95rp:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  ingress-azure-token-v95rp
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <none>

• Ingress definition - namespace 1

Name:             app-ingress1
Namespace:        ns1
Address:
Default backend:  default-http-backend:80 (<none>)
TLS:
  app-hostname1-tls terminates hostname1
Rules:
  Host                   Path  Backends
  ----                   ----  --------
hostname1        app:8080 (<none>)
Annotations:
  appgw.ingress.kubernetes.io/cookie-based-affinity:  true
  appgw.ingress.kubernetes.io/ssl-redirect:           true
  kubernetes.io/ingress.class:                        azure/application-gateway
Events:                                               <none>

• Ingress definition - namespace 2

Name:             app-ingress1
Namespace:        ns2
Address:
Default backend:  default-http-backend:80 (<none>)
TLS:
  app-hostname2-tls terminates hostname2
Rules:
  Host                   Path  Backends
  ----                   ----  --------
hostname2        app:8080 (<none>)
Annotations:
  appgw.ingress.kubernetes.io/ssl-redirect:           true
  kubernetes.io/ingress.class:                        azure/application-gateway
Events:                                               <none>

• Output of `kubectl logs .
• Any Azure support tickets associated with this issue.

[robertprather]

This small bug is a frustrating blocker for us, any comments from the team @akshaysngupta ?
Will you review a PR for it as I'd be keen to see this in...

[krottiers]

@akshaysngupta I have a customer facing the same issue. Is there a timeline on a fix?