In case it helps anyone else:
I was building a similar limited-scope policy in my homelab over the weekend, but using Wasabi. I stole Dustin's snippet from above, but the "HeadBucket" action permission wasn't accepted in the Wasabi console, giving me an error when creating the policy.
Using "s3:ListBucket" instead worked for me.
EDIT: Upon further reading, this actually may open up more access than desired to all buckets. Striking that line all together from this second part of the policy appears to work for me with Wasabi. Was able to add extent without issue, and Capacity Tier is currently syncing without issue (so far).
What permissions should be checked here, see image below, on this screen to block public access but still allow IAM user access for the Veeam Object Storage backup?
You can safely Block all public access in the screenshot you've shown. Public access is defined as someone being able to access your S3 Bucket without authentication.
As the IAM user should have the necessary access applied to it, it's not deemed public access.
hcs_tech wrote: ↑Sep 28, 2019 7:31 pmWhat permissions should be checked here, see image below, on this screen to block public access but still allow IAM user access for the Veeam Object Storage backup?
Your post has been merged into the existing discussion. Kindly, check the answers provided above. Thanks!
anthonyspiteri79 wrote: ↑Feb 21, 2019 2:53 pm
Just as a heads up, there are a few of us internally working on a Cloud Tier Deep Dive White Paper which will contain explanations around scenarios like this. We hope to have it out in 4-6 weeks.
Any update on when this white paper will be available?
If you're interested in list of minimal permissions needed for Capacity Tier, then, we're planning to publish it next week. QA team has just confirmed the list. Thanks!