As reported in IcM 294491919, even though az ad sp create-for-rbac has retry logic to create service principal after the application creation replication/propagation is done:
AAD has a very restrictive approach towards onboarding any team on RwcToken.
Even if we use RwcToken in az ad sp create-for-rbac, it is difficult to apply RwcToken to separate command executions like az ad app create and az ad sp create. Azure CLI will have to save the RwcToken to a local file (because each execution is a separate Python process). How to save this token securely needs to be decided.
Alternative solutions
Increase _RETRY_TIMES to higher value or use exponential backoff in order to increase the max totally retry time (currently 36*5s=180s).
yonzhan
commented
2 years ago
Symptom
As reported in IcM 294491919, even though
az ad sp create-for-rbachas retry logic to create service principal after the application creation replication/propagation is done:https://github.com/Azure/azure-cli/blob/f8ea47cd3330d1125b322f6c54e3da947596c1c7/src/azure-cli/azure/cli/command_modules/role/custom.py#L1451-L1469
It is still be possible that after
_RETRY_TIMES(whose value is36), the replication is not complete, leading to service principal creation failure:Possible solution
AAD has a mechanism called Read Write Consistency (RWC) Token to solve this:
Problems
az ad sp create-for-rbac, it is difficult to apply RwcToken to separate command executions likeaz ad app createandaz ad sp create. Azure CLI will have to save the RwcToken to a local file (because each execution is a separate Python process). How to save this token securely needs to be decided.Alternative solutions
Increase
_RETRY_TIMESto higher value or use exponential backoff in order to increase the max totally retry time (currently 36*5s=180s).