Longhorn Object Storage
You set up longhorn object storage by linking a bucket as your backup store. Longhorn sends volume snapshots to any S3-compatible bucket or NFS share you pick. Most teams create one shared cloud key and store it in Kubernetes secrets. That approach works fast, but broad bucket roles put every cluster backup at risk. If one node or admin role leaks, an attacker can delete all volume backups. How longhorn object storage works for volume backups Longhorn gives Kubernetes pods block storage that
Insecure Direct Object References (IDOR): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up longhorn object storage by linking a bucket as your backup store. Longhorn sends volume snapshots to any S3-compatible bucket or NFS share you pick. Most teams create one shared cloud key and store it in Kubernetes secrets. That approach works fast, but broad bucket roles put every cluster backup at risk. If one node or admin role leaks, an attacker can delete all volume backups.
How longhorn object storage works for volume backups
Longhorn gives Kubernetes pods block storage that runs across your cluster nodes. It does not serve object buckets to your apps on its own. Instead, longhorn object storage acts as the remote vault for volume backups. When you take a snapshot, the storage engine reads the changed data blocks. Then the manager pods send those blocks out to your remote bucket.
To make this work, you create a secret inside the Longhorn namespace. That secret holds the bucket endpoint, the region, and your cloud key pair. You then point the Longhorn backup setting to that bucket URL and secret. Every storage manager pod reads that secret to push or pull backup blocks. You can use public cloud buckets or self-hosted object stores inside your network.
Why static bucket keys create risk in Kubernetes
Native secret setups verify which pod or user can log in to the cluster. They also give the storage engine permission to write files into your bucket. This design keeps normal backup jobs running on schedule every day. It also lets you move volumes to a brand new cluster during recovery.
Still, static cloud keys leave a large gap in daily cluster operations. Kubernetes role rules only check who can view or edit the secret object. Once an engineer or script has cluster access, they can read the raw key. Native role checks do not inspect individual commands or queries in flight. A shared key cannot tell which human triggered a backup delete command. If an engineer runs a cleanup script with a bug, the bucket obeys. It deletes the remote blocks because the static key has full write rights. Also, rotating these static keys takes manual work across multiple clusters and secrets. Teams often skip rotation because one bad update breaks every scheduled backup job.
Insecure Direct Object References (IDOR): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing cluster and backup operations safely
Safe storage operations need clear limits between cluster admins and raw backup buckets. Start by scoping the cloud bucket role to one single backup bucket path. Never reuse the same key pair across test clusters and live production clusters. Give your test cluster read-only bucket rights when you test volume restores. That stops a test cluster from overwriting live backup data by mistake.
You also need tight controls over who runs commands against the Kubernetes API. Instead of handing out permanent cluster admin files, require identity checks for every session. Track every action that touches the storage namespace or alters backup target settings. When you control the path to the cluster API, you protect the underlying secrets. You can pause risky delete calls before they wipe out critical recovery data.
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
Does Longhorn provide an S3 bucket for my apps?
No, Longhorn provides block volumes for pods inside your Kubernetes cluster. It uses external object buckets only to store off-cluster volume backups.
What happens if the audit storage goes offline?
Your running pods keep working because live volumes sit on local node disks. Scheduled backup jobs and volume restores will fail until the bucket returns.
Can two clusters share one backup bucket?
Yes, a second cluster can read the bucket to restore volumes during recovery. Give the standby cluster read-only rights so it does not alter live backups.