Documentation embedded in this build.

3. Protect a service

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. Nothing about the caller is ever taken from a header.

A route

A route names a path, the service behind it, and what a caller must satisfy to reach it. The composition you brought up already has several. The application door echoes back the headers it was given, which makes it the easiest one to read:

$ curl --cacert <runtime>/gen/ca.pem \
       --cert <runtime>/gen/admin.pem --key <runtime>/gen/admin-key.pem \
       https://app.<domain>/whoami

What comes back names you, and the attributes the door pushed to a service that has only a header parser.

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. In the composition, one door requires a certificate and another requires none at all — the anonymous door in front of the same application, with any forged identity header stripped on the way in.

A refused request, and a permitted one

Ask the anonymous door with no certificate at all, and then ask the application door the same way:

$ curl https://www.<domain>/whoami           # answers: no identity, nothing forged
$ curl https://app.<domain>/whoami           # refused at the handshake: no certificate

Then ask with a credential that is authenticated but not authorized for the route, and you get 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. It names the subject, the operation, the outcome and the reason, in a hash-chained record.

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