Actually found the answer in the docs.

Access Permissions - User Guide for VMware vSphere (veeam.com)

As default the traffic will flow throught the gateway server, even if we set the repository in direct mode. We also need to set the access permission correct.

next up:

Find a setting which sets the setting as default for every repository I add (prefer to add one wasabi respotiory for each customer. Perhaps not the best solution though...) What do you guys/girls do?

I believe it would make sense that all traffic to a VSPC’s object storage would flow via them so they can appropriately secure the storage. You wouldn’t want a bucket accessible to all because of customers targeting it directly, and then a customer using unencrypted backups would you? And if you want your customers to write directly to wasabi that you don’t target VCC in this case.

I’m assuming it’s a VCC-B job with the performance tier using wasabi?

To flow the backuptraffic via VSPC running in Azure would be extreme expensive regarding the egress, dont you think?

It seems like you can configure a session token, seems like it could be a great fit for secure backup direct to the object storage

It’s good that Veeam has the option based on what you’ve found for such scenarios. Forgive me, I stopped working for a VSPC at the end of 2021 so I’ve not played with v12 with cloud connect myself yet.

I don’t deny that if you’re hosting via a public cloud and egressing to another public cloud that the egrees fees would be cost-prohibitive, in which cases the scenario you’re looking at does make sense. I’m thinking more along the lines of the security of the storage, so provided these tokens can be generated to control access sufficiently it should be safe for direct to object.

Would be good to see a write up on how you get on with this!

I know you are working with VCC but if you want Agents to go to Wasabi directly why not just point them there?  The new agent can do direct itself and would eliminate the costs for you.

Because we want to automate this. cant login to every workstation at customers on their laptops as we are not their companyadministrator.

And VCC doesnt support the object storage as repository directly in the gui. But it seems like if we add a object storage as repository, and the veeam agents then choose cloud connect repository, we can use the traffic (see sreenshot at my earlier post) to actually redirect that traffic to the object storage directly.

This is indeed possible via IAM/STS service which is also provided by Wasabi. In your screenshot, you’d have to configure the third option and add the IAM and STS endpoints. Additionally, you need to add some permissions to the account used to initially setup the object storage in Veeam to enable this account to create temporary STS access keys for the Veeam Agents. This makes sure that each agent only has access to its own backups.

Do you have a blog for these steps? Would be great!

Not yet… one of my fellow SAs here at Veeam is currently preparing a white paper about this and I had the chance to review a draft.

Maybe he can provide more details, I’ll check with him.

That would be great! If he wants he is welcome to send me the draft in PM

hi all,

I’ve been summomed by Matthias to take a look at this thread, as I’m the guy writing the mentioned WP. I tested this new “Secure mode” as we call it (I’m not sure there’s an official name, but I’d say we can call it like this) and I can answer your questions.

We need to split the two paths: backup traffic will be indeed direct from agents to object storage. One of the premise of Secure Mode is in fact the use of “Direct” option when mounting the objs itself. Otherwise, we fall again into the scenario of the gated access via cloud gateways (in VCC) that will become soon the bottleneck.
VCC (and VSPC) are still there for the management traffic, so that all policies and commands to agents will be controlled by VSPC, like this:

but here comes the need for IAM/STS: without it, each agent uses the same accessID/secretID keypiar, so everyone is able to read everyone else’s backup. No good! But, at the same time, creating a bucket for each agent is a PITA. With Secure mode and STS, you share the same bucket across an entire tenant, and each agent (remember, they are sub-tenants in VCC) receives a STS token that allow them to only read what they have written. In the mentioned whitepaper I called it “automatic multitenancy”.

The final draft is completed, I cannot post it here but I can surely share it via PM, the more the feedback the better. Also cause I really want the paper to go out asap, and this thread gives me the confirmation that many people are looking at it.

hi all,

I’ve been summomed by Matthias to take a look at this thread, as I’m the guy writing the mentioned WP. I tested this new “Secure mode” as we call it (I’m not sure there’s an official name, but I’d say we can call it like this) and I can answer your questions.

I know you are working with VCC but if you want Agents to go to Wasabi directly why not just point them there?  The new agent can do direct itself and would eliminate the costs for you.

