I have an OAuth authorization server hosted outside of Kubernetes cluster. Our micro services are hosted inside K8. We want to authorize the incoming request at the Ingress gateway . Is it possible to build a custom adaptor which can call the authorization server by passing the bearer token from the incoming request header.
I think this is doable by configuring the ingress gateway to process token validation. Please take a look at: Configure end user authentication on ingress gateway
If you aren’t using JWTs we used an EnvoyFIlter that we plug into our Gateway that proxies all requests to our authn server. I wrote about it here: https://medium.com/plangrid-technology/custom-user-authentication-in-istio-67c90458b093
The example doesn’t show a way to configuring the authorization server. I see the token is returned from the github repo , if the token needs to be sent to another service for authorization do I have to write a custom adaptor?
I see the post from Omar was flagged , is it not the recommended way?
@natraj09, here is an blog detailing how your configure the authorization server: https://programmaticponderings.com/2019/01/06/securing-kubernetes-withistio-end-user-authentication-using-json-web-tokens-jwt/ . The blog is based on Auth0 but the configuration should be quite similar for other products.
Our use case is similar to what Omar had shared in the blog. Is implementing the custom EnvoyFilter in form of a inline lua script the recommended approach for such use cases. The management of inline script could be tedious and error prone. Is there plan of supporting such extensibility with a cleaner interface?
Afaik, the solution provided by Omar and PlanGrid is the only way to support other OAuth token type in addition to JWT. I think also that Istio JWT token is based on Envoy JWT filter which is build the same way using Envoy filters (https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/jwt_authn_filter).
On the other hand, you should keep in mind the limitation of filters (That what I can see as precaution from Istio documentation: https://istio.io/docs/reference/config/istio.networking.v1alpha3/#EnvoyFilter). So, keeping a minimal number of filters in addition to running validation test when upgrading Istio should be a good practice.
I would like that a core team member comment on that to be sure. @spikecurtis
Yeah, I echo the caution about EnvoyFilter, as it comes with no guarantees about backward compatibility.
There is some work starting in the Security WG to bring support for “opaque” authentication tokens using a “blessed” Istio API. I don’t have an exact time frame, but you might contact the authors of this doc and mention your interest.
The other thing to mention is that instead of custom Lua, you might consider the Envoy ExtAuth filter.
Thank you Spike for all these details and useful information. I will definitely opt for External Authorization filter as a tactical solution until having the out of box support.
Thanks Rafik and Spike for the suggestion. Will take a look