AKS Fleet Manager is surprisingly more about centralized identity and RBAC management than it is about actual cluster provisioning or orchestrating workloads across them.
Let’s see it in action. Imagine you have two AKS clusters, cluster-east in the East US region and cluster-west in the West US region. You want to grant a specific Azure AD group, DevOpsTeam, read-only access to both clusters.
First, you define your "fleet" in Azure, which is essentially just a resource group that will contain your fleet-managed clusters.
az group create --name fleet-resource-group --location eastus
Then, you register your existing AKS clusters with this fleet. This doesn’t move the clusters, it just registers them for centralized management.
az fleet.aks register --fleet-name my-fleet --resource-group fleet-resource-group --aks-resource-id "/subscriptions/YOUR_SUB_ID/resourceGroups/eastus-rg/providers/Microsoft.ContainerService/managedClusters/cluster-east"
az fleet.aks register --fleet-name my-fleet --resource-group fleet-resource-group --aks-resource-id "/subscriptions/YOUR_SUB_ID/resourceGroups/westus-rg/providers/Microsoft.ContainerService/managedClusters/cluster-west"
Now, the magic. You create a FleetRoleAssignment. This is where you define what permissions the DevOpsTeam group gets, and crucially, which clusters within the fleet it applies to.
az fleet.role assignment create --fleet-name my-fleet \
--name devops-readonly-assignment \
--role reader \
--principal-type group \
--principal-id "GROUP_OBJECT_ID_FOR_DEVOPS_TEAM" \
--scope "/subscriptions/YOUR_SUB_ID/resourceGroups/fleet-resource-group/providers/Microsoft.Fleet/fleets/my-fleet"
Notice the --scope. By applying the role assignment at the fleet level, you’re telling Azure that this role (reader) assigned to this principal (DevOpsTeam group) should be propagated to all clusters registered under my-fleet. Azure then automatically translates this into individual Microsoft.Authorization/roleAssignments on each of the member AKS clusters. If you wanted to restrict it to only a subset of clusters, you’d use --scope with a more granular path pointing to a specific cluster resource ID within the fleet.
The core problem Fleet Manager solves is the operational overhead of managing RBAC and other policies across many Kubernetes clusters. Without it, you’d be logging into each cluster individually, or scripting az aks get-credentials followed by kubectl commands to apply role bindings or Azure RBAC assignments. This becomes a nightmare as your cluster count grows, and ensuring consistency is nearly impossible. Fleet Manager centralizes these declarations. You declare what you want, and Azure handles the distribution.
Internally, when you create a FleetRoleAssignment or a FleetPolicyAssignment (for Azure Policy), Fleet Manager acts as a control plane. It watches for changes to these fleet-level resources. When it detects a new assignment, it queries the registered member clusters. For each cluster, it then makes a call to the Azure Resource Manager API to create the equivalent Azure RBAC role assignment or Azure Policy assignment directly on that cluster’s Azure resource. This is why the assignments appear as standard Azure RBAC roles within the AKS cluster’s resource blade in the Azure portal, even though you declared them at the fleet level.
A common misconception is that Fleet Manager provisions or manages the lifecycle of the AKS clusters themselves. It does not. It’s purely a management overlay for existing AKS clusters. You still create, upgrade, and delete your AKS clusters independently. Fleet Manager simply allows you to apply consistent management policies to them once they are registered.
The most surprising part for many is how Azure RBAC and Kubernetes RBAC can coexist and be managed through this single fleet-level construct. When you assign a role like Azure Kubernetes Service Cluster User Role at the fleet level, Azure Fleet Manager doesn’t just grant Azure IAM permissions to the AKS cluster resource. It also often translates this into Kubernetes ClusterRoleBinding resources within each cluster, mapping the Azure AD principal to a Kubernetes Subject with the appropriate permissions. This seamless bridging of cloud IAM and in-cluster authorization is a key, often understated, capability.
The next logical step after mastering fleet-wide RBAC is to explore fleet-wide Azure Policy for Kubernetes.