Sign Flux's events to the Reporter #421

What happens

The estate-scoped artifact sends Flux's events to the Reporter through a generic Provider (chapter 55, from #420). The requests are unsigned and go over plain HTTP inside the cluster, so nothing in one proves Flux sent it.

Two things stand in for a signature today:

• the Reporter's policy admits Flux's notification controller alone, so another pod cannot reach the port where the policy is enforced;
• chapter 55 has the Reporter treat an event as a prompt to read the unit itself, and write a status only from what it reads from the cluster, so a forged event costs a read and changes no status.

Neither is authentication. A Reporter that trusted an event, or a cluster whose policy controller is not enforcing, would let any pod write a release's status.

What to build

The route is signed. Flux's generic-hmac provider signs each request with a key from a Secret in its own namespace, and the Reporter verifies it. What needs deciding is where the key lives and how both sides come to hold it:

• the Platform document names the Secret in Flux's namespace, as bootstrap.flux.artifacts.pullSecret does for the render's pull Secret, and the bootstrap writes it;
• the Reporter reads the same key through a grant of its own.

Acceptance criteria

• Where the platform names the key, the rendered Provider is generic-hmac and references the Secret.
• A platform that names a Reporter and no key is refused, or renders unsigned with the reason stated, as the chapter decides.
• The Reporter (JorisJonkers-dev/delivery) refuses a request whose signature does not verify.
• Both implementations, and the worked example.