This documentation describes AuthBox v0.3.0-174-g4a160181.

Scenarios

The eleven shapes the box runs in, each with the scenario that stands it up from the images and the proof behind it.

• Protect a service with an authorizing proxyStand a proxy in front of a service that knows nothing about certificates and cannot be changed to learn. One binary and one configuration cover one service, many told apart by name, or a whole Kubernetes cluster as its ingress controller.
• A fleet of edge proxies around a central AuthBoxOne AuthBox in the middle, with proxies and read-only replicas at the edges, each deciding from a signed bundle of the center's authority. No request waits on the center, and an outage there is not an outage at the door.
• Your own certificate authority for a teamA team that wants its own certificates and has no PKI to hang them on. The first boot's wizard stands up a certificate authority, writes the one configuration file and prints a single bootstrap administrator invitation, all on one host the root never leaves.
• A federation across organizationsOrganizations that must work together without merging directories: each keeps its own authority and issues its own certificates. Records carry the origin they came from, trusting a partner's certificates for the handshake never means adopting its data, and an authority that goes quiet stops conferring anything.
• Bring the organization you already haveFor an organization that already runs a directory, a PKI and a mail relay. AuthBox adopts the people and groups it reads and never owns them, trusts the certificates your own authority issues rather than issuing any, and stops counting a directory that goes quiet rather than going stale.
• Sign in with the card you already carryFor people who already carry a PIV or CAC card issued by an authority this box never ran. The door admits the card's sign-in certificate, refuses the same card's signature certificate, checks the issuer's own revocation list, and records a person it has never seen for an administrator to place in a group.
• Your own card, from its own authorityFor a person who holds a real CAC or PIV card: the evaluation image carries the DoD PKI's and the U.S. Treasury PKI's own certificates as the card's issuer sets, fetches their revocation lists from the addresses on the card, mints nothing, and records the card holder on first sign-in.
• Your computer's credential as a cardFor a person with no smart card. On Linux, authbox-agent shows the credential this box issued to your computer as a PIV card in a virtual reader, behind a PIN you set, so Firefox, ssh and every other smart-card tool use it the way they use a real card, and the key never leaves the credential store.
• A machine for a missionFor a team that needs somewhere to work for the length of a mission. Pick a server type on the mission, and the controller stands up a machine only that mission's members can log in to, through the front door, with the card's key. When the mission ends, the machine goes.
• The demoThe demo is one deployment you walk in acts: ask for access, enroll your laptop, present its credential as a card, log in over SSH with that card, file mock documents onto a sealed shelf, and see that the machine holding them cannot read them while your own credential can. A scenario the repository runs proves each act.
• Move labeled data only to the services cleared for itSend a feed of labeled records down one long-lived connection to two services cleared to different levels. The front door decides each record on its label alone, never buffering, parsing, storing or opening one, and signs a receipt for each batch it delivers.
• Hand out classified records only to the clearedHand records of mixed classification only to the people cleared for each. The application labels every answer with one header; the front door compares the label with the caller, replaces whole what they are not cleared for with a plain refusal, and signs a receipt for what it allows.
• A file that stays classified after it is copiedRecords that stay classified after they leave you, whether copied to a partner, a share, a backup or a laptop that goes missing. Each is sealed as it is written, its classification locked to the encryption, and a small door that holds keys and no data hands the key only to the cleared.
• SSH access to your hosts and your cluster's nodesDecide who may log in to which machine, and as which account, with the same policy as everything else instead of keys copied onto servers. Each person keeps one key and presents a certificate that expires in hours, so a lost laptop stops working on its own.
• A laptop with the cable out, or a clusterThe 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.
• Give a service a certificateGive a web server, a test site or an API its own certificate without a person claiming one for it. A project admin creates the identity from the workspace, and the key is born where it is used: on the server through ACME, at the door, or at the courier, which hands it over once and forgets it.

All documentation