using authservice with ingressgateway to protect multiple seperate individual services in cluster

[r-kotagudem]

@cfryanr Currently below file has configuration that can be applied to one particular application(service) authservice-configmap-template-for-authn.yaml

Could someone help us on how to configure authservice for multiple separate services in the cluster individually.

note service specific callback_uri in the configmap.

I want to achieve below: 1.Authservice at the gateway level to provide a single login flow for all applications inside an Istio mesh, rather than using it at the sidecar level 2.currently if I try to configure the above it applies to all services in the cluster.

Let me know if my question isnt clear.

[cfryanr]

Hi @r-kotagudem, the callback uri can be configured to any path that you like. The Authservice will intercept all requests to that path, so you only need to be sure that it does not conflict with any path that your applications want to serve. You don't need to name the callback uri using the name of any particular service. For example, you could call it /mesh/auth_callback.

When you say "currently if I try to configure the above it applies to all services in the cluster", is that what you are trying to achieve, or are you trying to achieve something else?

Running the Authservice as an ext_authz filter on the ingress gateway will cause token acquisition for all requests that flow through the ingress gateway. If you want to exclude some paths, you can use the include/exclude path configurations in the configmap.

[r-kotagudem]

Hi @r-kotagudem, the callback uri can be configured to any path that you like. The Authservice will intercept all requests to that path, so you only need to be sure that it does not conflict with any path that your applications want to serve. You don't need to name the callback uri using the name of any particular service. For example, you could call it /mesh/auth_callback.

When you say "currently if I try to configure the above it applies to all services in the cluster", is that what you are trying to achieve, or are you trying to achieve something else?

Running the Authservice as an ext_authz filter on the ingress gateway will cause token acquisition for all requests that flow through the ingress gateway. If you want to exclude some paths, you can use the include/exclude path configurations in the configmap.

Thanks for the reply @cfryanr Consider if my cluster has different apps(each app/service has its own clientid ,clientsecret and scopes). How do we configure such with single ingress gateway

Also we would like to use this for knative, I believe inmemory session storage would cause inconsistency when the pods disappear due to inactivity for sometime. Please advice on this.

[cfryanr]

For the use case of protecting different apps each with their own client id and scopes and such, we've been assuming that it would be easier to deploy Authservice as a sidecar. That way, each app (e.g. deployment/statefulset/pod) can have its own Authservice config. That way you can deploy and delete apps without needing to update a central gateway config. Curious what folks think about that.

Yes, using the in-memory session store has some limitations. If the pod containing the authservice is restarted, then all of those users lose their sessions. Those users probably have browser cookies with the actual IDP, in which case re-login would be pretty much invisible to them aside from some quick redirects.

We're currently exploring adding Redis as an option for session storage. In addition to solving the issue with Authservice restarting, we hope that this will make the Authservice more horizontally scalable.

[r-kotagudem]

Thanks for the insight, highly appreciated.

@cfryanr Currently for knative service pods to include authservice container, we need to explore option to use kubernetes admission controllers to inject the authservice each time a knative pod is spinup since knative doesn't support defining multiple container in deployment/definition file.