Most people who are professionally working with any of the cloud providers use some kind of infrastructure-as-code solution.
For Microsoft Azure, I’m mostly working with ARM- or Bicep templates to describe the resources necessary. While I’ve written ARM templates for years now, I’m enjoying creating Bicep templates a bit more due to the tooling it offers.

There is at least one downside to using these solutions, and that’s the fact most operations are happening on the Azure control plane. Often times this is good enough, as you only need to deploy some resources, specify some values to the resources, and be done with it. However, there are cases where you also need to invoke some actions which require the creation of data, identities, or trigger some kind of endpoint.
To facilitate this need, there’s a special kind of resource in Azure called deploymentScripts.

What are deploymentScripts?

As it’s mentioned in the docs, these scripts can be used to perform lots of custom actions, like:

• Add users to a directory.
• Perform data plane operations, for example, copy blobs or seed database.
• Look up and validate a license key.
• Create a self-signed certificate.
• Create an object in Azure AD.
• Look up IP Address blocks from custom system.

The benefits of deployment script:

Read more →

When you need to work with service principals in your Azure environment, you are probably creating them via some script using the az ad sp command.

This works quite well, but these are created with your account. The account you used to log in with the Azure CLI. The same goes when using PowerShell, it’s always running in the context you used to log in. Most of the time your personal or environment administrator account.

There are a several reasons why you probably don’t want or need, these privileges assigned to your account. But you probably still want to create new service principals & assign them roles to specific services or applications. This is where an ‘administrator’ (for lack of a better name) service principal might come in to help.
By having a service principal with enough permissions on a subscription, management group, or tenant, you can get rid of these permissions on your account.

First, you need to create the ‘administrator’ service principal. I’m using the built-in Owner role for this, but you would be wise to use a custom role with just enough permissions to create users/service principals.

$createdAdminServicePrincipal = az ad sp create-for-rbac --name $administratorServicePrincipalName --role Owner --scopes /subscriptions/$subscriptionId | ConvertFrom-Json
$createdAdminServicePrincipalAppId = $createdAdminServicePrincipal.appId
$createdAdminServicePrincipalPassword = $createdAdminServicePrincipal.password

The appId and password are used to log in later on.