Bring your own Key Vault¶

When you finish, the cluster keeps its secrets in a Key Vault you own, and the cluster nodes reach that vault from their subnet.

Before you start¶

An existing Key Vault, whose lifecycle, network configuration, and access policies stay yours to manage
A cluster configuration from Deploy a basic Azure cluster or Deploy a production Azure cluster
The Azure CLI signed in with az login

1. Find the vault's resource ID¶

az keyvault show --name <vault-name> --query id -o tsv

The command prints an ID that ends in /providers/Microsoft.KeyVault/vaults/<vault-name>.

2. Let the cluster subnet reach the vault¶

az keyvault show --name <vault-name> --query properties.networkAcls.defaultAction -o tsv

If the command prints Allow, skip to step 3. If it prints Deny, add a service endpoint and a matching network rule for the cluster subnet.

az network vnet subnet update --resource-group <network-rg> --vnet-name <vnet> --name <cluster-subnet> \
    --service-endpoints Microsoft.Storage Microsoft.KeyVault
az keyvault network-rule add --resource-group <vault-rg> --name <vault-name> --subnet <cluster-subnet-id>
az keyvault network-rule list --name <vault-name> --query "virtualNetworkRules[].id" -o tsv

The last command prints the cluster subnet's ID. The nodes read their storage SAS tokens from the vault for the life of the cluster, so the rule must stay in place.

Instead of the rule, you can build a Key Vault private endpoint in the cluster subnet outside Terraform, linked to a privatelink.vaultcore.azure.net zone. An allowed egress IP address works only when a NAT gateway pins it, and "Allow trusted Microsoft services" does not cover the nodes.

3. Add the vault to the configuration¶

Add this line to the qumulo_filesystem_azure block, using the ID from step 1.

key_vault_id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-vaults/providers/Microsoft.KeyVault/vaults/qumulo-vault" # <-- Replace with your vault ID

terraform plan shows key_vault_id set to your vault ID. The plan rejects key_vault_id together with create_keyvault_private_endpoint, private_link_keyvault_dns_zone_id, or disable_keyvault_public_network_access.

Warning

key_vault_id cannot change after the cluster exists. Add it before the first apply or not at all.

4. Apply¶

terraform apply

The apply ends with Apply complete! Resources: 1 added, 0 changed, 0 destroyed. If cluster creation fails with ForbiddenByFirewall, see Troubleshoot an Azure deployment.

Next¶

On destroy, the provider removes its storage account registrations and SAS definitions from your vault and leaves the vault in place. The qumulo_filesystem_azure reference describes key_vault_id in full.