gloo-mesh
gloo-mesh copied to clipboard
solo-io
GMG ext-auth-service would benefit from a workload selector
Version
1.2.x (latest stable)
Is your feature request related to a problem? Please describe.
In short the presently generated EnvoyFilter provided by the enterprise-agent when gloo-mesh-addons/ext-auth-service is enabled has no workloadSelector which causes the filter to enforce authentication on all gateways and sidecars.
This might not be desirable in all cases, and might be helpful to instead allow a selector (or label ) to be provided by the implementor or better, have gloo-mesh infer which selector to use somehow.
Describe the solution you'd like
I think it would be helpful having a configurable somehow set here. I can see a use case where I have one set of common labels used as a selector for a NodePortthat also matches what is set on the ingress-gateway. But in a situation where I would want to maybe share that NodePort with another ingress-gateway in the same namespace, but not apply the ext-auth-service using that same label. Ideally it would be nice to be able to specify which selector might be used on the envoyfilter made by the gloo-mesh-gateway- ext-auth-service.
Describe alternatives you've considered
No response
Additional Context
I was able to validate that the selector works (and the disable route option for other gloo-mesh tenets that use this same gateway) by having a few routes running -- one with basic-auth on a gloo-mesh workload in a random namespace using ext-auth-service in gloo-mesh-addons via an authconfig -- another route using no auth on a gloo-mesh workload in a random namespace that doesn’t use ext-auth-service (these routes we have to explicitly set the options to disabled true -- finally using a route kserve/knative, I was able to validate that once the workload selector was set on the gloo-mesh-addons envoyfilter, I could setup a knative-specific gateway with its own label and sideskirt the envoyfilter enforcing authz (or not) on the routes above.
