Available from 1.5 release
Goal: To enable user to use a separate service principal (aad-pod-identity admin service principal) other than the cluster service principal and to move away from
Users now have the option to deploy aad-pod-identity with a separate service principal which is together with its secret and other configurations stored in a Kubernetes secret object.
The permission of the admin service principal needs to be ‘Contributor’ role over the scope of node resource group starting with “MC_”.
Create a new service principal with the permission:
az ad sp create-for-rbac -n "<sp_name>" --role "Contributor" --scopes "/subscriptions/<subscription-id>/resourceGroups/<MC_node_resource_group>"
tenantfrom the resulting json, which will be used in creating the admin secret.
Or assign the permission for an existing service principal:
az role assignment create --role "Contributor" --assignee <sp_id> --scope "/subscriptions/<subscription-id>/resourceGroups/<MC_node_resource_group>"
For any subsequent user assigned managed identity that’s intended for a pod, it’s also required to grant the service principal ‘Managed Identity Operator’ permission (also stated here):
az role assignment create --role "Managed Identity Operator" --assignee <sp_id> --scope <resource id of the managed identity>
aadpodidentity-admin-secret contains the following fields:
AzureGermanCloud(values taken from here).
standardfor normal virtual machine nodes, and
vmssfor cluster deployed with a virtual machine scale set.
echo -n 'secret-content' | base64to create a base64 encoded string.
Fill out those secret values in the /deploy/infra/noazurejson/deployment.yaml or /deploy/infra/noazurejson/deployment-rbac.yaml before executing
kubectl create -f ./deploy/infra/noazurejson/deployment.yaml or
kubectl create -f ./deploy/infra/noazurejson/deployment-rbac.yaml.
Note that if not use the above yaml’s,
aadpodidentity-admin-secretmust be created before deploying
micmust reference the secret as shown in the yaml’s.
The secret will be injected as an environment variable into
mic upon pod creation and cannot be updated during the lifecycle of
mic. However, redeploying
mic should pick up the updated service principal’s information should they change.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.