undefined in redirect URL #23
Comments
|
Maybe something wrong with my token, I see |
|
here is my envoy filter: |
|
Great! Istio support would be fantastic! My guess is The header should contain everything after the host in a complete URI including query params. There are alternatives if you can inject into the request the complete URI (scheme/host/path/query) as a header then you can use |
|
I've tried this config as well: and still the same |
|
Given that istio is based on envoy as well as ambassador set the path prefix the same way you did for ambassador...ie: After using the above route the request uri will be set by the app resolving that issue. If this works I'll probably rename the route to be |
|
@travisghansen thanks, that was it, I think that URL idea crossed my mind once but I didn't dare to try it :) Now getting 503, although OIDC server logs show success. We already have another solution where my colleague actually partially rewrote ambassador-oidc to do what your project is doing more or less - I mean part about injecting headers and some more :) He is passing full id_token as header, is it also possible here? Just some more docs for you. And virtual service (backend routing): |
|
Yeah you can pass the full I think I had some way to specify whether to send the encoded or decoded value but don't recall the specifics...which do you want? |
|
As an FYI I've been working on some other projects the last few weeks but I'll likely have some time later this week to revisit |
|
Colleague used raw token, so I guess it needs to be encoded, can verify tomorrow. New release sounds great, hope I provided you with enough input so far at least for documentation. Istio is quite powerful but also quite a lot of work to setup properly. So, I guess if I specify id_token here, it will be available to the beackend services under Authorization header And then can be used for istio end-user authentication and finally we should be able to restrict access based on groups as id_token will have those claims |
|
Yeah, I believe that gets sent down encoded as the full jwt but you'll need to confirm. |
|
We are kinda stuck - any idea why 503 can be returned from eas after successful authentication? I think this is the full log of the request: |
|
Hmm, that's not providing much feedback is it :( I'll have to dig through the code and look for cases where we explicitly send 503 otherwise I've got something that isn't defensive enough. |
|
I'll add more debug code it there but it appears you're missing the csrf cookie. I'm not sure however why you would be missing that.. |
|
Not much feedback indeed. Depending if we were putting original application behind http or https, we were also hitting infinite redirection loop and my colleague also thought it may be related to cookies, more specifically to cookie domain but I really don't know - worked fine with ambassador. |
|
Do you have to explicitly allow the cookie header to be passed down with istio? Can you send the output that includes all the headers etc to review? |
|
I will try again maybe tomorrow and send all logs I can find. But we have spent quite some time on this and have some setup working, so can't guarantee, although using eas would be preferrable as it is supported versus our quick hack. |
|
Sounds good, thanks for all the feedback! |
|
Sorry, I am already busy with other stuff, if something changes I will come back with more updates or perhaps you will test it on istio yourself by then. |
|
Ok, I'm going to snap another release this week actually. I have 0 experience with istio but my understanding is it's for traffic within the cluster (east/west) vs external traffic coming in (north/south). In that vein it seems counter intuitive to use oidc in a service mesh so any clues you can provide to your setup would be great. If I have time I'll poke around with it and see what I can figure out. Thanks! |
|
That's correct, the only thing since some release ago they also provided they own ingress for north/sourth traffic, so we added EnvoyFilter. It's quite a bit to set up, but overall steps:
Basically, if EnvoyFilter has listenre on port 80: and you have Gateway on port 80: Then, any service refferring to this gateway will be protected by external auth service (notice And if this works (that's where we were getting 503 from OIDC plugin), then we used token claims and more istio-specific RBAC rules to separate tenants and users |
|
Ok thanks for the background info. I'll see what I can figure out! |
|
Please drop a line if you manage to get it working with Istio. We got some extra requirements and now end up with auth proxy per tenant/per app as our proxy doesn't support multiple client IDs. So, a single instance of eas with multiple clients would be pretty great if it works :) |
|
Working on a few updates now...gonna try and get istio up and going in a test cluster. |
|
Thanks for the effort, ping me if I can help - understanding Istio took some time and I am still not super comfortable I guess but better than before. |
|
Yeah sure, just prepping my test cluster. Been working on a few other items with the project so far and got those wrapped up. Moving to this and ambassador now (ie: envoy).. |
|
Do you by chance know how to create a |
|
I am not sure what you mean. By default, you can talk to the outside endpoints. Only if you restrict outside connections you may have to specify extra rules like here to allow access to external services. |
|
Yes, but configuration of the authz plugin requires a cluster. Looking at the resultant file from ambassador it creates an arbitrary cluster with whatever ip/port you put in the configuration of the AuthService. As I want to point to my development machine while debugging this seems to be the easiest approach although there are others.. |
|
Ah, now I see, I don't know, I didn't even dive into cluster syntax much, just figured it's service port and name and used that. I've never used this tool, but maybe you fancy trying it :) https://www.telepresence.io/ - basically for debugging apps running on k8s but using your local connections if I remember right |
|
Just looked at their demo - you expose your local server inside kubernetes, so I guess it will cover your use-case pretty well |
|
I'd like to thank you in some way, I checked https://github.com/sponsors maybe you want to join? Or send me some payment request for dinner :) |
|
Nice! Glad it's working now. You really made me think on that one :) thanks for the offer of support but I'll respectfully decline but accept any contributions you make to the project ;) As an FYI, I'm deprecating the I'm also going to test Lastly, regarding the set cookie issue I'm guessing istio is using an older version of envoy maybe? Thanks for the assistance getting this one going! Envoy support is pretty great feature addition! |
|
I feel quite stupid, but while trying to setup server-side tokens, I realised that we still have to specify token id in Will you add this part as well or shall we stick to our fork for now? |
|
I'm commenting it for now. I may add an option to control it eventually if needed. For some reason I thought you were going to add pcb rules to isolate clients in a single token. You'd end up with a huge token though with any number of clients. Can you remind me of the goal/approach you're taking and I'll see if I can think of anything that may help. With istio isn't it possible to apply the filter a little more directly so you can alter the prefix per service? Regardless you shouldn't need multiple installs of eas itself but perhaps several tokens (ie: token per service). |
|
I've confirmed this behavior works FYI: This example happens to be using a server-side token, but when using a full |
|
So, we want multi-tenant, multi-user, multi-application separation =D. When I go to url More specifically the flow is:
So, question is, can you somehow specify multiple tokens with this for eas service? The approach I tested with pbc was good for multi-tenant setup (ignoring the length of the token) but then all users of the same tenant would be able to acess any application instance, so we needed something more advanced like istio. |
|
So at what level do you want
And at what level does istio allow you to apply/direct filters? |
|
One client per tenant is what we are aiming for, so Filters are tenant-level as well (per namespace). |
|
Maybe good to add - if we deploy one instance of eas per namespace, it will work, but wondering if we can deploy single instance that would be shared between all namespaces. |
|
So if the filter is applied at that tenant level what's the issue? Simply specify the token details (either in the URL or in the header per the example I just sent) on the per-tenant filter definition..am I missing something still? |
|
My brain isn't working anymore, for some reason I assumed |
|
LOL I've been there! Yeah so I'll commit my code with the header configuration and then you can use the syntax I mentioned above. Alternatively, are you using a single oidc provider/instance with the same client_id etc for all tenants? Meaning, is there only ever 1 |
|
Nope, we will have client_id per tenant (although started testing with a single client_id). Our old/current setup on VMs has client_id for every application for each tenant and each application was handling OIDC connections by itself. We are trying to optimise on kubernetes. |
|
Ok then yeah setting the token on a per tenant filter sounds like the perfect solution. I'll snap a release and you can try it all out! |
|
Do you have example healthy sentinel output? eas can't talk to sentinel, but if I am not mistaken it's due to sentinel not being up: probably some istio issues, will try to drill down tomorrow, but helpful to compare to good output |
|
Snapped |
|
This is all my redis sentinel logs show: |
|
Thanks a lot, I will test tomorrow and report back, have a good evening if you are in the same time zone :) but suspect you are working somewhere in US |
|
Yeah, I'm in the Western US :D |
|
Thanks again @travisghansen, everything works fine, redis didn't work due to our default deny rbac policy. Now filter is much cleaner with |
|
Nice! Anything left on this issue to address or should we close it down? |
|
I think we can close it, I will open another one if something comes up :) |
|
Thanks for the support and kind words! I'd love an update after you get more usage out of it. |
|
I am planning to write a blog post, trying to draw a diagram about our set up and describe it a bit later, will share once I am done |
Trying to make eas work with istio, almost got it working (I will share docs later), but getting undefined appended to redirect URI for some reason, any idea what that may be?
Logs from eas (notice
bookinfo.dev.k8s.hal24k.nlundefined):Somewhere here, but not sure exactly what is the problem
external-auth-server/src/plugin/oauth/index.js
Line 140 in 8d97265
The text was updated successfully, but these errors were encountered: