Skip to content

Managed identities and storage account keys for a self-hosted deployment

When you deploy BI Pixie on Azure, its function apps sign in to storage and Event Hubs with connection strings that carry account keys. Some security teams require that applications sign in with their own Microsoft Entra identity instead, and that storage account keys are turned off. The roles template on this page is the first step toward that. It is optional, and BI Pixie works the same without it.

What the template does

The template gives the managed identity of each BI Pixie function app the Azure roles it needs to work without keys. It changes nothing else: the apps keep their connection strings, so running it on its own is safe and viewers notice nothing. Running it a second time changes nothing either.

  • The function app that receives Pixie events gets Storage Blob Data Owner on its storage account and Azure Event Hubs Data Sender on the event hub.
  • The function app that processes events and runs the collectors gets Storage Blob Data Owner and Storage Queue Data Contributor on its storage account, and Azure Event Hubs Data Receiver on the event hub.

The BI Pixie installation itself grants no roles. Azure reports a role assignment as complete several minutes before it takes effect, while a new function app uses its storage at once, so the roles are a separate step you take after the installation.

Before you start

  • BI Pixie is installed from version 1.1.0 of the deployment template or later, on the Flex Consumption plan, with two function apps and new storage accounts. The Elastic Premium plan and installations with a single function app still need account keys.
  • The person who deploys the template can assign roles in the managed resource group, for example as an Owner or Role Based Access Control Administrator. Your organization's Azure administrator may need to deploy it.
  • A managed application can lock its managed resource group. If the lock covers role assignments, Azure refuses the deployment and nothing is changed.

Deploy the template

Deploy the template after the installation has finished, into the managed resource group of your BI Pixie installation, where the function apps, storage accounts and Event Hubs namespace are.

Deploy to Azure

The template is also available to download as managedIdentityRoles-1.7.0.json, published with release 1.7.0, if you prefer to deploy it with the Azure CLI or PowerShell.

Parameters

Every name is one you chose when you installed BI Pixie, and you can find each of them in the managed resource group.

  • External App Name: the function app that receives Pixie events from your reports.
  • Internal App Name: the function app that processes events from Event Hubs and runs the collectors.
  • Internal Storage Account Name: the storage account of the internal function app, which also holds the bipixielake container.
  • External Storage Account Name: the storage account of the external function app. When both apps share one storage account, leave the default, which is the internal storage account.
  • Event Hub Namespace Name: the Event Hubs namespace that carries Pixie events.
  • Event Hub Name: the event hub inside that namespace. The default is bipixie-hub.

After the roles take effect

Allow about 10 minutes for the roles to take effect. The function apps can then switch from their connection strings to their managed identities. BI Pixie support provides the use-managed-identity.ps1 script for this step. It only reports what it would change until you run it with -Mode Apply, and it can deploy this template for you as its first step.

Optional last step: turn off storage account keys

Once no function app uses a key, you can turn the storage account keys off. Do this only after the BI Pixie Dashboard connects to storage with the OAuth2 (Organizational account) authentication method, as described in Set up the dashboard, and the person who connects it has the Storage Blob Data Reader role. A Shared Access Signature (SAS) stops working when the keys are off, so a dashboard that still refreshes with a SAS fails.

The same script turns the keys off when you run it with -Mode Apply -DisableAccountKeys -DashboardUsesOrganizationalAccount. It never turns them off unless you ask it to.