[Wasabi] 403 Access Denied error when using limited IAM policy

[pirx]

Well, not really. If such a thing (the permission change) slips through QA and can't be fixed in a short time, in my opinion this does not look good for any vendor. Especially if there was feedback from support 2 weeks ago that it is fixed.

[StoopidMonkey]

I'm having the same issue! I'm hoping the fix is published soon.

[MrSpock]

I am evaluating Wasabi with immutability in VBR 12.1, but got stuck on this too (I think).

"Failed to delete checkpoint. Details: S3 delete multiple objects request failed to delete object"

Support case ID: #07076664

[veremin]

You may be encountering a similar issue indeed.

We have just reached out to the Wasabi team to request an update on the current state of the issue.

As soon as we receive a response, we will promptly share it here.

Thanks!

[chrisWasabi]

Hi All,

A fix has been identified and will be released in our next patch rollout in mid-February.
There is a workaround that can be leveraged by contacting support@wasabi.com with the bucket you are experiencing the issue on.

Thanks,
-ChrisWasabi

[mlgim]

Any updates on this issue? Thanks

[Mildur]

Hi Michael

Please see ChrisWasabis comment.
Wait till mid-February or contact wasabi support for the work around.
Also my understanding from previous comments, you can use your root account access key to access the buckets until the fix is installed on Wasabis end.

Best,
Fabian

[nextsys]

If you add to the Wasabi IAM policy as per below it should temp fix the issue.

“s3:Delete*”

Our policy previous to the issue (v12.1) had just these (2) delete permissions. Apparently for now it needs more delete permissions.

"s3:DeleteObjectVersion",
"s3:DeleteObject",

[ReKe]

@chrisWasabi

Is the fix applied now? Is it safe to remove all the workarounds?

Greetings Rene

[chrisWasabi]

Hi All,

The fix has been applied to all vaults. You should be able to revert to your standard settings.

Thanks,
ChrisWasabi

[BostjanUNIJA]

Hi guys.
We are experiencing the same issue (403 forbiden).
As vscp we are adding our first customer in our veeam cloud connect infrastructure.
The idea is that Veeam agents backup traffic would go directly to S3 wasabi (we as vscp provider dont want to be a proxy for that traffic).
We have opened support ticket on Veeam and also on Wasabi but no useful answer so far.

We have enablee object versioning on wasabi newly created bucket and we want to use Veeam's immutable functionality.

From articles on Veeam page I see that immutable has option to have helper appliance or option without that.
QUESTIONS:
1. For starts, what is exactly helper appliance in immutable repository and where can it be set?

2. Can somebody please write how the policy for S3 wasabi bucket should look like?

3. Do you guys create 1 policy for wasabi bucket or you create multiple and assign it to a user which has access to the bucket?

4. In this threads I often see: Resource: *, does that mean you are giving permission to all the buckets?

5. So far we have been creating this default policy below every time when we have created new bucket. Do we need to merge additional settings into 1 policy or add an additional policy?

Code: Select all

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "arn:aws:s3::: NEWbucketNAME"
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::NEWbucketNAME ",
        "arn:aws:s3::: NEWbucketNAME /*"
      ]
    }
  ]
}

6. Is IAM custom policy needed only in case where backup policy is set to; managed by agent, or does direct backup traffic to S3 wasabi also works if you create backup policy managed by server?

Thanks anyone willing to answer our questions!

[BostjanUNIJA]

Hi. Anyone?

[DavidRobertson]

Hi, I looked into providing Wasabi-backed CloudConnect to some of our customers a while back. Your questions regarding policies are very valid and ones I had at the time before I decided we probably didn't have a need to present it as "our" storage and instead just use Wasabi WACM to provision and then direct-connect customers to their own buckets. Your use case may be different however.

[marco.luvisi]

Same issue on my experience on configuration from VCSP with IAM/STS, need policy "WasabiFullAccess" to user that access to bucket.