Documentation embedded in this build.

5. Where next

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 a worked deployment from a checkout. For a deployment of your own there is no configuration file to write by hand:

$ authboxd -setup -config /etc/authbox/authbox.yaml

That 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.

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 repository stands up and proves, each with the command that stands it up and the smoke that proves it. Start with the one that sounds like your problem:

• Protect a service with an authorizing proxy
• A fleet of edge proxies around a central AuthBox
• Your own certificate authority for a team
• A federation across organisations
• Bring the organisation you already have
• Move labelled data only to the services cleared for it
• Hand out classified records only to the cleared
• A file that stays classified after it is copied
• SSH access to your hosts and your cluster's nodes
• A laptop with the cable out, or a cluster

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.