This documentation describes AuthBox v0.3.0-133-g71cb5564.

5. Where next

In short

The map of everything after the evaluation: a deployment of your own from the published image, the ten deployment shapes, and what the user guide, the operator guide and the technical and accreditation collections each hold.

You have stood a deployment up, enrolled somebody, watched a door refuse and permit, and taken a grant through both halves of its ceremony. This page is the map of everything else.

Run one of your own

Everything so far was an evaluation, on answers built into the image. A deployment of your own starts from the same published image, authboxus/authbox, and there is no configuration file to write by hand:

$ mkdir -p data && sudo chown 65532:65532 data
$ docker run --rm -it -v "$PWD/data:/data" -p 127.0.0.1:8090:8090 \
      authboxus/authbox -setup -config /data/authbox.yaml \
      -setup-listen 0.0.0.0:8090 -setup-token generate

One volume holds the configuration and the state; on the environment step, press In a container: /data so every path lands in it. From another machine, publish the port to every interface (-p 8090:8090) and open http://<that host>:8090 with the token. On a host install the same wizard is authboxd -setup -config /etc/authbox/authbox.yaml, on loopback with no token. It serves a wizard on 127.0.0.1:8090, asks what the deployment is for and who runs it, and ends by writing one configuration file, the artifacts for the shape you chose, and a single bootstrap administrator invitation. It applies nothing to anything running, because at the moment it runs there is nothing running to disturb. Without a browser, the tools image runs the same engine: docker run --rm authboxus/authbox-tools setup -example prints an answers file to edit. The first boot runbook, in the operator guide below, is every answer the wizard asks for.

The published images are the release's own: authboxus/authbox in both postures (the open one as authboxus/authbox-open), the front door, the courier, the portal, the key access door, the object store and the dialect sidecar, each at latest and at the release's version tag.

A tagged release also ships one signed tarball — the binaries for both postures, every image, the manifests and the unit, the runbooks and a manifest naming every file's digest — which authboxctl release verify checks offline, with no registry and no docker, on a box that will never see either.

The shapes

Ten deployment shapes, each one a topology this product stands up and proves, each with the evaluation that shows it and the smoke that proves it. Start with the one that sounds like your problem:

The user guide

For the person holding the certificate rather than running the deployment: Enrolling with AuthBox, Living with your certificate, Revocation, and how to need it less, Asking for access, Signing, Logging in to a machine, and the console, page by page.

And one story that uses several of the above at once: A day in the harbour watch, six acts that run as a live demonstration, a workshop, or an unattended test.

The operator guide

The runbooks, served in the console: the first boot, backup and restore, break glass, authority rotation, revocation list distribution, certificate renewal, audit export and retention, the proxy, the streams, the key access door, the SSH authority, and the one page to open when a request is refused and nobody knows why.

Technical, and accreditation

The architecture, the configuration schema, the deployment reference and the support matrix say how it is built. The accreditation collection says what was decided and why: the decisions register with every rule and the mutation that proves it, the cryptographic inventory, key custody, the receipt profile, and the zero-trust and control mappings.

Every claim on the product's own page names a proof — a scenario, a make target, a requirement — and a test fails the build if that proof stops existing. That is the thread to pull on when you want to know whether something is true.