Support Client cert and/or endpoint discovery for Auth proxy

Is your feature request related to a problem? Please describe.
The auth proxy is very powerful!...but not a lot is provided to secure access to this flow. (only ip address regex) In a kubernetes cluster, there are a lot of moving parts that we need to try and make secure

Describe the solution you'd like
Either we are allowed to enter the service name, which could be used to fetch the endpoints of the service and thus use that to validate if the ip address is allowed. But there might be dragons here as these endpoints can change over time...

Another, probably more robust, way is to use Client TLS verification. Only owners of specific TLS certificate (or a CN that matches a regex) are allowed to pass headers. This is apparently also the way Searchguard's Proxy2 module does it

Describe alternatives you've considered
Alternatively we can have "chains" of authentication flows, for which one chain could use the existing TLS client verification and match it against a CN regex, if this is ok, than it allows to forward to the auth proxy else not.

Additional context
In my use-case, we use both Client TLS authentication as well as Proxy authentication. The former to get machines to log to this device without user intervention, the latter is for users to allow to probe the API or access dashboards

Start by locating the auth proxy entry point and its existing IP address regex validation. Compare the proposed service endpoint discovery, client TLS verification, and authentication-chain alternatives, then clarify one accepted approach and its validation criteria before implementation.