Skip to content

Bring your own managed identity

When you finish, the cluster nodes and the provisioner VM run as user-assigned managed identities you created, and each identity holds its roles before the first apply.

Before you start

1. Create the deployment resource group

az group create --name rg-qumulo-prod --location eastus2 --query properties.provisioningState -o tsv

Use the resource_group_name and location from your configuration. The command prints Succeeded.

2. Create the identities

az identity create --resource-group <identity-resource-group> --name qumulo-cluster --query "{id:id, principalId:principalId}"
az identity create --resource-group <identity-resource-group> --name qumulo-provisioner --query "{id:id, principalId:principalId}"

Each command prints an id for your configuration and a principalId for the role grants. One identity can serve both roles instead, as long as it receives every grant in step 3.

3. Grant the roles

SCOPE=/subscriptions/<subscription-id>/resourceGroups/rg-qumulo-prod

for role in "Key Vault Secrets User" "Storage Blob Data Contributor" "Reader"
do
  az role assignment create --assignee-object-id <cluster-principal-id> \
    --assignee-principal-type ServicePrincipal --role "$role" --scope "$SCOPE"
done

for role in "Key Vault Secrets User" "App Configuration Data Owner" "Virtual Machine Contributor"
do
  az role assignment create --assignee-object-id <provisioner-principal-id> \
    --assignee-principal-type ServicePrincipal --role "$role" --scope "$SCOPE"
done

az role assignment list --assignee <cluster-principal-id> --scope "$SCOPE" --query "[].roleDefinitionName" -o tsv

The last command prints Key Vault Secrets User, Storage Blob Data Contributor, and Reader, in any order. The grants sit on the resource group because the Key Vault, App Configuration store, and storage accounts do not exist until the apply creates them, and they inherit its role assignments.

If your configuration sets persistent_storage_resource_group, grant the cluster identity Storage Blob Data Contributor on that resource group too.

4. Add the identities to the configuration

Add these lines to the qumulo_filesystem_azure block, using the id values from step 2.

cluster_node_identity_id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-identities/providers/Microsoft.ManagedIdentity/userAssignedIdentities/qumulo-cluster"     # <-- Replace with your node identity ID
provisioner_identity_id  = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-identities/providers/Microsoft.ManagedIdentity/userAssignedIdentities/qumulo-provisioner" # <-- Replace with your provisioner identity ID

terraform plan shows both attributes set to your identity IDs.

Warning

cluster_node_identity_id and provisioner_identity_id cannot change after the cluster exists. A changed value is rejected at plan time. Add them before the first apply or not at all.

5. Apply

terraform apply

The apply ends with Apply complete! Resources: 1 added, 0 changed, 0 destroyed. The provider grants no roles of its own to either identity.

Next

The Azure permissions reference lists both identities' roles in one place. If the apply fails, see Troubleshoot an Azure deployment.