Longhorn S3 Storage
You set up longhorn s3 storage by pairing an object bucket with cluster secret keys. Then you point the backup target setting to that bucket URL and region. Most platform teams start with one shared bucket for all cluster backups. They create an account key and save it as a cluster secret. When those keys have broad permissions, any user with cluster admin rights can read or delete all backups. A small mistake in the cluster can wipe out your recovery data. How longhorn s3 storage works for vo
S3 Storage: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up longhorn s3 storage by pairing an object bucket with cluster secret keys. Then you point the backup target setting to that bucket URL and region. Most platform teams start with one shared bucket for all cluster backups. They create an account key and save it as a cluster secret. When those keys have broad permissions, any user with cluster admin rights can read or delete all backups. A small mistake in the cluster can wipe out your recovery data.
How longhorn s3 storage works for volume backups
Longhorn runs as block storage inside your Kubernetes cluster. It splits volume data into small chunks across multiple nodes. Local replicas protect against a single node failure in the cluster. Still, local replicas do not save data if the whole cluster fails. To protect against full cluster loss, the engine sends volume snapshots to an external bucket. This external store holds the backup blocks outside the cluster nodes.
First, you create a bucket in your object storage service. Next, you create an identity role or key pair with bucket permissions. You store those keys inside a Kubernetes secret in the storage namespace. The storage manager reads that secret and talks to the bucket endpoint. When a volume snapshot runs, the engine uploads only the changed data blocks. This block method saves space and keeps network traffic low during backups. If you run a local S3 service, you also add your custom certificate to that secret.
What native bucket setup solves and what it misses
This native backup flow solves node failures and full cluster outages. If a cluster dies, you can spin up a new cluster fast. You attach the same bucket and pull the volume blocks back down. Your apps get their state back without manual file copies. It also helps teams move volumes from one cluster to another.
Still, the native setup leaves a major operational gap around access control. The storage secret holds static keys that sit inside the cluster. Anyone who can read secrets in that namespace can copy those keys. Native setup only checks who logs in to the cluster or bucket. It does not inspect what individual commands or requests do in flight. A tired engineer can delete a live backup volume by mistake. Also, if an engineer restores production data to a test cluster, sensitive fields stay raw. Emails, phone numbers, card numbers, and national IDs move straight into test volumes without masking.
S3 Storage: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing secret keys and backup permissions safely
Teams should scope bucket permissions down to the smallest possible role. Give each cluster its own bucket or its own folder path. Never reuse the same static key across prod and test clusters. Read-only clusters should only get permission to list and download backup blocks. They should never have permission to write or delete objects in the prod bucket.
You should also turn on bucket object locking if your storage provider supports it. Object locking stops anyone from deleting backup blocks before a set date. Rotate your cluster storage keys on a regular schedule to limit key leaks. Finally, review your cluster role bindings so developers cannot read the storage namespace secrets. Keep cluster admin sessions short and log every command sent to the cluster API.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can Longhorn use self-hosted S3 storage for backups?
Yes, it works with most S3-compatible object storage tools on your own servers. You just provide the custom endpoint URL and add your root certificate to the secret.
What happens if the S3 bucket goes offline during a backup?
The backup job fails and the storage manager logs an error in the cluster. Your live volume keeps running fine because local replicas stay on the cluster nodes.
How do you share backups across two different clusters?
Point the second cluster to the same bucket URL and secret keys. Give the second cluster read-only bucket keys so it cannot overwrite the main backups.