Velero: Least privileges of Service Principal

[jaygridley]

The documentation states that the Service Principal used with Velero should have a role Contributor. This role is quite open and some company policies do not allow this. The documentation should be updated to state the least privileges for the Service Principal.

[skriss]

agreed, it would be great to refine the privileges here. Would love some help on this issue!

[fl-max]

Does it truly need Subscription wide access or can it be scoped to just the Resource Group?

[pietervincken]

It requires permissions for (at least) the storage account and the disks to snapshot them right? I'm not sure which other permissions are required.

[prutsert]

I've been able to narrow it down to _Contributor_ role on the _Resource Groups_ that are involved. Those are the Resource Group of the AKS cluster: $AZURE_RESOURCE_GROUP, and the Resource Group of the backup storage: $AZURE_BACKUP_RESOURCE_GROUP.
This could probably be even more restrictive on the backup storage Resource Group, but as long as it only contains data created and used by Velero anyway, this works for me.

AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" --role "Contributor" \
   --query 'password' -o tsv --scopes \
 /subscriptions/${AZURE_SUBSCRIPTION_ID}/resourceGroups/${AZURE_BACKUP_RESOURCE_GROUP} \
 /subscriptions/${AZURE_SUBSCRIPTION_ID}/resourceGroups/${AZURE_RESOURCE_GROUP}`

Both Resource Groups are in the same Subscription, in my case. I'm not sure if this would work if they are in separate Subscriptions, and you would change /subscriptions/${AZURE_SUBSCRIPTION_ID}/resourceGroups/${AZURE_BACKUP_RESOURCE_GROUP} to /subscriptions/${AZURE_BACKUP_SUBSCRIPTION_ID}/resourceGroups/${AZURE_BACKUP_RESOURCE_GROUP}

[fredgate]

Yes configuring the service principal with the least privileges is almost essentials. Because having a service principal with full access on a subscription is not acceptable by company policy of some of our customers.
Already being able to limit to the resources group is appreciable. But maybe we can be even more precise.

[seboss666]

I just found myself getting involved with deploying velero on a client-deployed cluster with no direct access to their azuread, I'm pretty sure that if I ask them to deploy a service principal with contributor role just to perform aks related backups, they will just laugh at me.

Strangely, the gcp documentation is far more precise on IAM policies : https://github.com/vmware-tanzu/velero-plugin-for-gcp. Why is this not the case here ?

[ashish-amarnath]

@seboss666 We would love some help on this.
@prutsert Do you mind putting your comment into our docs?

[michaelshire]

I am currently using Velero in Azure (ARO) with the SP running with role "Storage Account Contributor" applied to the _Storage Account_ created for Velero.
This is a significant step down from the Contributor role to the subscription. I have performed backups and restores at this role, no issues so far.
_edit_ getting "PartiallyFailed" on backup status. Looking into this.

[seboss666]

Hello michael,
are you able to generate dynamic volume snapshot with that coverage ? I can see why it's sufficient for object/manifests backup, and it's great to know that, but I'm afraid it may be too narrow for the snapshot feature :/

[michaelshire]

Hello michael,
are you able to generate dynamic volume snapshot with that coverage ? I can see why it's sufficient for object/manifests backup, and it's great to know that, but I'm afraid it may be too narrow for the snapshot feature :/

Agreed. Main issue there is Deny Assignments applied to Azure Red Hat OpenShift (ARO) clusters are preventing volume snapshots, and the error in my logs are resulting from that (even with Contributor at the Subscription level, same failure). Raised issue with the product team.