What a security review and a continuity plan will ask
Security and resilience
Encryption, retention, authorisation, continuity across two sites, and getting a whole cluster back from one surviving backend and a passphrase.
Authentication and authorisation
Two properties of the evaluation order matter to a review: an explicit denial wins wherever it appears, and default deny is the floor.
Every signed request is verified
The gateway checks Signature Version 4 on every signed request to the S3 endpoint, including the streaming form clients use for chunked uploads. It resolves the credential to its realm before any handler runs. Presigned URLs are verified on the same path.
Anonymous requests are policy, not a bypass
The same policy engine evaluates an unsigned request. It is refused unless a policy names the anonymous principal explicitly.
Copies are authorised twice
A copy is checked for the destination and separately for read access to the source object, before the source is looked up at all.
Legacy access-control lists are refused
Access is governed by bucket policies and identity policies. Writing an access-control list is answered as not implemented, and reading one returns a document granting the owner full control. An application whose access model rests on per-object list grants has to express that model as policy before it moves.
Encryption and retention
Object data can be encrypted by the gateway before it reaches a backend, so a backend holds ciphertext rather than readable content. Keys come from the cluster's own key hierarchy, from an external key management service reached through a provider interface, or from the client with each request. A default can be set per bucket.
The cluster's master key forms at first boot with no external material required. It is then held one of two ways: resident in the metadata plane, protected by that plane's own access control, or sealed under a key file mounted on every pod. Sealing is optional hardening rather than a prerequisite, and a resident cluster upgrades itself to sealed at boot once the key file appears.
Retention is enforced through the same policy engine as everything else. A governance-mode rule can be bypassed only by a principal whose policy grants the bypass action. That check runs on the request like any other action, not against a list of exempt accounts. Compliance mode admits no bypass at all.
Retention and legal hold
- Object lock per bucket
- Configured on the bucket, applied per object version.
- Governance mode
- An explicitly authorised principal can shorten or remove a retention period. Authorisation runs through the live policy engine.
- Compliance mode
- No principal can bypass it, including a realm administrator.
- Legal hold
- Independent of a retention period, set and cleared as its own flag.
- Encryption on copy
- A server-side copy re-encrypts rather than moving ciphertext it cannot re-key.
Trusting your own certificate authority
Most of what the gateway calls outbound is inside your own network: the backends, the webhooks that receive event notifications, your identity provider, and the peer and witness of a replicated pair. In an enterprise or a sovereign installation those endpoints present certificates from an internal authority, not a public one.
So each of those connections can be given its own certificate authority bundle. A backend takes one when it is registered, and so does a notification topic. The bundle is write-only at the administrative interface: no route reads it back, and a listing returns only its SHA-256 fingerprint.
Verification can also be switched off per backend, because a lab sometimes needs it. That is treated as the hazard it is rather than as a convenience — a metric reports every backend currently running without verification, so you can alert on it instead of finding out during an audit.
Where a bundle can be set
- Per backend
- Given at registration, alongside an optional per-backend switch to skip verification.
- Per notification topic
- So a webhook inside your network does not have to be reachable over public trust.
- Replication peer and witness
- Set in configuration, on both sides of a pair.
- The administrative interface
- The operator command line carries its own bundle flag for reaching the admin API and the identity provider.
Continuity across two sites
Geo-replication is an active-passive pair of independent clusters, each with its own metadata plane and its own backends.
Every replicated change is written to an outbox in the same transaction that makes the change, so a committed change is never left unqueued. The passive site pulls entries and applies them. It fetches the bytes it needs over an authenticated internal surface, rebuilds volumes byte for byte, and adopts them onto its own backends through the normal rotation path.
Each site carries a role. A site that is not primary closes its S3 endpoint. It answers with a retryable service response rather than an authorisation failure, so a client retries instead of treating the outage as a permissions problem. Role changes carry an epoch, and a site whose role record has gone stale fences itself.
Failover is an operator decision with two shapes. A planned handover drains the primary, waits for the passive to catch up, and loses nothing. A forced promotion during an outage may lose whatever had not yet arrived. An optional third-site witness arbitrates, so the two halves of a partition cannot both believe they are primary.
The whole internal replication surface requires transport security. A site that has lost its link is rebuilt by a reseed from the surviving primary, and that reseed resumes after a crash. A site that lost a promotion race can be truncated back to the divergence point, with its own bytes exported first.
What the operator drives
- Planned handover
- Demote the primary, wait for convergence, promote the peer. Designed to lose no recent work, and cancellable while it runs.
- Forced promotion
- For a site that is gone. May lose whatever had not reached the passive, and the split-brain wait-out is never skipped.
- Reseed
- Rebuilds a passive's entire key space from a non-empty primary, resumable across restarts. The only recovery for a lost link.
- Failback
- Truncates a site that lost a promotion race. It exports that site's divergent bytes before removing them, and it refuses rather than guesses when the record it needs has been trimmed away.
Recovering a cluster you have lost
Disaster recovery rests on an operator passphrase rather than on preserved key material. Configuration records are copied to the backends by a background worker, and setting the passphrase writes a wrapped copy of the master key to every registered backend.
A recovery cluster boots with its write path fenced. It takes the passphrase, unwraps the key, and rehydrates the configuration records: backends, realms, placements, buckets, credentials and policies. A further documented step rebuilds tenant metadata by listing the volumes on each backend and reading their manifests.
The passphrase is always entered at an interactive prompt. It is never read from a flag or an environment setting, and never written to a log. A recovery attempt that keeps failing locks out rather than allowing an unbounded number of guesses.
What recovery needs
- One surviving backend
- Holding the sealed configuration bundle and the wrapped key.
- The passphrase
- Held by the operator, outside the cluster.
- A foreign-identity check
- A cluster identity is written once at first boot, and restore refuses a bundle that belongs to a different cluster.
- Nothing else
- No preserved key file, and no metadata-plane backup, though a backup remains worth having for the time it saves.
Reliability in the ordinary case
Most of what protects data is not failover. It is what happens on a normal Tuesday when one component misbehaves.
A torn write is never read as a complete one
An open volume has a write-ahead sidecar recording each object as it is appended. Sealing appends the manifest and deletes the sidecar, so a surviving sidecar proves the volume was never sealed, and recovery reads the sidecar first.
No read location is ever dropped
Health ranking only reorders an object's locations. A backend believed down is the last resort and never skipped, so a stale health signal cannot make readable data unreachable.
Failures after the answer are recorded
A backend operation that fails after the client has been answered goes to a durable retry queue that a background worker drains. The queue does give up eventually: a record that exhausts its retry budget is abandoned and logged. That is why its depth is a figure to watch.
Durability debt cannot be cleared by hand
No operator command discards an owed copy. The product does not promise that every owed copy is eventually made; it promises that none is forgotten.
Background work is serialised by lease
Each periodic worker claims a lease in the metadata plane, renews it while it runs, and stands down when it loses it. A pod that dies releases its work when its lease lapses.
Compatibility is tested, not asserted
Arcois Gateway is validated against an independent open-source S3 conformance suite and against the test suites of several client toolkits. Each passing set is held as a baseline, and a release gate refuses a change that loses one of its tests.
Bring your own object count and we will work through the arithmetic
You already know your object count and size distribution. That is everything needed to work out what your backend would hold after aggregation, before anyone signs anything.