Microsoft.Storage/storageAccounts/read permission required with useAAD="true"

[ranjith-vatakkeel]

What steps did you take and what happened:

As per this link, when we migrate from listkeys to AAD, only storage data blob contributor role is sufficient to manage the backups. But observed that, plugin first expects Microsoft.Storage/storageAccounts/read permission and then fallback to default blob storage url and everything works perfect. Since blob contributor doesn't contain Microsoft.Storage/storageAccounts/read, If we need clean logs, then we have to give this role in addition. Also it is worth to mention this required role in the above document link.

What did you expect to happen:

Clean pod logs with out showing any 403.
The following information will help us better understand what's going on:
No any issues, just an update to the documentation

If you are using velero v1.7.0+:
Please use velero debug --backup <backupname> --restore <restorename> to generate the support bundle, and attach to this issue, more options please refer to velero debug --help

If you are using earlier versions:
Please provide the output of the following commands (Pasting long output into a GitHub gist or other pastebin is fine.)

• kubectl logs deployment/velero -n velero
• velero backup describe <backupname> or kubectl get backup/<backupname> -n velero -o yaml
• velero backup logs <backupname>
• velero restore describe <restorename> or kubectl get restore/<restorename> -n velero -o yaml
• velero restore logs <restorename>

Anything else you would like to add:

Environment:

• Velero version (use velero version): latest
• Velero features (use velero client config get features):
• Kubernetes version (use kubectl version):
• Kubernetes installer & version:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "I would like to see this bug fixed as soon as possible"
• 👎 for "There are more important bugs to focus on right now"

[Lyndon-Li]

@anshulahuja98 Could you help to check this issue?

[anshulahuja98]

IF you set
storageAccountURI="https://xxxxxx.blob.core.windows.net"
Then the GET on call on storage is not made.
GET call is only a fallback if the storageaccounturi is not provided.

[anshulahuja98]

if you provide the URI, the blob data contributor role will be enough.