Azure permissions¶

The deploying identity is the Azure identity that runs terraform apply for qumulo_filesystem_azure. This page lists what that identity, and the managed identities the cluster runs as, must be allowed to do.

Deploying identity¶

Built-in roles	Covers
Owner	Every action on this page except the Key Vault Secrets Officer row, when granted on the subscription. Owner carries no Key Vault data actions, so that row still applies.
Contributor plus User Access Administrator	Every action on this page except the Key Vault Secrets Officer row, when granted on the subscription. Neither role carries Key Vault data actions, so that row still applies.

Contributor alone cannot write role assignments or management locks, so it is not enough to deploy a cluster. A grant on a resource group covers only the actions the table below scopes to that resource group.

Specific actions¶

Action	Scope	When it is needed
`Microsoft.Authorization/roleAssignments/write`	The deployment resource group	Every cluster, to grant roles to the provisioner VM and the cluster nodes. Not needed when both `cluster_node_identity_id` and `provisioner_identity_id` are set.
`Microsoft.AppConfiguration/configurationStores/write`	The deployment resource group	Every cluster, to create the App Configuration store that carries provisioning status
`Microsoft.KeyVault/vaults/write`	The deployment resource group	Every cluster, to create the Key Vault for cluster secrets. The permission check also asks for it when `key_vault_id` is set.
`Microsoft.Authorization/locks/write`, `Microsoft.Authorization/locks/delete`	The deployment resource group	When `deletion_protection = true`
`Microsoft.Network/virtualNetworks/checkIpAddressAvailability/read`	The virtual network, or any parent scope	When `floating_ip_count` is greater than 0, including clusters that set their own identities. Reader, Network Contributor, and Contributor carry it. A grant of only `subnets/read` plus `subnets/join/action` does not.
`Microsoft.Authorization/roleDefinitions/write`	The subscription	When the provider creates the node identity, to define the per-deployment `Qumulo Join Subnet` role that attaches floating IPs. Without it, the provider logs a warning and floating IP attachment can fail.
Key Vault Secrets Officer (data actions `Microsoft.KeyVault/vaults/secrets/setSecret/action`, `Microsoft.KeyVault/vaults/secrets/update/action`, `Microsoft.KeyVault/vaults/secrets/delete`, and `Microsoft.KeyVault/vaults/secrets/recover/action`)	The deployment resource group, or the vault itself when `key_vault_id` is set	Every cluster, to write the `<deployment_unique_name>-provisioner-secrets` secret before each provisioner run and to disable the version it wrote afterward. The provider deletes the secret on destroy only when you bring your own vault, since it deletes a provider-created vault whole. On a vault supplied through `key_vault_id`, the first run after a destroy recovers the soft-deleted secret, which needs `recover/action`. The provider writes through the data plane. Pair the role with `Microsoft.Authorization/roleAssignments/delete` at the same scope for the per-run assignment cleanup in the next row.
`Microsoft.Authorization/roleAssignments/delete`	The deployment resource group, or the vault itself when `key_vault_id` is set	Every cluster, to remove the provisioner VM's read access to that secret after each run. For a vault supplied through `key_vault_id`, destroy also uses it to remove any leftover assignment on the secret.
`Microsoft.Compute/capacityReservationGroups/deploy/action`	The capacity reservation group	When `capacity_reservation_group_id` is set, to create node VMs in the group
`Microsoft.Storage/storageAccounts/write`, `Microsoft.Storage/storageAccounts/listKeys/action`, `Microsoft.Storage/storageAccounts/blobServices/containers/write`	The storage resource group	Every operation that builds nodes, when `air_gapped = true` and `package_url` is not set. The provider copies the Qumulo Core packages from Nexus into a staging storage account named after `deployment_unique_name` with hyphens removed and `stg` appended, using the account key, and gives each node a read-only download URL that expires after one hour

At the start of create, the provider checks the first five rows and names any action that is missing. It skips that check when cluster_node_identity_id or provisioner_identity_id is set.

Note

The staging storage account accepts requests from any network, so the Terraform host can fill it from wherever it runs; reading a package needs its signed URL. Where an Azure Policy forbids storage accounts with public network access, set package_url to a Qumulo Core package the cluster subnet can reach, and the provider creates no staging account.

Cluster node identity¶

These roles apply to a user-assigned identity supplied through cluster_node_identity_id. The provider grants nothing to it.

