Comments (10)
Redis seems like a good place to start.
from authservice.
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.
from authservice.
This was moved to review in progress quite some time ago. Has any progress been made on the review?
from authservice.
We've started working on Redis support.
from authservice.
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.
from authservice.
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.
from authservice.
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
from authservice.
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.
from authservice.
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.
from authservice.
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
from authservice.
Related Issues (20)
- authservice pod never reaches ready state HOT 3
- Create authservice 0.5.0 release HOT 1
- Example: jwks_fetcher: Cannot find field HOT 2
- support for oidc client_assertion as one of the client authentication methods HOT 2
- "Retrieve token: invalid form" in a loged-in session window. HOT 4
- Websocket connections not possible because '/path?access_token=<JWT>' not handled in ODIC filter
- Feature Request - Support Redis TTL HOT 1
- integration with ADFS fails due to unable to shutdown connection for ssl stream HOT 2
- Better connection management for http host
- Concurrency Issues HOT 1
- Doc/example desired for trigger_rules
- Performance issues under minimal load
- HTTP Redirects end up with lost token information HOT 3
- Redis error during high traffic times
- How to set the client secret from an existing kubernetes secret? HOT 1
- Question on implementing multitenancy with istio/keycloak/authservice HOT 1
- Other flows particularly client credentials flow(machine2machine) HOT 1
- Does authservice only works for SPA app or can work for server side calls from client?
- Failed to login, get "Oops, your session has expired. Please try again." HOT 2
- Merge authservice-go into the main project as a v1 version HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from authservice.