Using a Managed Identity

1. Start Locally

Firstly, we need to launch Locally which we can do from a terminal by running:

Once Locally has started, the Locally Dashboard will open automatically:

2. Create a Resource Group

Next we can create the Resource Group to hold everything:

There's two things to note here:

1. The Azure CLI supports Automatic Configuration, meaning that it can automatically be configured to work against Locally just by prefixing commands with locally run.
2. Locally intentionally uses a different set of locations to Azure as a safety precaution, so that you can be confident you're deploying against Locally rather than regular Azure. You can also configure Locally to use the Azure locations too, but you'll want to be extra sure that you're prefixing commands with locally run when you do.

3. Create the Managed Identity

A user-assigned identity is a resource in its own right, so it can be created before anything uses it:

{
  "note": "some fields skipped for brevity",

  "clientId": "e17ff4a6-8106-4eac-a9d7-160615f36e7c",
  "id": "/subscriptions/307d8f52-9719-460e-9f85-aa408e28ee55/resourceGroups/sample-identity/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sample-func-identity",
  "location": "berlin",
  "name": "sample-func-identity",
  "principalId": "6f0b6de2-55f9-4c20-a184-1428be832fd9",
  "resourceGroup": "sample-identity",
  "tenantId": "59e01520-e049-4dfa-8a7d-1a847fc07763",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

The principalId is the identity's object in the directory, which is what roles get assigned to. We'll need it, and the identity's resource ID, in a few places - so let's keep both in variables:

We can see the Managed Identity in the Locally Dashboard too:

4. Create a Key Vault and a secret

Next, a Key Vault that uses Azure RBAC for access, rather than access policies:

{
  "note": "some fields skipped for brevity",

  "location": "berlin",
  "name": "sampleidkv1",
  "properties": {
    "enableRbacAuthorization": true,
    "provisioningState": "Succeeded",
    "vaultUri": "https://sampleidkv1.vault.locally:5661/"
  },
  "resourceGroup": "sample-identity",
  "type": "Microsoft.KeyVault/vaults"
}

And a secret for the app to read:

The Key Vault guide covers the vault's data plane in more detail.

5. Give the identity access to the vault

The identity can't read anything yet. Assigning it the Key Vault Secrets User role, scoped to just this vault, lets it read secret values and nothing else:

{
  "note": "some fields skipped for brevity",

  "principalId": "6f0b6de2-55f9-4c20-a184-1428be832fd9",
  "principalType": "ServicePrincipal",
  "roleDefinitionId": "/subscriptions/307d8f52-9719-460e-9f85-aa408e28ee55/providers/Microsoft.Authorization/roleDefinitions/4633458b-17de-408a-b874-0445c86b69e6",
  "scope": "/subscriptions/307d8f52-9719-460e-9f85-aa408e28ee55/resourceGroups/sample-identity/providers/Microsoft.KeyVault/vaults/sampleidkv1",
  "type": "Microsoft.Authorization/roleAssignments"
}

6. Create a Function App that uses the identity

A Function App keeps its state in a Storage Account, so that comes first:

Then the Function App itself:

{
  "note": "some fields skipped for brevity",

  "defaultHostName": "sampleidfuncapp1.furnace.locally:5663",
  "kind": "functionapp",
  "location": "berlin",
  "name": "sampleidfuncapp1",
  "resourceGroup": "sample-identity",
  "state": "Running",
  "type": "Microsoft.Web/sites"
}

Now we can assign the identity to the app:

{
  "note": "some fields skipped for brevity",

  "type": "UserAssigned",
  "userAssignedIdentities": {
    "/subscriptions/307d8f52-9719-460e-9f85-aa408e28ee55/resourceGroups/sample-identity/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sample-func-identity": {
      "clientId": "e17ff4a6-8106-4eac-a9d7-160615f36e7c",
      "principalId": "6f0b6de2-55f9-4c20-a184-1428be832fd9"
    }
  }
}

An app can have several identities, so we also need to tell it which one to use for Key Vault references. Without this it would use a system-assigned identity, which this app doesn't have:

"/subscriptions/307d8f52-9719-460e-9f85-aa408e28ee55/resourceGroups/sample-identity/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sample-func-identity"

7. Reference the secret from an app setting

Rather than putting the password in the app's settings, we put a Key Vault reference there instead. When the app starts, the reference is swapped for the secret's value, read as the app's identity:

To see it working we need a function that reads the setting. A Function App package is a zip of your project's files, so we can build a small one by hand. First the host configuration and package.json:

Then a function called secret, with an anonymous HTTP trigger:

{
  "bindings": [
    { "authLevel": "anonymous", "type": "httpTrigger", "direction": "in", "name": "req", "methods": ["get"] },
    { "type": "http", "direction": "out", "name": "res" }
  ]
}

And a handler that returns the setting, so we can see what the app was given:

module.exports = async function (context, req) {
  context.res = { body: process.env.DATABASE_PASSWORD };
};

Then zip it up:

8. Deploy and read the secret

We can deploy the package with the Azure CLI's zip deploy:

{
  "active": true,
  "complete": true,
  "id": "18fab220-d7f4-40fd-8955-162bc125626a",
  "log_url": "https://sampleidfuncapp1-scm.furnace.locally:5663/api/deployments/18fab220-d7f4-40fd-8955-162bc125626a/log",
  "received_time": "2026-10-05T09:22:46Z",
  "status": 4,
  "status_text": "",
  "url": "https://sampleidfuncapp1-scm.furnace.locally:5663/api/deployments/18fab220-d7f4-40fd-8955-162bc125626a"
}

And then call the function:

HTTP 200 OK
X-Ms-Request-Id: 6d55c0c9-4fa7-469f-b4f5-0338cbe538f7
Date: Thu, 01 Oct 2026 09:22:51 GMT
Content-Length: 28
Content-Type: text/plain; charset=utf-8
X-Ms-Correlation-Id: 56a7540c-30e6-4c39-8f0c-6c350dc49ced

correct-horse-battery-staple

That's the secret from the vault. The app never held a password or a connection string - it was given the value because its identity has the role on the vault.

To prove it's the role doing the work, we can take it away again:

Redeploy, so the app starts up again:

And call it again:

HTTP 200 OK
X-Ms-Correlation-Id: ee9c75b4-905e-4fed-833d-d2b9bbe00a55
X-Ms-Request-Id: 4fef8c43-a2fe-4274-a429-45ddbd0cada2
Date: Thu, 01 Oct 2026 09:24:01 GMT
Content-Length: 71
Content-Type: text/plain; charset=utf-8

@Microsoft.KeyVault(VaultName=sampleidkv1;SecretName=database-password)

This time the identity isn't allowed to read the secret, so the app gets the reference itself rather than the value - which is what Azure does too.

9. Tidy up

Finally, we can tidy up. To remove the Resource Group and everything within it:

As in Azure, deleting a Key Vault soft-deletes it rather than removing it outright, so the name sampleidkv1 stays reserved. To free it up for next time, purge it:

There's nothing billable to clean up, since everything ran on your machine, but it's still worth checking your teardown scripts work here before you run them against Azure.

Doing this with other tooling

Whilst this guide used the Azure CLI, the same setup works through any of the tooling that Locally supports - a Microsoft.ManagedIdentity/userAssignedIdentities resource, a role assignment and a Function App with keyVaultReferenceIdentity set provision in the same way with HashiCorp Terraform or OpenTofu, Pulumi, Bicep or an ARM Template.

For more on how Function Apps run on your machine, see the Function App guide and the Function App Emulator.

Next steps

Role Assignments covers how Locally enforces the roles you give an identity. To go further with the vault, see Key Vault Keys and Certificates.

Should you encounter any issues, please take a look at the troubleshooting section.