Role	Scope
Key Vault Secrets User	The deployment resource group
Storage Blob Data Contributor	The deployment resource group, or `persistent_storage_resource_group` when it is set
Reader	The deployment resource group

Provisioner identity¶

These roles apply to a user-assigned identity supplied through provisioner_identity_id. The provider grants nothing to it.

Role	Scope
Key Vault Secrets User	The deployment resource group, or the vault itself when `key_vault_id` is set. The provisioner reads `<deployment_unique_name>-provisioner-secrets` with it.
App Configuration Data Owner	The deployment resource group
Virtual Machine Contributor	The deployment resource group

One identity can serve both attributes when it holds every role from both tables. An identity in another subscription works too, since the provider reads the subscription from the identity's resource ID.

Customer-managed Key Vault¶

A vault supplied through key_vault_id must accept network traffic from the cluster subnet for the life of the cluster. Bring your own Key Vault lists the ways to allow it.

For that vault, the deploying identity needs Key Vault Secrets Officer, or the data-plane equivalent, so it can write and delete <deployment_unique_name>-provisioner-secrets. When provisioner_identity_id is not set, the provisioner VM runs as a system-assigned identity, and the deploying identity also needs Microsoft.Authorization/roleAssignments/write and Microsoft.Authorization/roleAssignments/delete on the vault to grant that identity read on the secret for each run and remove the grant afterward. The provisioner subnet must reach the vault as well, because the provisioner reads that secret from it. Destroy deletes the secret and any role assignment left on it, and leaves the vault in place.

Customer-managed encryption key¶

When key_vault_key_id is set, the cluster's node disks, the provisioner's disk, and every storage account use the key. qumulo_threat_detection_azure and qumulo_neuralsearch_azure appliances stay on platform-managed keys. Microsoft Learn describes the Azure features in Server-side encryption of Azure Disk Storage and Customer-managed keys for Azure Storage encryption.

The provider checks the vault and the key at the start of the apply that creates the cluster, before it creates anything. A failed check names the vault and says what to change. Deploy a production Azure cluster shows how to set the attribute.

The vault must meet these requirements.

It uses Azure role-based access control, not access policies.
Soft delete and purge protection are on. Microsoft Learn explains both in Azure Key Vault soft-delete overview.
It is in the cluster's subscription and region.
If it restricts network access, "Allow trusted Microsoft services to bypass this firewall" is on. The disk encryption set and the storage accounts reach the key as trusted services, so the cluster subnet needs no access to this vault. See Azure Key Vault network security.
The key is enabled and is an RSA or RSA-HSM key of 2048, 3072, or 4096 bits.

The vault's enabledForDiskEncryption setting is not required.

The provider grants the cluster's storage identity Key Vault Crypto Service Encryption User on the vault. It grants the cluster's disk encryption set Key Vault Crypto Service Encryption User and Reader. On the vault, the deploying identity needs these actions.

Action	Scope	When it is needed
`Microsoft.KeyVault/vaults/read`	The vault	When the cluster is created, to check the vault's settings
`Microsoft.KeyVault/vaults/keys/read`	The vault	When the cluster is created, to check the key's type and size and to read its current version
`Microsoft.Authorization/roleAssignments/write`	The vault	When the cluster is created, to grant the disk encryption set and the storage identity access to the key
`Microsoft.Authorization/roleAssignments/read`	The vault	When the cluster is created, to confirm those grants exist before the first resource uses the key. On destroy, to find them again.
`Microsoft.Authorization/roleAssignments/delete`	The vault	On destroy, and when a failed create rolls back, to remove those grants. Without it, the provider logs a warning, visible with `TF_LOG=WARN`, and leaves them in place. Remove them by hand.
`Microsoft.KeyVault/vaults/read`	The subscription	On import, to find the vault by name from the key the disk encryption set uses. Without it, the import fails. Destroy takes the vault from `key_vault_key_id` and needs this action only when state has no key but the cluster's disk encryption set still exists. Without it in that case, destroy logs a warning, visible with `TF_LOG=WARN`, and leaves the grants in place. Remove them by hand.

In the cluster's resource groups, the deploying identity needs these actions.

