Review managed identity use in AKS

Description

When AKS uses a service principal to access Azure resources, its credentials require protection and rotation. Managed identities let Azure manage credentials, reducing that burden, but granting only the required permissions remains necessary.

Potential impact

Exposed or unrotated service-principal secrets can affect resource access and service operation.
Excessive cluster or kubelet roles can increase impact even when managed identities are used.

Remediation

Configure an identity block with SystemAssigned or an approved UserAssigned identity for the use case. Minimize Azure RBAC roles for cluster and kubelet identities separately.
When migrating from a service principal, review resource permissions and the node-pool transition procedure. Verify operations with the new identities before retiring unused credentials.

Examples

These excerpts compare identity settings. The first omits both managed identity and service principal and is not a complete deployment configuration; AzureRM requires one of them.

Before

hcl

resource "azurerm_kubernetes_cluster" "example" {
  name                = "example-aks"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  dns_prefix          = "exampleaks"

  default_node_pool {
    name       = "default"
    node_count = 1
    vm_size    = "Standard_D2_v2"
  }
}

After

hcl

resource "azurerm_kubernetes_cluster" "example" {
  name                = "example-aks"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  dns_prefix          = "exampleaks"

  default_node_pool {
    name       = "default"
    node_count = 1
    vm_size    = "Standard_D2_v2"
  }

  identity {
    type = "SystemAssigned"
  }
}

Explanation:

Before: The cluster’s authentication identity is not defined in this excerpt.
After: A system-assigned managed identity is selected. Grant required resource roles separately.