Azure credentials store an Azure service principal used to provision and manage Azure Kubernetes Service (AKS). Ankra authenticates with the client-credentials grant against Microsoft Entra ID and reads the subscription’s locations, Kubernetes versions, VM SKUs, quota and virtual networks to build the catalogue, then creates and operates AKS clusters in the resource groups it owns or adopts.
Least-privilege roles
Do not grant Contributor on the whole subscription. Scope the service principal to what Ankra does:
Grant Network Contributor on the resource group of the virtual network too when the subnet lives elsewhere. If you would rather not grant resource-group creation at the subscription, create the group yourself and name it at cluster creation (aks.resource_group); Ankra adopts it and never deletes it.
The Azure Kubernetes Service Contributor Role lets the principal retrieve the cluster admin kubeconfig, which Ankra needs to install its agent. Scope it to the resource groups Ankra manages, not the subscription.
Creating an Azure credential
Create the service principal
Note the appId (client ID), password (client secret) and tenant. The secret is shown once - store it in a secret manager, not in a shell history or a ticket. Assign the roles
Repeat the resource-group assignments for every group Ankra will manage. Store it in Ankra
The CLI never accepts the secret as a flag: set AZURE_CLIENT_SECRET for automation, or let the command prompt for it. Rotating the secret
Create a new secret on the application in Microsoft Entra ID, update the Ankra credential, then delete the old secret. Ankra reads the credential from its vault on every provider call, so a rotation takes effect immediately.
