AuthBox documentation — Scenarios

Documentation embedded in this build.

A laptop with the cable out, or a cluster

What it is for

The same binary in every row below. What changes is how many copies of it are running and what starts them — not the configuration language, not the posture, and not what a decision means.

This is not five products. One binary, one configuration file, one posture.

The topology

There is no diagram here, because the point is that there is nothing to draw: the shape is the same in all five rows and only the count and the supervisor change.

Where What you run What comes up
A laptop, cable out make demo then make run One box with every capability, served from a locally built binary, no network at any point.
One host a systemd unit The static binary, one configuration file and one state directory, started at boot.
Compose make all-in-one Writer, console, courier, proxy and mail relay with their own fixture PKI, then a live smoke over all of it.
Kubernetes kubectl apply -k deploy/kubernetes/base, or make kind-up for a cluster of your own The reference fleet: one writer, three read-only replicas, three proxies, every operator object.
Kubernetes, whole make kind-all-in-one The entire compose composition translated to manifests, applied in waves, and smoked by the same phases.

Stand it up

$ make demo && make run        # a laptop, no network at any point
$ make all-in-one              # the composition, on docker compose
$ make kind-up                 # the reference fleet on a kind cluster you keep
$ make kind-all-in-one         # the whole composition, translated to manifests

make demo and make run need nothing but a Go toolchain and a checkout — dependencies are vendored and the build makes no network call. The other three need docker, and the kind ones need kind and kubectl.

What the smoke proves

Each row is smoked by the same phases rather than by a check written for that row. make all-in-one stages the composition, brings it up, and runs its enrolment, evidence and door phases; make kind-all-in-one hands that identical staging to a translator, applies the result in waves, and runs the same phases against it — which is what makes "one product, two supervisors" a demonstrated claim rather than a design intention. make kind-up applies the checked-in reference manifests through the single-node overlay and stands the fleet up on a cluster you keep, with its fixture keys and every operator object.

The laptop row is proved by the build itself: the open-posture and the FIPS-posture builds are both produced and both run, from vendored dependencies, with no network available.

Read on