How to get the principal id of the current principal executing the azure bicep deployment?

[dazinator]

My bicep template makes use of deployment script resource

resource deploymentScript 'Microsoft.Resources/deploymentScripts@2020-10-01' = {

One of the properties you have to supply is an identity.

identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${userAssignedIdentityId}': {}
    }
  }

At the moment, in my bicep deployment itself I have to create this identity, so I can then assign it to the deployment script.

However I don't think this should be necessary. Given my bicep deployment is executing as an authenticated az identity, I am wondering how get access to the current principal executing the deployment so I can assign that identity and re-use it. Similar to how you can use subscription() to get hold of the current subscription info for example.

Is this possible?

[jeskew]

There's no function to get the principal ID of the user executing the deployment (though it is planned).

For your specific use case, though, such a function wouldn't help. The identity property of a deployment script can only specify a user-assigned managed service identity, however, so even if you had the ID of the user executing the deployment, you wouldn't be able to use that in the identity property of the deploymentScripts resource. You could always omit the identity property and then log in within the script itself using Connect-AzAccount (for a powershell script) or az login (for a CLI script), passing login credentials to the script as secure environment variables. There's some more guidance on how/when to do this at https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/deployment-script-template#configure-the-minimum-permissions

[dazinator]

@brwilkinson
I have not used runCommands as part of any workaround as the deployment scripts I run are pre existence of any VM's. However I am happy that the question has been answered. I will mark as such, thank you.

[brwilkinson]

Okay sure, thank you @dazinator

DeploymentScripts are a workaround/bandaid solution to solve the last mile problem or gaps in ARM native capabilities.

As we get more extension support in Bicep or as Resource Providers add native functionality, hopefully over time the need for using them diminishes. A deploymentScript should always be a last option, so if you can consider doing things another way where possible.

[brwilkinson]

adding this link for interest as well:

• Reference logged in account in bicep template #9092 (reply in thread)

[LennDG]

Hi @brwilkinson,

Our use case is managing an App Registration with a Service Principal that is authenticated using a certificate. The certificate is available in a keyvault. We want to use az login in the deploymentScript but so far I have found no way of passing the certificate from the keyvault into the container.

Since this is a migration of existing Terraform IaC we are not opposed to rethinking our infrastructure somewhat. Would creating a Managed Identity with the same permissions be a way forward? I guess we will in every case still need to use deploymentScript to interact with Azure AD.

[brwilkinson]

@LennDG you should switch out for a "User Assigned Managed Identity" Then you don't need a certificate or a secret.

[dazinator]

Just adding another case for where I wanted to do this.

When the bicep deployment runs, it creates a keyVault. The KeyVault uses access policies. I want it to create an access policy to give its own principal (object id) access to secrets.

[brwilkinson]

The only workaround is to use a deployment script at this time.

[brwilkinson]

Also, given the service principal deploying needs some permission to deploy, to create the keyvault. You can move to RBAC model, which is recommended. Then assign access in the same process where the SP permissions were assigned. KV access can be assigned at any scope, including on RG.

[cataggar]

The workaround I just used was to get it from the Azure CLI and pass it in as a param. Here is a Nushell script:

let principalId = az rest --method GET --uri https://graph.microsoft.com/v1.0/me | from json | get id
az deployment group create -g mygroup -f my.bicep -p $"principalId=($principalId)"

[seesharprun]

@jeskew, is there any update on when the "function to get the principal ID of the user executing the deployment" is planned?

My use case is that I write a lot of templates that deploy database or data services and I want my Bicep templates to have local keys disabled by default. In a perfect world, I could call a function in the Bicep template to get the metadata for the executing identity (human, managed, or etc.) and then assign the least permissive roles using RBAC.

Today, I have two workarounds:

1. Run an Azure CLI or Azure PowerShell script to get the current signed-in user and then pass that as a secure parameter to Bicep
2. Wrap the Bicep script in an Azure Developer CLI template. AZD passes in the current user as a parameter by default

These work for now, but this just adds complexity when all I really want is for someone to deploy a Bicep template as a one-liner and not need the prerequisite steps.

Thanks!

[Welasco]

I just had a use case where the ObjectID would be important as well.
The use case it's to create an Azure SQL and it requires SID (aka ObjectID) to set the default admin of a Server. It's a required value.

[rdf6]

+1 for including ObjectID. I need this for using Bicep to set permissions on storage accounts used by a Synapse workspace.

[johndowns]

The object ID is also important for the scenario where you create an Entra group by using the new Graph extensibility, and then assign the current user to that group.

[seesharprun]

@seesharprun we are planning on picking this up soon. An optimistic ETA would be the end of October - it requires implementing in the backend service, waiting for global rollout, and then implementing in Bicep.

To scope it down, we just plan to expose 2 properties - clientId and tenantId. Would that fit your goals?

Yes, that would work with Azure Developer CLI.

[NanoBob]

I also encountered a use case for this, where we would need the object ID. Specifically for allowing the service principal that is running a deployment to be given permission to write to a blob storage container, for a later step in that same deployment.