Istio + OAuth 2.0

Security
1

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.

2

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

3

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

1 Like
4

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?

5

@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.

6

Hi Rafik,
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?

7

Hi Natraj,
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

1 Like
8

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.

2 Likes
9

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.

10

Thanks Rafik and Spike for the suggestion. Will take a look

11

I am new to Istio world, but I think a Mixer adapter will be able to do this task using Authorization template
Here I imagine how things should work (please feel free to correct me, I am still understanding this Mixer :slight_smile: ) =>

  • Since envoy proxy(the sidecar inside you container) suppose to do 2 things, one of them is performing precondition checks, so I imagine this flow=>
    1- Sidecar proxy sends instances of kind Authorization template, which should include dimension attributes like ( request.headers(jwt), source IP, client ID, etc…) to the Mixer.
    2- Then Mixer receive these attributes and map them to your Adapter configuration : e.g. map request.header[‘Autheriztion’] to Token and source.ip to clientID … etc this called instance configuration.
    3- Adapter ( which you suppose to write the internal Oauth2 logic on it using Go or any language) will receive these mapped instances/data and perform OAuth logic through handlers and perform required checks using pervious inputs ( jwt/clientid ) and return result to Mixer

Also I think OPA Mixer’s adapter could help you.



12

Hey guys,
I am trying to follow the OAuth 2.0 with Istio, using Envoy Filter, but I am having some trouble with it. My request reaches the ingress and filter, but it’s not redirected to the Authorization service (Keycloak).
I included a similar question here: https://stackoverflow.com/questions/55159887/istio-oauth2-with-keycloak
Anyone with this problem too? If I work with curl, everything is fine, the problem is when I try by browser and follow the OAuth2 flux.

Thank you!

13

Did you find any solution for this?

14

The main problem is that if you want to validate opaque tokens (instead of JWT tokens) you cannot do this without a little development effort.
With JWT, a simple RequestAuthentication resource is enough to do the job thanks to the jwks-uri. But, to validate an opaque token you have to do a query to the IDP to ask if the token is ok.
The only way to do that is to create an external-authorizer as explained here : Istio / External Authorization.

In addition, even if your have JWT tokens, istio will only expect to retrieve them in an authorization bearer header. For example, If your SPA application send this token through a cookie, it wont work with JWTRules. And this is very frustrating.

1 Like