Kubernetes backup gateway | S3-compatible | production-preview evaluation
Path-private S3 backup gateway.
rs3 is a path-private, tamper-evident S3 gateway for operators
evaluating Velero/Kopia backup storage on S3-compatible infrastructure that
may be untrusted or partially compromised.
What It Is¶
The gateway is designed for teams that need existing S3-oriented backup tools to work without exposing repository paths, Kubernetes resource names, or accepted repository state directly to an object-store backend.
Privacy
Path and Kubernetes names stay opaque.
Client paths, Kubernetes object names, namespaces, and snapshot labels are treated as secrets at storage and telemetry boundaries.
Integrity
State is accepted through signed commits.
Repository changes are committed and anchored instead of trusting a latest-object convention in the backend.
Operations
Restore behavior is measured.
Kopia runs compare the gateway to a straight proxy baseline and record request, byte, CPU, memory, and variability evidence.
Current Status¶
rs3 is being prepared for a production preview. The repository contains a
working local gateway path, Kopia and Velero integration harnesses, repository
encryption boundaries, Kubernetes Lease anchoring, signed v2 commit publishing,
restore-bundle workflows, retention-aware storage contracts, metrics, tracing,
and performance measurement against a straight proxy baseline.
commits/v01 has been removed and is unsupported; it had no production
repositories. The runtime now reads and writes bounded commits/v02 payload
packs, encrypted index runs, and signed index-root checkpoints. Packed reads
resolve authenticated record descriptors from the encrypted index and fetch
the exact payload ciphertext range without first reading pack metadata.
Existing gateway and provider results remain regression evidence. Guarded
compaction, automatic watermarks, clean local fresh-process scale, the exact
full-GC engine, and the fenced maintenance supervisor are implemented and pass
local gates. A repository release remains blocked on current retained-provider
restart/fault and production-cardinality maintenance qualification, exact
candidate pinned-runner timing, owner release infrastructure, and external
review. New writes isolate effective protection cohorts and maintenance renews
restore dependencies before guarded orphan deletion. No v01 migration or
dual reader is planned.
Do not treat the current repository format, cryptographic formats, or runtime defaults as production-stable yet.
Production preview, not stable format
The project is being built toward a production-preview evaluation target. Current docs intentionally separate measured facts from future design intent.
Design Priorities¶
- Hide client-visible paths and Kubernetes names from backend object keys, unauthenticated metadata, metrics labels, traces, and logs.
- Detect rollback through signed commits and an external anchor instead of trusting a latest-object convention in the object store.
- Preserve restore correctness for S3 backup clients, starting with Kopia and Velero/Kopia.
- Measure request count, read bytes, write bytes, elapsed time, CPU, and memory against a straight proxy baseline before optimizing.
- Keep operational failure modes explicit: anchors fail closed, retention is provider-capability gated, and recovery modes must be auditable.
Reader Paths¶
| Reader | Start Here |
|---|---|
| Platform lead | Evaluation |
| Release reviewer | Production Preview |
| Security reviewer | Security Model and Security Review |
| Operator | Operations and Restore Under Attack |
| Contributor | Architecture and Testing |
| Performance reviewer | Performance |
Documentation Structure¶
The public docs site follows a Diataxis-style split:
- Tutorials and first steps in Getting Started.
- How-to operational material in Operations.
- Reference material under Reference.
- Explanation in Architecture, Security Model, and Performance.
The MkDocs site builds from docs/site/.