Documentation embedded in this build.

A fleet of edge proxies around a central AuthBox

What it is for

One AuthBox in the middle; proxies and read-only replicas at the edges of the network. Each edge holds a signed bundle of the center's authority and decides from what it holds — there is no call to the middle while a request is in flight, so no request waits on a link across the country, and an outage at the center is not an outage at the door.

The center publishes its live store on a cadence, and what happened at the edge comes back: signed receipts, and the door's own sealed audit segments, so a refusal decided at the edge is on the console of the deployment whose policy decided it — stored as the door signed it, shown beside the center's own record and never merged into it. An edge that goes dark keeps enforcing exactly what it was given until its freshness budget lapses; then it steps out of rotation rather than failing open, and the fleet is short one edge instead of wrong at one edge.

This is not a cache in front of a central decision. The decision is made at the edge.

The topology

A central AuthBox publishes signed bundles outward; each edge decides there, and thin return paths carry receipts back to the center.

                    +-----------------+
                    |  CENTRAL BOX    |
                    |  publishes on   |
                    |  a cadence      |
                    +--+----+------+--+
             bundle     |    |      |     bundle
        +---------------+    |      +---------------+
        v                    v                      v
   +---------+         +----------+           +-----------+
   | PROXY   |         | PROXY    |           | REPLICA   |
   | decides |         | decides  |           | read-only |
   +----+----+         +-----+----+           +-----+-----+
        |                    |                      |
        +---- receipts, sealed audit segments ------+
                      (back to the centre)

The reference deployment is one writer, three read-only replicas and three proxies.

Stand it up

$ docker run --rm authboxus/authbox-eval -evaluate -scenario fleet -print docker | sh
$ docker stop writer        # the replica keeps answering
$ docker start writer       # and adopts the next bundle within one poll

A second server that keeps answering: the box, the front door, and a read-only replica on port 8445 that adopts the bundle the box signs onto the shared volume every thirty seconds. Stop the writer and the replica keeps answering from what it holds — the console included, for the evaluation image's people. The evaluation runbook says what each container is and how it ends.

What the smoke proves

The evaluation's own proof runs the printed recipe from the built image: the replica's readiness answers with the writer running and with the writer STOPPED, and after the writer starts again the replica logs a bundle adopted at a newer serial than it held.

The fleet's proof goes further. A writer signs and publishes a bundle; a replica already running and polling adopts it live, so a record present only in the newer bundle becomes visible without a restart; and an aged replica whose bundle has passed its maximum age reports itself not ready, leaves rotation, and goes on enforcing exactly the data it holds. Leaving rotation rather than failing open is the whole claim, and it is asserted on the wire an operator's load balancer reads.

The Kubernetes proof applies the reference manifests a release ships to a real node — one writer, three replicas, three proxies, every operator object, across three namespaces — rather than only linting them, and stands the same fleet up on a cluster that is kept.

Read on

• The operator guide's runbooks cover bundle publication and what a stale replica means for a load balancer.
• The federation scenario is the shape to read next when the edges belong to somebody else.