Server-Side Encryption

FlexFS supports S3 server-side encryption (SSE) for block data stored in object storage. When requested, the storage provider encrypts blocks at rest using its own key management.

Requesting SSE

Server-side encryption is requested via the --sse flag on the mount client:

mount.flexfs start my-volume /mnt/data --sse

Or via fstab mount options:

my-volume  /mnt/data  flexfs  _netdev,nofail,sse  0 0

With the flag set, flexFS includes the x-amz-server-side-encryption: AES256 header on all PUT requests to the block store. The storage provider handles key management and encryption transparently. The flag takes effect only on block stores whose API code is s3 — Amazon S3 and S3-compatible endpoints; it is ignored by the native gcs, azure, and oci block APIs.

When the flag is needed

For Amazon S3 itself, --sse is usually unnecessary: S3 encrypts every new object with SSE-S3 (AES-256) by default, in all buckets, at no additional cost, and default encryption cannot be disabled. Blocks written without the flag are still encrypted at rest.

The flag exists primarily for third-party S3-compatible object storage systems that support SSE but do not apply it by default. It is off by default in flexFS because many S3-compatible systems do not support SSE at all, and explicitly requesting it on such a system causes writes to fail with an error — set it only when your block store both supports SSE and does not already apply it on its own.

How it works

Step	What happens
Write	Mount client uploads a block with the SSE header. The storage provider encrypts the block before writing to disk.
Read	The storage provider decrypts the block transparently before returning it. No special header is needed on GET requests.

SSE is transparent to the application — no changes are needed beyond setting the flag.

SSE with proxy servers

SSE is configured independently on each component that writes to object storage — it is not passed through from the mount client. A mount client’s --sse applies only to blocks it uploads directly; blocks written through a proxy are governed by that proxy’s own --sse flag, so set it on every proxy in the group or those writes land without SSE.

Blocks cached on the proxy disk are stored exactly as the mount client sent them: compressed, and, on an end-to-end encrypted volume, still encrypted. The proxy never holds the encryption secret and cannot decrypt block data. The same is true of the mount client’s own on-disk cache, which sits below the encryption layer.

SSE vs. end-to-end encryption

Feature	Server-Side Encryption (SSE)	End-to-End Encryption (E2E)
Edition	All editions	Enterprise only
Who encrypts	Storage provider	Mount client
Key management	Storage provider	User-provided secret
Data encrypted at	Object storage layer	Before leaving mount client
Metadata encrypted	No	Yes
Protection from storage provider	No (provider has keys)	Yes (provider never sees plaintext)

Tip

For maximum security, pair E2E encryption with SSE. Data is encrypted client-side first, then encrypted again by the storage provider.

Storage provider support

Provider	SSE support	Notes
Amazon S3	Yes	SSE-S3 (AES256). New objects are encrypted with SSE-S3 by default even without the flag.
Google Cloud Storage	N/A	GCS encrypts at rest by default. --sse applies only to block stores with API code s3, and the Cloud Storage XML API does not honor x-amz-server-side-encryption.
S3-compatible stores (MinIO, Wasabi, Ceph RGW)	Varies	Depends on the implementation
Azure Blob Storage	N/A	Azure encrypts at rest by default
Oracle Cloud Infrastructure	N/A	OCI encrypts at rest by default

Next steps

• End-to-end encryption — client-side AES-256 encryption (Enterprise)
• TLS certificates — in-transit encryption
• Access Control — POSIX permissions and ACLs