Longhorn Backup Target S3
You set up a longhorn backup target s3 by linking your cluster to an object bucket. You give the storage manager an endpoint URL and a secret with bucket keys. Most teams store static cloud keys inside a Kubernetes secret in the storage namespace. If those keys or cluster roles are too broad, anyone with secret read rights can pull or wipe all volume backups. How a longhorn backup target s3 works Longhorn runs as a block storage system inside your Kubernetes cluster. It splits persistent volu
Backup Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a longhorn backup target s3 by linking your cluster to an object bucket. You give the storage manager an endpoint URL and a secret with bucket keys. Most teams store static cloud keys inside a Kubernetes secret in the storage namespace. If those keys or cluster roles are too broad, anyone with secret read rights can pull or wipe all volume backups.
How a longhorn backup target s3 works
Longhorn runs as a block storage system inside your Kubernetes cluster. It splits persistent volume data into small blocks across your cluster nodes. When you take a snapshot, the system records only the blocks that changed. To protect against a full cluster outage, you must send these snapshots off the nodes.
An S3 bucket serves as the remote store for those changed data blocks. You point the storage manager to the bucket name and region. You also point it to a Kubernetes secret that holds your cloud keys. The manager reads that secret and tests the link to the remote bucket.
Once linked, the storage engine pushes changed blocks to the bucket on a set schedule. If a node fails or a volume breaks, the engine pulls the blocks back. It rebuilds the persistent volume from the remote objects without manual file copies.
Choosing between static keys and cloud roles
Teams usually start by creating an IAM user with read and write bucket rights. They put the user key pair into a standard Kubernetes secret. Every storage pod and admin with namespace read rights can read that secret. Those static keys do not expire unless an engineer rotates them by hand.
Cloud workload roles offer a safer way to grant bucket rights to your cluster. With this setup, the cloud provider links an IAM role to the Kubernetes service account. The storage pods get short-lived tokens from the cloud provider instead of static keys. You still need to scope the bucket policy so pods only touch one bucket.
Backup Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native storage settings leave open
Setting up bucket roles handles how the storage pods talk to your cloud storage. It does not control what engineers or automated tools do inside the cluster itself. Engineers still log in to the cluster API or database pods to fix problems. Once an engineer has a valid cluster role, Kubernetes lets every permitted command run.
Native roles decide who can log in to a cluster or read a secret. They do not inspect individual commands or queries while an engineer works in a session. A wide admin role lets a user read backup secrets or delete live volumes. It also lets a user pull raw database tables that hold emails, phone numbers, or card numbers.
To close this gap, teams must check commands and queries at the execution level. You need a way to require quick peer approval before someone runs a destructive command. You also need data masking that rewrites matched fields in results during live queries. That way, you protect both the live data and the remote volume backups.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why is my S3 backup target showing as unavailable?
This usually happens when the bucket URL format or region string is wrong. It also happens when the Kubernetes secret lacks list and write permissions for the bucket.
Can two clusters share the same S3 bucket for backups?
Yes, two clusters can use one bucket if you give each cluster a unique folder path. Sharing the exact same folder path can cause backup state conflicts and missing volume data.
What happens to running pods when a backup runs?
Your pods keep running and writing data to the volume while the backup runs. The engine reads a frozen point-in-time snapshot and sends those blocks to the bucket.