AGIC route table warning in multi-subscription and Azure CNI setup

[krisdg]

I'm setting up an environment where the node pools and Application Gateway are in different subscriptions and virtual networks. SubscriptionA contains VNetA, which is associated with the AppGw. SubscriptionB contains VNetB, used by AKS. The vnets are peered to each other. While configuring AGIC via the AKS extension, I observe that the AppGw is being updated, indicating that workload identity authorization is correctly configured.

However, the following log entry appears in the AGIC pod:

  Warning  FailedCNIConfiguration  28s   azure/application-gateway  failed to reconcile kubenet CNI: Unable to associate Application Gateway subnet '/subscriptions/SubscriptionA/resourceGroups/xxxx/providers/Microsoft.Network/virtualNetworks/vnet-appgw/subnets/AppGwSubnet' with route table '/subscriptions/SubscriptionB/resourceGroups/worker-rg/providers/Microsoft.Network/routeTables/aks-agentpool-38674675-routetable' due to error (this is relevant for AKS clusters using 'Kubenet' network plugin): network.RouteTablesClient#Get: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client 'c82c35f5-a5a4-44a9-a39c-51c3a446f183' with object id 'c82c35f5-a5a4-44a9-a39c-51c3a446f183' does not have authorization to perform action 'Microsoft.Network/routeTables/read' over scope '/subscriptions/SubscriptionA/resourceGroups/worker-rg/providers/Microsoft.Network/routeTables/aks-agentpool-38674675-routetable' or the scope is invalid. If access was recently granted, please refresh your credentials.

c82c35f5-a5a4-44a9-a39c-51c3a446f183 is the ClientID of the managed identity assigned to the appgw ingress controller

After breaking down the warning step by step, a few interesting points emerge:

this is relevant for AKS clusters using 'Kubenet' network plugin
This seems to be the concluding statement. I do not use kubenet as network plugin, but the Azure CNI. Which means: no route tables are being used. Does that mean I can safely ignore the warning? Also, why is it trying to associate a route table with the AppGwSubnet? The nodepool subnet does not use that routetable either.

Original Error: autorest/azure: Service returned an error. Status=403
This makes sense. Although the permissions are correctly set, the system is attempting to assign a non-existent route table. It is trying to read the resource at: /subscriptions/SubscriptionA/resourceGroups/worker-rg/providers/Microsoft.Network/routeTables/aks-agentpool-38674675-routetable
which is not correct. The routetable is not located in SubscriptionA (appgw), but in SubscriptionB. This scope appears to be dynamically generated, as I was not able to configure it manually.

The setup works fine for me now, but I wanted to share these findings. The procedure triggers a warning, even though it shouldn't run at all. If the scope did exist, it would have associated the wrong route table