Google Cloud Storage

We write each new build of the databases you choose to a Google Cloud Storage bucket of yours, as our service account delivery@vpndetection-io.iam.gserviceaccount.com. There's no key to create or hand over: you grant that account access to the bucket. What lands in it, and when, is on Database Delivery.

Every customer grants the same account, so before writing anywhere we check the bucket is yours: it has to hold a verification file with a token that only your destination knows.

Setting it up

In the console, add a Google Cloud Storage destination, enter the bucket and the folder to deliver to, and save. The destination then shows both commands below with your bucket, folder and token filled in. Here the bucket is acme-data and the folder databases.

Let our service account write to the bucket:

gcloud storage buckets add-iam-policy-binding gs://acme-data \
  --member=serviceAccount:delivery@vpndetection-io.iam.gserviceaccount.com \
  --role=roles/storage.objectUser

Put the destination's token in the folder, as .vpndetection-verify:

echo -n vpndetection-1a2b3c4d5e6f7a8b9c0d1e2f | gcloud storage cp - gs://acme-data/databases/.vpndetection-verify

Then Test connection. It reads the verification file, writes vpndetection-connection-test.txt and deletes it, and Activate opens once it passes. Leave the verification file in place: each test reads it again.

roles/storage.objectUser is the narrowest predefined role that can replace an object, which Cloud Storage counts as a delete. Both uniform and fine-grained access control work, since we set no ACLs on what we write.