We need to split the two paths: backup traffic will be indeed direct from agents to object storage. One of the premise of Secure Mode is in fact the use of “Direct” option when mounting the objs itself. Otherwise, we fall again into the scenario of the gated access via cloud gateways (in VCC) that will become soon the bottleneck.
VCC (and VSPC) are still there for the management traffic, so that all policies and commands to agents will be controlled by VSPC, like this:

but here comes the need for IAM/STS: without it, each agent uses the same accessID/secretID keypiar, so everyone is able to read everyone else’s backup. No good! But, at the same time, creating a bucket for each agent is a PITA. With Secure mode and STS, you share the same bucket across an entire tenant, and each agent (remember, they are sub-tenants in VCC) receives a STS token that allow them to only read what they have written. In the mentioned whitepaper I called it “automatic multitenancy”.

That would be great! If he wants he is welcome to send me the draft in PM

The final draft is completed, I cannot post it here but I can surely share it via PM, the more the feedback the better. Also cause I really want the paper to go out asap, and this thread gives me the confirmation that many people are looking at it.

Thanks for sharing this Luca as it makes sense.  If you need more feedback feel free to PM me the document too.  

It looks like the secure mode is going to be the way to go.  Somewhat related, I know that for VBR installations, it’s recommended to have a separate bucket for each backup server because otherwise you introduce performance issues because you have multiple servers trying to read/write the metadata for the bucket.  In my case, I have multiple buckets under the same account.  As for using the Veeam agent, it certainly doesn’t make sense to have a bucket for each agent, so I’m curious about this secure mode as well, and also to see if this could filter back into VBR where you could then have multiple servers accessing the same bucket.  In most cases, I think I’d still want them separate because I can then easily see how much each bucket is consuming and bill back if needed based on usage, but then again, I have one client that has two VBR deployments - one for their main datacenter, and one for a subsidiary that they acquired, so each deployment is using a separate bucket and we have to tally the utilization for both - it could be nice to have them going to the same bucket if possible.

You can also send VBR backups into OBJS via Secure Mode, but in this case the tenancy will be only one, as the idea is that every vm from the same server belongs to the same tenancy. I didn’t tested the VBR scenario, but in your case as I understood there will be two STS accounts, one for each VBR; to be confirmed. 
Where Secure mode shines is indeed with Agents, where the automatic creation of STS users makes a lot of sense. By the way, it works not just for S3, but also Azure and GCP, even if in different ways as the protocol is different.

About the design, I didn’t see it applied yet in the field (also cause there’s no documentation yet lol, so I hope my paper will help) but I guess that for billing/performance reason, people would indeed use one bucket for each tenant, and then use secure mode inside each tenant. I’m curious to read opinions from service providers, how do they see it fit.

PS: don’t forget block storage for VCC, as Secure Mode works only if sources is VBR v12 and its related Agents. v11 and v10 cannot use Secure mode, but still need to be supported.

Thank you, I’d love to see this whitepaper as well and learn more about this.  I may or may not use it, but I’m very much curious about how this works,

Very interesting concept. Would you send the document to me per DM please, too?

Have implemented this in my labs and it works gret with Wasabi also. The STS user gets created when the agent initialize the first backup to the repository. And the traffic runs directly to the object storage, thats great!

As the document says (when you receive it) it will need an extra iam-policy attached to your IAM-user. 

I prefer one wasabi account, 1 bucket, 1 vspc repository for my customers. Its probably too much overhead for larger service providers which probably can have a lot of customers on one shared repository, but since we are pretty small I like this segmentation. 

Exactly what I am trying to do (Workstation agent talking directly to Wasabi) while we work out issues with the full setup. Would you be able to send to me as well? Trying to determine how to wire up wasabi to the local agent storage selection. Thanks!

Hi all, a quick update: the whitepaper is out, you can read it here:
https://fromthearchitect.net/wp-content/uploads/2022/09/VBR12-and-Secure-Mode.pdf

Thanks for sharing this Luca.

Thank you for sharing...will be reading this as soon as time permits!

Hi.

Thumbs up for the whitepaper, unfortunatelly we are still struggling to get over 403 forbidden message when implementing Secure Mode with wasabi :/