Since we released Veeam Backup for GCP – Google Cloud Platform (can we call it VB4GCP from now on, do you mind?) a few weeks ago, many users have immediately started to use it. The use case of a single user protecting his resources is very easy to understand and configure, but today I’ve been asked by one of our service providers how could we configure the software to protect different customers from the same installation. Let’s test this in the lab!
The scenario
In VB4GCP I can register multiple projects and protect all of them with multiple policies. This is great for the security of a single GCP organization, as I can create different permissions and if one project is compromised, in my “well architected” design the backups will be stored in another project. This is explained in this diagram:
Using projects inside the same account is one of the great things of Google Cloud I’m lately learning, as it makes granular permissions very easy, compared to other platforms where I need to create multiple accounts to obtain the same results.
But what happens in a service provider environment? Here, I have two completely different organizations, each of them with their own projects. Ideally, there will be the provider with his own project where he’s running VB4GCP, and one or more tenants with their own production projects. In this case, the scenario would be something like this:
Let’s see how I can protect this scenario.
Enabling access to external projects
First, I create a new project from scratch in a different tenant (that’s a different account I have):
Then, I add a small virtual machine:
Now, I move into VB4GCP, where I start by registering the new project I want to protect:
In the following step, I don’t obviously have any service account created into this tenant project, in fact any permissions check will fail at this point. I can however use the wizard to get VB4GCP create for me the proper script that I would then need to run inside the tenant’s project. I only need to choose a name for the service account, and download the script that the software creates for me:
Note that the full address of the service account is unique in the entire Google Cloud Platform, as it uses the project’s name as part of the “domain” of the username. They are all formatted as “service-account-name@project-id.iam.gserviceaccount.com“.
In this way, ANY service account in GCP can uniquely be identified. Very clever from Google.
Now, I upload the script into my cloud shell and execute it there; remember, it has to be executed into the tenant’s project that I want to protect. Then, I can check again the permissions of the service account and it has now all the needed permissions to protect this project:
Backup policy for the external project
Time to create a new policy for the tenant. I go into VB4GCP and its policies and I start the wizard to create a new one. I give it a meaningful name, like maybe “name-of-tenant”_”name-of-policy”; this can become important once I start to protect many tenants from the same console. In the Sources I select the Project I want to protect, and its VM:
As I’m protecting an external tenant, it makes a lot of sense to enable backups in this policy, so I can take the data and move them into my provider’s account. So, if anything happens to the tenant’s project, data are safely stored in a different account with different permissions. Finally, I configure the scheduling options that I need, and I complete the wizard.
Time to start the policy and see what is going to happen!
The snapshot is almost immediate, while the backup may take a while, depending on a few factors. We can see what VB4GCP is doing at each step by looking at the live logging:
And after a few minutes, the policy is correctly executed, and we have a backup of a tenant VM saved in the provider’s object storage!
(Ignore the warning, there’s a limit on disk quotas in trial accounts like the one I’m using).