We recently updated our Azure RBAC policies for Key Vault management and now our automated backup process is failing with a Forbidden (403) error. The backup script worked fine before the RBAC changes.
We’re using Azure Key Vault for certificate and secret storage, and our backup automation runs daily using a service principal. After migrating from access policies to RBAC model, the restore operation also fails with similar permissions issues.
Backup-AzKeyVaultSecret -VaultName "prod-keyvault" -Name "db-connection"
ERROR: Operation returned an invalid status code 'Forbidden'
The client does not have permission to perform action 'Microsoft.KeyVault/vaults/secrets/backup/action'
Our network configuration includes firewall rules allowing specific IP ranges, and we’ve verified the service principal has Owner role at the subscription level. What specific RBAC role assignments are needed for backup and restore operations? Is there a difference between access policies and RBAC permissions for these operations?
One important distinction between access policies and RBAC: access policies were vault-scoped and granted permissions immediately, while RBAC assignments can take up to 10 minutes to propagate. If you just made the role assignment changes, wait a bit and retry. Also, the backup operation creates a blob that’s stored outside Key Vault - make sure your service principal has storage permissions if you’re specifying a custom backup location. The default behavior stores backups in a Microsoft-managed location which requires the trusted services bypass.
Quick clarification on the roles - for automated backup scenarios, you definitely want a custom role. Here’s what I’ve seen work in production environments: the service principal needs secrets/backup/action and secrets/restore/action at minimum, but also secrets/get/action for validation. Network-wise, if you’re running backups from Azure Automation or Logic Apps, the trusted services bypass is mandatory. Without it, even with correct RBAC, the operation will fail with 403. The IP allowlist only applies to direct client connections, not Azure service-to-service calls.
I ran into this exact issue last month. The problem is that backup/restore operations require specific permissions that aren’t included in the standard Secret User role. You need to assign “Key Vault Crypto Officer” role or create a custom role with these actions: Microsoft.KeyVault/vaults/secrets/backup/action and Microsoft.KeyVault/vaults/secrets/restore/action. Also verify your network firewall rules - if you’re running the backup from an Azure service, make sure “Allow trusted Microsoft services” is enabled under the networking tab.
The network firewall is likely contributing to your issue. When using service principals from Azure Automation or other Azure services, you need “Allow trusted Microsoft services” enabled - this is separate from IP-based access. For RBAC roles, I’d recommend creating a custom role specifically for backup/restore rather than using Crypto Officer which grants broader permissions than needed. The custom role should include: Microsoft.KeyVault/vaults/secrets/backup/action, Microsoft.KeyVault/vaults/secrets/restore/action, and Microsoft.KeyVault/vaults/secrets/readMetadata/action. This follows least privilege principle while solving your immediate problem.