Action	Scope	When it is needed
`Microsoft.Compute/diskEncryptionSets/write`, `Microsoft.Compute/diskEncryptionSets/delete`	The deployment resource group	When `key_vault_key_id` is set, to create the disk encryption set `<deployment_unique_name>-disk-encryption-set`, keep its tags current, and delete it. Tag updates and destroy act only on a set that carries the `qumulo-deployment` tag the provider applies, or on a set the cluster's disks use
`Microsoft.ManagedIdentity/userAssignedIdentities/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/delete`	The resource group that holds the storage accounts, which is the deployment resource group or `persistent_storage_resource_group`	When `key_vault_key_id` is set, to create the storage identity `<deployment_unique_name>-storage-cmk`, keep its tags current, and delete it. Tag updates and destroy act only on an identity that carries the `qumulo-deployment` tag the provider applies
`Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`	The storage identity	When `key_vault_key_id` is set, to attach the identity to each storage account the provider creates, including the accounts a capacity increase adds
`Microsoft.Compute/diskEncryptionSets/read`, `Microsoft.ManagedIdentity/userAssignedIdentities/read`	The set in the deployment resource group, and the identity in the resource group that holds the storage accounts. On import and updates, the identity is the one the storage accounts' encryption settings name, wherever it lives	Every cluster, to find a disk encryption set and a storage identity on destroy and to confirm nothing is left behind. A cluster with the key also reads both on import, and before every scale-out, scale-down, node replacement, capacity growth, and config update. Without read permission, destroy logs a warning, visible with `TF_LOG=WARN`, and leaves both in place. When a later refresh finds the cluster gone, the check for leftover resources logs a warning, skips the unreadable set or identity, and checks everything else. Remove a set or identity left this way by hand.
`Microsoft.Compute/proximityPlacementGroups/read`, `Microsoft.Compute/proximityPlacementGroups/delete`	The deployment resource group	Clusters adopted from `azure-terraform-cnq`, which creates the proximity placement group `<deployment_unique_name>-qumulo-cluster-ppg` for single-zone clusters. Destroy deletes it after the node VMs. Without read permission, destroy logs a warning, visible with `TF_LOG=WARN`, and leaves it in place, and the check for leftover resources logs a warning, skips it, and checks everything else. Delete it by hand in that case.

Owner, or Contributor plus User Access Administrator, on the subscription carries every action in both tables. For narrower grants, Role Based Access Control Administrator on the vault carries the first five rows of the first table, and Reader on the subscription carries the last. Contributor on the deployment resource group, and on persistent_storage_resource_group when it is set, carries every action in the second table.

After the first apply¶

Rotating the key in your vault needs no apply. Disks and storage accounts follow the latest key version.
key_vault_key_id cannot be added to a cluster created without it. The plan rejects the change, so set the key when you create the cluster.
Scale-out, scale-down, node replacement, capacity growth, and config updates use the same key and the storage identity the cluster's storage accounts already use. They stop before creating any disk, VM, or storage account if the disk encryption set or that identity is missing, if the storage accounts use different identities or none, or if someone pointed the set at another key outside Terraform. Changes to deletion_protection, allow_cidrs, nsg_allow_ingress_icmp, and tags in the same apply are made before that check.
A refresh warns, and never fails, when some disks or storage accounts are not on the key. A legacy cluster that an earlier provider version scaled is the usual cause. Moving a disk onto the key means deallocating the cluster's nodes. A storage account can switch keys without that.
When the cluster's disks use a disk encryption set the provider does not manage, a refresh with no key_vault_key_id declared warns and leaves key_vault_key_id empty. With a key declared, a refresh lists those disks as not using the key.
terraform destroy deletes the disk encryption set and the storage identity <deployment_unique_name>-storage-cmk. It removes only the role assignments that those two principals hold at the vault's own scope, so a grant of yours on the vault or on a resource group above it stays. Destroy and tag updates act only on a set or identity that carries the qumulo-deployment tag the provider applies, and on a set the cluster's disks use, which covers the untagged set of a cluster adopted from the legacy modules. A same-named set or identity that the provider did not create stays in place with its role assignments, and the log, visible with TF_LOG=INFO, says so. A cluster adopted from the legacy modules uses a storage identity with another name, which destroy leaves in place with its role assignment. The vault and the key stay in place. When the provider cannot read the set or the identity, or cannot remove a role assignment, the provider logs a warning, visible with TF_LOG=WARN, and leaves that set, identity, or role assignment in place. Remove the leftover set, identity, or role assignment by hand.