Documentation embedded in this build.

3. Protect a service

In short

Put a service behind the front door and watch it refuse a request, then permit one. The door decides from the same policy as the rest of the deployment, signs a receipt for every request it forwards, and never takes the caller from a header.

You hold a certificate from step 2. Now put something behind the front door and watch it refuse and permit.

The door is authboxproxy: the same binary in every deployment shape, standing in front of a service that knows nothing about certificates and cannot be changed to learn. The caller's identity arrives already verified, the decision comes from the same policy the rest of the deployment uses, and a signed receipt rides every request it forwards. Nothing about the caller is ever taken from a header.

The door scenario

The door evaluation is the box with the front door in front of it, on its own image, deciding from the bundle the box publishes. Start it in place of step 1's box:

$ docker rm -f -v writer
$ docker run --rm authboxus/authbox-eval -evaluate -scenario door -print docker | sh
$ docker logs writer

The door answers on port 8444. What it fronts is the box's own console, which is a real service behind a real door: the door ends the caller's certificate, decides, and forwards with the verified identity and the receipt.

A requirement

A requirement lives on the operation, not in a policy file off to one side: a route declares what a caller must be or hold, and the same evaluator decides it that decides everything else in the deployment. The console's pages each declare theirs, and the door holds every caller to them before the box sees the request.

A refused request, and a permitted one

Ask the door for the console's directory as eval-operator, then as eval-reader. The operator is let through. The reader is authenticated and not authorized for the route, and gets a plain refusal — and no explanation. The reason is in the audit record, naming the clause that decided it, and it is deliberately not in the response: a refusal that explains itself is an oracle for probing other people's standing.

Find that decision on the console's audit page as eval-admin. It names the subject, the operation, the outcome and the reason, in a hash-chained record. The door keeps a trail of its own beside it, with the permit each receipt was minted from.

Where this goes next

The same door covers one service, many services told apart by the name they are asked for, or a whole Kubernetes cluster as the ingress controller. That is the authorizing proxy scenario.

Next: Your first mission