Support Client cert and/or endpoint discovery for Auth proxy

[UXabre]

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

[dblock]

@UXabre Help me understand where you come from? Which auth proxy?

[UXabre]

Hi, the auth proxy we're currently using is Kong Ingress Gateway, comparable to any nginx with some oidc IDP. For ease of conversation, let's just say it's nginx as reverse proxy. Still, I'd like to "verify" that it's actually my nginx that is "talking" to opensearch. Via the ip adress verification method available in the security plugin, I can check that this would be my nginx but I don't know the ip address of my nginx instance (in kubernetes) until I instance it. What's more, if I were to apply some more dynamic rules, like pod scaling, the valid ip addresses would change as the load changes in my ingress. So that would require me to use a regex. Now, the regex would need to be similar to my pod CIDR. This means that now any container in my cluster would be able to access opensearch and, via http headers, get admin rights or something.

I love opensearch, and probably most of all for the security options it provides out-of-the-box. I also love kubernetes and I'm looking how to get these two great things to work great together. But maybe i'm the only one that uses auth proxy 😅

Possible workarounds:

• use calico network policies: if i could use it...i would but I'm using AKS in dualstack mode which does not support calico :-( also, that would add an external dependency
• use istio with mTLS and create an access policy to only allow certain namespace with proxies: as this requires mTLS , it would conflict with my mTLS setup I've set-up with opensearch. Also, istio is a pretty huge dependency as well

I hope this clarifies it a bit and thank you for your time in understanding my issue better :-)

Small note: Like I said it seems search guard provides this via proxy2 and I thought opensearch uses searchguard? But this is an assumption as the configuration is pretty similar

[dblock]

I'm going to move this to opensearch-devops

[gaiksaya]

Adding @prudhvigodithi to add more. Thanks!