Credentials

FlexBlock never takes credentials on the command line. It asks each provider’s own credential chain, so the common identities that work for aws, az, oci or Google’s client libraries work for flexBlock; the per-provider pages list exactly which are supported.

What the identity needs

Every command that touches the bucket performs the same small set of operations under the grant’s prefix: list the objects there, read them, write them (sometimes with a create-only or compare-and-swap condition), and delete them. Nothing is created or changed outside the prefix, so the identity can be scoped to the bucket and, on providers that support it, to the prefix.

Operation	Used for
List under the prefix	Rebuilding the object index at start, orphan checks, show --remote
Read an object	Cache misses, the volume superblock, the ownership marker
Write an object, including overwrite	Flushing chunks, the superblock, the access check at init, attach and start; the ownership marker with create-only and compare-and-swap conditions
Delete an object, singly or in batches	Discarded chunks, the access check, wipe
List one key under the prefix (S3, GCS, OCI) or read the container (Blob)	The reachability check every command runs first

Good practice

Three habits keep this simple in production:

• Prefer the platform identity of the host: an instance role, a service account, a managed identity or an instance principal, over static keys. Nothing to rotate, nothing on disk.
• Keep static secrets out of unit files. When a static secret is unavoidable, put it in the per-instance environment file the systemd unit reads (see Running Under systemd), owned by root with mode 0600, never in the unit file or a shell history.
• Test before touching a device. Check the pairing of grant and identity with show --remote, which proves list and read only. init, attach and start check write, overwrite and delete before they change anything.

sudo -E flexblock show --remote

When a permission is missing

• A permission problem surfaces as a permanent storage error naming the provider, the operation and the HTTP status, for example gcs LIST flexblock/acme-0001/ [403], and the command exits with code 14.
• If listing works but init, attach or start finds the credentials cannot write, read, list or delete, it names the missing permission and exits with code 10.

The daemon does not retry permanent errors, so a missing permission shows up at the first command rather than as a slow failure later.

Per-provider summary

Provider	Credential chain	Recommended production identity	Details
Amazon S3	AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, then AWS_PROFILE and the shared config files, then web identity, or the container or instance role	EC2 instance profile with a policy scoped to the prefix	Amazon S3
Google Cloud Storage	GOOGLE_APPLICATION_CREDENTIALS, then gcloud application-default credentials, then the instance metadata server	Service account with roles/storage.objectUser on the bucket	Google Cloud Storage
Azure Blob Storage	AZURE_STORAGE_KEY, otherwise Entra ID: service principal, workload identity, managed identity, then an Azure CLI or Azure Developer CLI login	System-assigned managed identity with Storage Blob Data Contributor on the container	Azure Blob Storage
OCI Object Storage	OCI_CLI_AUTH, or when unset: resource principal, then the ~/.oci/config profile, then instance principal	Instance principal in a dynamic group with manage objects	Oracle Cloud

One identity, many volumes

The grant, not the identity, decides which bucket and prefix a command touches. A host that serves several volumes can use one identity whose policy lists every prefix, or one identity per volume if the volumes belong to different tenants.

Next steps

• Your First Volume
• Running Under systemd: where per-instance environment files live.