AuthBox

Documentation embedded in this build.

A laptop with the cable out, or a cluster

In short

The same binary on a laptop with the cable out, one host, a compose file or a cluster. What changes is how many copies run and what starts them, never the configuration language, the posture, or what a decision means.

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 docker run ... authboxus/authbox-eval -evaluate One box with a console, the site and four people to log in as. Once the image is on the laptop nothing is fetched from anywhere.
One host a systemd unit The static binary, one configuration file and one state directory, started at boot.
Compose the recipe the image prints, -print compose One container per binary on one named volume: the box, the front door, the companions, a replica, a second organization.
Kubernetes the manifests a release ships The reference fleet: one writer, three read-only replicas, three proxies, every operator object.
Kubernetes, whole from the source, below The entire worked composition translated to manifests, applied in waves, and smoked by the same phases.

Stand it up

$ docker run -d --name writer -p 8443:8443 -p 8080:8080 -p 8081:8081 authboxus/authbox-eval -evaluate
$ docker run --rm authboxus/authbox-eval -evaluate -scenario companions -print compose > docker-compose.yml
$ docker compose up -d

The first is the laptop row: one image, no network once it is pulled, no configuration to write. The second and third are the compose row: every scenario the image carries comes as a compose file, from one server by itself to two organizations that trust each other. The evaluation runbook says what each one stands up. The systemd unit and the Kubernetes manifests ship with a release, beside the binaries they start.

What the smoke proves

Each row is smoked by the same phases rather than by a check written for that row. The worked composition is staged, brought up, and run through its enrollment, evidence and door phases; the Kubernetes run 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. The reference manifests are applied through a single-node overlay and stand the fleet up on a cluster that is kept, with its fixture keys and every operator object.

The evaluation is proved the same way: every scenario's printed recipe is run verbatim from the built image, each box waited on until it is ready, the console opened, and the recipe's own teardown run. 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