Skip to content

Google Cloud Storage

FlexBlock drives Google Cloud Storage through its native API. The grant names the bucket and prefix, so neither is passed on the command line.

FlexBlock uses Application Default Credentials, in this order:

  1. The file named by GOOGLE_APPLICATION_CREDENTIALS, which may be a service account key or a workload identity federation configuration.
  2. The credentials that gcloud auth application-default login writes.
  3. The instance metadata server.

Attach a service account to the instance with the Storage read-write or cloud-platform access scope, and grant it roles/storage.objectUser on the bucket.

roles/storage.objectUser carries the object permissions flexBlock needs, create, delete, get and list, and nothing on the bucket configuration.

Terminal window
gcloud storage buckets add-iam-policy-binding gs://acme-data \
--member=serviceAccount:flexblock@my-project.iam.gserviceaccount.com \
--role=roles/storage.objectUser

Bind the pod’s Kubernetes service account through Workload Identity Federation and the same role. The metadata server hands out the token.

Create a service account key, install it readable only by root, and name it in the environment file as GOOGLE_APPLICATION_CREDENTIALS. Under systemd, that is the per-instance environment file; see Running Under systemd.

Verify the grant and identity together before touching a device:

Terminal window
sudo -E flexblock show --remote

The clean way to isolate a volume on GCS is a bucket of its own.

Server-side encryption on GCS is provider managed. FlexBlock has no encryption setting for GCS; the --s3-sse and --s3-no-sse flags apply to S3 only.

Every chunk object is uploaded with a CRC32C checksum that GCS verifies, and verified again by flexBlock on download.

An http:// endpoint in the grant with no GOOGLE_APPLICATION_CREDENTIALS set is treated as an emulator, such as fake-gcs-server, and used without credentials. See Evaluating Without Hardware.