Fix inconsistencies in receiver guide

[kingdonb]

Fixes fluxcd/flux2#2240

And some other minor issues I found while running through the webhook receiver guide:

• A tab character at the end of a copy-paste block that fouls things up
• The name of the receiver service is misnamed above a copy paste block

[kingdonb]

• [X] Let me also fix this one before we merge this:

• https://github.com/fluxcd/flux2/issues/2240

• [X] and also, perhaps add a note about ingressClassName

• [X] and add an example that shows how to do image repository webhooks

ImageRepository webhooks aren't much different, but they are different enough to fail at discovering exactly how to do it.

[kingdonb]

This should be good to merge 👍

[kingdonb]

There is some feedback about the networkpolicy:

• https://github.com/fluxcd/flux2/issues/2240#issuecomment-2462593628

Maybe should address this before merging. I am not very proficient in network policies so I'm not terribly surprised if I haven't done it perfectly.

[kingdonb]

I am thinking of including a barebones networkpolicy that is sub-optimal, would be possible to exploit, and writing something like "Do not use this naive network policy on multi-tenant clusters. Configuring secure network policy in a multi-tenant environment for cert-manager is left as an exercise for the reader."

It might be better to just punt the network policy issue and leave https://github.com/fluxcd/flux2/issues/2240 unresolved, but I'd really like to get it nailed down. But I am wary that the more complicated I make the policy, the more likely it still does not fit everyone's potentially very different and unique environments, and so people will just copy and paste the wrong thing.

[kingdonb]

It sort of looks like cert-manager has its own helm values for network policy, which you can just enabled: true and get the behavior. But I tried that and it didn't get me anywhere. Maybe some adjustment is needed to accommodate the flux network policies in addition to those.

I will give this another try tomorrow, and if I can't figure it out, I'll remove the network policy stuff, or scale it way back.

(I personally would be happy with the sub-optimal network policy that allows anyone to communicate with the pods labeled http-01 - nobody is going into the flux-system namespace and launching arbitrary pods or relabeling pods unless a cluster is already thoroughly compromised, so I don't see that as a problem. But I am not sure I understand how network policy works so I'll do some testing before I put that in the docs.)

[kingdonb]

The answer was a lot simpler than I thought. It even works on my "not such a good example" environment.

I don't know where we got the idea that a reverse policy was needed.

[fluxcdbot]

Successfully created backport PR for v2-4:

• 2088