AKS Ingress and App Gateway Integration

sneh srivastavasneh srivastava
4 min read

AKS Ingress Issue with Managed Identity and App Gateway Integration

Working with Azure Kubernetes Service (AKS) and Application Gateway Ingress Controller (AGIC) can be incredibly powerful — but sometimes, subtle configuration mismatches can cause hours of head-scratching.

In this article, I’ll walk you through how I resolved a real-world issue where an AKS Ingress was failing to update an Application Gateway (App Gateway) due to a permissions issue with its Managed Identity (MI).


🧩 The Scenario

  • AKS cluster and App Gateway were deployed in the same resource group.

  • However, the Ingress Managed Identity was created in a different resource group.

  • The Ingress was not able to apply configuration updates to the App Gateway, causing Ingress provisioning to fail.


🔎 Root Cause

Ingress communicates with the App Gateway using a User Assigned Managed Identity (UAMI). This MI needs specific permissions on both the App Gateway and its own identity object.

What was misconfigured:

  • The MI only had the Contributor role on the App Gateway's resource group.

  • To update App Gateway backend pools and related configurations, additional roles are required:

    • Network Contributor on the App Gateway's resource group.

    • Managed Identity Operator on the MI's own resource scope (especially important when MI is in a different resource group).


🧸 Simple Analogy – Explaining It to a 10-Year-Old

Imagine this like a school project:

  • You (the AKS Ingress) want to update a big whiteboard (App Gateway) in your school.

  • You’ve been given a marker (Managed Identity) to write on the whiteboard.

  • The whiteboard is in Room A (App Gateway’s resource group), but your marker is stored in Room B (Managed Identity’s resource group).

  • The school only lets you use a marker from another room if you have a special permission slip (Managed Identity Operator role).

  • Without that slip, even if you have the marker and are allowed in Room A, the school stops you from writing because you didn't officially get permission to borrow the marker from Room B.

Once you get that permission slip (by assigning the correct role), you can take the marker, walk into Room A, and write on the whiteboard with no issues.


🚨 The Error Message

The Ingress controller started failing with this error:

plaintextCopyEditreason: FailedApplyingAppGwConfig
message: >-
  network.ApplicationGatewaysClient#CreateOrUpdate: Failure sending request:
  StatusCode=403 -- Original Error: Code="LinkedAuthorizationFailed"
  Message="The client '<ObjectID>' has permission to perform action
  'Microsoft.Network/applicationGateways/write' on scope
  '/subscriptions/<sub-id>/resourceGroups/<app-gw-rg>/providers/Microsoft.Network/applicationGateways/<gateway-name>';
  however, it does not have permission to perform action(s)
  'Microsoft.ManagedIdentity/userAssignedIdentities/assign/action' on the linked
  scope(s)
  '/subscriptions/<sub-id>/resourcegroups/<mi-rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<mi-name>'

This message clearly indicated that although the MI had permission to modify the App Gateway, it lacked permission to assign itself or interact with its own identity across resource group boundaries.


✅ The Fix

To resolve the issue, I did the following:

  1. Navigate to the Managed Identity:

    • Found the User Assigned Managed Identity used by the Ingress controller.
  2. Add Role Assignment:

    • Go to Access Control (IAM) for the MI.

    • Click + Add → Add role assignment.

  3. Assign the Correct Role:

    • Role: Managed Identity Operator

    • Assign access to: User, group, or service principal

    • Select member: Paste the Object ID of the AKS Ingress identity.

  4. Review + Assign:

    • Confirmed and completed the role assignment.

🎉 Result

Once this role was assigned, the Ingress was able to:

  • Communicate with the App Gateway successfully.

  • Apply backend pool updates.

  • Sync configuration changes as expected.

The issue was resolved, and traffic began flowing through the Application Gateway to the AKS workloads smoothly.


🧠 Key Takeaways

  • When using AGIC with a User Assigned Managed Identity, always verify cross-resource permissions.

  • Managed Identity Operator is required if the MI resides in a different resource group than the App Gateway.

  • Error messages like LinkedAuthorizationFailed are a clear indicator of missing cross-scope permissions.


If you're facing similar issues integrating AKS with App Gateway via AGIC, double-check role assignments across both resource scopes and identity objects. It can save you hours of troubleshooting.

0
Subscribe to my newsletter

Read articles from sneh srivastava directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

sneh srivastava
sneh srivastava