Support other kind(s) of session storage, e.g. Redis or MySql or something

[cfryanr]

Authservice server-side sessions store things like your ID token, access token, refresh token, and the url that you originally requested before you were redirected to auth. In the first draft, this is all stored in memory. This has two implications for large-scale production usage:

1. If the container restarts, those users loses their sessions. This isn't too bad if your IDP has its own sessions with those users, because on their next request the Authservice will redirect to the IDP which will immediately log them in without showing any UI.

2. If you are scaling the Authservice horizontally, then you need to use session affinity to ensure that each session always lands on the same Authservice instance. Again, if your IDP has its own sessions, then its not too big of a deal for a user to land on the wrong instance of Authservice, as they will transparently be logged in (again) after some redirects. This just puts unnecessary load on the IDP.

Moving session storage to a shared storage layer would fix both of these issues.

That opens the question of which solution(s) would be preferable? e.g. Redis, MySql, others? How do other aspects of Istio do things like this? How is this typically done on k8s?

[mhite]

Redis seems like a good place to start.

[cfryanr]

We've started working on Redis support.

[mhite]

Hi, @cfryanr - This is exciting! When we have session storage support available with Redis, will authservice support letting us run it in its own namespace and no longer require container adjacency with Istio gateway pods and/or sidecars? I imagine the EnvoyFilter authn filter configuration could be pointed to a hostname in a different namespace rather than its current destination of 127.0.0.1.

[cfryanr]

Hi, Authservice doesn't technically require that it is deployed in the same pod today. The communication between Envoy and the Authservice is all GRPC-based, so it can happen over the network, as you pointed out.

There would, of course, be potential security and performance implications for you to consider before moving it to a different pod. The GRPC calls made by Envoy are not themselves using TLS, as far as I know, so it would be worth understanding how the mesh will protect the GRPC traffic. And keep in mind that every request (except those excluded from the ext_authz filter configuration) will cause a GRPC request to the Authservice, so you'd be potentially introducing a little network latency to every request. Those concerns should be manageable.

[mhite]

Ok, thanks for validating my assumptions regarding future deployment scenarios!

In some early discussions I've had with colleagues regarding authservice, we've identified not only the Redis support (or rather out-of-process state persistence) as highly desirable, but also the ability to loosely couple the maintenance/operation/upgrading of Istio from that of authservice.

I understand your caveat about security and performance implications. It hadn't occurred to me that Envoy auth filters might not support encryption. Does the Envoy grpc client[1] not support TLS?

As for performance, there is probably a decent way of optimizing this for gateways but probably not sidecars. For gateways, I am thinking you could probably create a pod affinity[2] between Istio gateways and the authservice pods. You'd also want to use a service topology[3] to keep traffic local instead of sending it to a random pod for the authservice.

Not perfect, and maybe better to just co-locate them as you suggest. So...

If co-locating the authservice as a container in the gateway or sidecar pod was a must, we thought creating a custom mutating web hook that injects the authservice would be a reasonable approach. All the documentation we've seen thus far talk about having to manually modify Istio. Do you think an authservice injector might be useful?

Sorry for bombarding you with a bunch of questions but we're all a bit excited over here. :)

[1] - https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/core/grpc_service.proto#envoy-api-msg-core-grpcservice [2] - https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity [3] - https://kubernetes.io/docs/concepts/services-networking/service-topology/#using-service-topology

[cfryanr]

Just to be clear, co-locating is definitely not a “must” today or in the future. It is designed to be flexible and give you options in how you would like to deploy authservice. If you would prefer to deploy the authservice as a separate deployment, that should work. I’d only recommend that you take the time understand/measure the other concerns that I mentioned.

I’m actually not too sure about how envoy does TLS for GRPC. I wonder if it just doesn’t, and then assumes that all traffic will be sent through the service mesh and transparently encrypted via mTLS by the mesh? If you could point me to any resources about this, it would be appreciated.

That said, if you did want to write an injector, it should be pretty easy. We wrote one to get a feel for it (not to release) and didn’t run into any roadblocks. We did ours as a mutating admission webhook controller. It could mutate pods, or statefulsets, or deployments, or whatever you prefer. You could write it to only act upon certain namespaces and/or labels, for example.

[jeason81]

Is there an example of the session affinity you're describing in option two? Is it DestinationRule that specifically targets the authservice kubernetes service? I've tried applying this destinationrule following guides for Istio sticky sessions and haven't had any luck.

[jpweber]

This was moved to review in progress quite some time ago. Has any progress been made on the review?

[cfryanr]

This was moved to review in progress quite some time ago. Has any progress been made on the review?

Redis support was merged to main in July of 2020.

[irefaat]

This was moved to review in progress quite some time ago. Has any progress been made on the review?

Redis support was merged to main in July of 2020.

The Redis Session Storage still in Progress, Would you please advise when it will be ready?

Thanks

https://github.com/istio-ecosystem/authservice/projects/1

[nacx]

Redis storage is ready, and there is an interface to add other storage backends, so this issue can be closed now.