Why are Enterprise Application registrations and Service principals’ creation excluded from IaC?

When we create an Azure App Registration, it results in the creation of both an Application Object and a Service Principal Object. The application object is the representation of the application in the home tenant and acts as a template or blueprint for creating service principals. It contains information about how the application can issue tokens, the resources it can access and the actions it can perform. One can configure API permissions, client secrets, branding, and App roles within this object definition.

A service principal aka Enterprise Application is a concrete instance of the application object within a specific tenant. It represents the application’s identity and comes with a unique object identifier that can be used for non-interactive automations. Each tenant where the application is used will have its own service principal. Most role-based access control assignments for the application are made using this object identifier.

It is possible to register the application using IaC but there are several drawbacks due to which they are not popular. For example, there are special permissions needed for the identity used with the pipeline to deploy such a registration in the Azure Entra aka Active Directory. Such permissions are usually difficult to distribute and must remain within the exclusive control of a centralized entity within the organization which is usually named the Identity and Access Management team. When the permissions are not sufficient, the idempotency of the resource creation and deletion is lost. At this point, the syntax and semantics of app registration appear to be broken and for this reason, it is difficult for anyone to create application registrations from code deploying to their subscriptions. All such registrations will end up in the same global active directory.

Another reason is that the provider registrations and the Active directory must remain up to date otherwise version discrepancies affect the IaC. Since the resource is global and not specific to the azure subscription-resource-group-and-resource tri-level hierarchy, the provider can change the syntax and semantics for the global entity that do not get captured with the IaC that once worked and does not later. For this reason, it is important that azure Active Directory resources not be treated the same as resources that instantiate services from Azure’s service portfolio

Previous article: https://1drv.ms/w/s!Ashlm-Nw-wnWhPVXO5Lemyhk5z34HA?e=8e2jVb