Cloud Native Computing Foundation KCD UK 2021, 18 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Advanced Authentication patterns at the Edge – Denis Jannot 1.2.2

Description

With the spread of micro services, it becomes a best practice to manage the authentication at the Edge (using an API gateway) instead of implementing it independently for each service. But this approach also introduces new challenges:
- how does the application know who the user is ?
- how can the application get more information about the user ?
- how can the application force a logout ?
- what about the authorization ?

In this talk, Denis will cover the different authentication mechanisms (OAuth, JWT, ...) and show how to overcome these challenges with practical examples and demos (passing user information using headers generated from claims, performing authorization with OPA, ...).

A

Okay, so next up we have denis and denise going to be talking about advanced authentication patterns at the edge.

B

Hi everyone welcome to this session about advanced authentication patterns at the edge. I am donijano director of field engineering in emea at solo.io. So, let's start with a little bit of background. Obviously all of you are aware that applications are now like developed with micro services, and I would say that most of you will agree that these micro services tends to now run on cubans clusters and one of the first questions. People are asking as soon as they start to deploy the application on kubernetes is.

B

How do I expose my application to the outside world and uh the standard answer for that in the kubernetes world is to use an ingress controller like nginx or hp proxy, or something like that and it works like it. You can expose your service, you can secure it with tls. You can do some basic routing, but um very quickly. We have more and more applications deployed in the cubans cluster and each team reinvents the wheel in terms of um managing the authentication, for example.

B

So you have like one application that wants to secure the access with or2 another one want to use like jot tokens. Another one want to use like api keys or even like a mix of different options, and they also need some capabilities that you generally find in a traditional api gateway that runs outside of kubernetes, some things like rate limiting uh web application, firewall and and so on.

B

So there are like different challenges right, so each team reinvent the wheel like I said, the implementation in fact is even different, like one team using java, another one like he's doing node.js, and so they would use like different libraries to do the same thing right and uh instead of that, uh I think everyone would agree that application teams should focus on the business logic instead of spending time uh on this uh authentication mechanism and uh also the security team, uh doesn't have any visibility on what's configured for each application, so it becomes quite difficult for them to understand if there are any potential security issues there and- and as I said, you know you- you still need some other security mechanism and you need to implement them outside of the the cubans cluster.

B

So so what about like using a kubernetes native api gateway? Instead of that?

B

So the idea here is that you, you would perform the authentication uh at the gateway level um and you you would have like different options like or like job tokens, api keys and so on, and basically the api gateway performs the authentication and then pass some information to the backend services to let them know who is the user that has been authenticated, for example, that could be, like uh I add, like a header uh with the user email, for example, or other information.

B

Basically any information that you get from a claim that is, in the token provided by the end user or the job token returned by the old provider, for example. And what's nice as well, is that these kubernetes api gateways they can generally do much more than just authentication right, so we can do like right, limiting uh waff, but also like things like transformation and so on, and you will see I will do like uh multiple demos to to try to to demonstrate that in a nice way.

B

These api gateways can also be used. They can run inside the qs cluster, but still be used to expose applications running in legacy environment like in vms, for example. They can also be used to expose modern services uh running in functions like in in london, for example, they can discover these lambda functions and and expose them to the outside world.

B

So, like a lot of benefits, authentication performed at the api gateway level, the team can now focus on the business logic. Everything is configured through kubernetes custom resources. So that's why we call it like a kubernetes native, and that means it's github's friendly right.

B

I can have all the yammer corresponding to the way I want to deploy my application on kubernetes in a gita repository and at the same time, the yaml corresponding about the way I want to secure my application, so the configuration of the gateway in the same repository, which is very nice- and I will show you some examples very soon- and other mechanism can be enforced, also at the gateway level and- and you have like nice visibility for the security team right, they can go and look at the gateway, configuration and understand very quickly about how the access to each application is is secured.

B

So in that talk, I will focus on our kubernetes native api gateway, which is called glue edge and blue edge is based on envoy. I am sure that most of you are familiar with uh with envoy, and I will speak about it like in a minute, but basically glue edge is like a management plane, a control plane, sorry for envoy and android is the data plane and you configure everything.

B

As I said, through custom resources in kubernetes blue edge reads this configuration and translate that into envoy configuration, and if you look at the architecture uh you see on the on the left, uh the envoy piece, and you see these different boxes that represent filters. So in envoy a request comes in and it goes through a filter chain and each filter in the chain can uh modify the request in one way or another. So, for example, the request comes in and you want to perform authentication.

B

Then this filter will not perform the authentication by itself, but it will call an external authentication server that will perform the authentication and say yes or no. Do I want to accept or not this call the same. If it's accepted it can go through a rate limiting uh filter that will color write limit server that will define if the limit is rich generally, this server and it's what we do in blue edge is using like redis to persist information about the request and to be able to determine if the limit is is rich.

B

And then there are like many things that can be done directly in envoy. In the filter, without even calling like an external component and that's what we we have done like, we have created like a filter for uh interacting with lambda function, another one for performing transformation, another one for uh revolution, firewall uh for ju out joe's authentication. We don't use the external audition server for that. We will perform that directly in uh envoy, so we there is like an open source version of uh glue edge.

B

But if you use the open source version, then you have to build your own external authentication server, your own right, limiting server, and you don't get all these filters. You get some of them, but you don't get like the web option firewall or jot, and basically everything that is really related to security is in the enterprise version and that's what I will use in in the demo.

B

So why envoy? First of all, it's coming from a neutral foundation, the cncf the same as kubernetes. So there is no one single company that drives their own map of of envoy.

B

It has a you know, very large community. It is used at scale by you, know many companies. It's really designed to be dynamically configured through a control plane. That's also why you see it like very commonly used in service mesh. Most of the service mesh technologies are using like uh envoy.

B

The most popular one is to obviously it's based on it, which is also a good reason for adopting like a an api gateway based on envoy, because uh when you you will adopt service mesh in your future, and I think, like most of you, will at some point uh then having the same technology for the gateway and for uh the the mesh allows you to have like the matrix in the same format, allows you to to debug the issues the same way and so on right.

B

So it's uh I think, it's very interesting to invest on on a gateway uh based on based on android. For all these reasons, so when I say cuban native- and I say we can, you know- drive the configuration through kubernetes resources.

B

Basically, this is what I mean right, so you will define uh in a virtual service uh custom resource uh which domain you want to listen to like here. I say I have a request, starting by slash app one. I want to perform authentication and the authentication is defined in this external uh object and I want to delegate the action to this uh root table so that the team can be responsible for managing a specific domain.

B

Then the application team can manage uh all the different uh paths like they can have different routes for different uh micro services and so on, and then you can use like an external object to to define the way you want to authenticate the user. And you see here we have a simple example with over. Will we will go through that in the demo, but you can also chain together multiple steps uh in the uh configure, and we will also see that at the at the end. So.

A

B

Into the demo, because, I think is the best way to understand the benefits and to learn about how glue edge is working.

B

Okay, so in this environment I have a cubans cluster, and uh if I look at my pods, uh I can see that I have this glue system namespace, where I have different components. Some of them are optional and I won't go through the full details. But basically, what you have to remember is that get the gateway proxy pod is envoy.

B

We have like the control, plane components here, and here we have the external authentication components that is running there. We have the right limit components here and both of them can use redis for different purposes.

B

So what I'm going to do here is that I deployed the key clock already and in this uh server, and I will configure it just like with these few commands, and you see it will create, like a user one with the password password and another user tool with the same password, but they will have two different email addresses right. You see the first one as an email address that finished by solo.io, while the second one has an email that finished by example.com right.

B

So it looks like that uh I have like blue edge and that will use keyclock. You know for the authentication, so I can create like a kubernetes secret, that uh contain my um key clock secret, and then I create this uh odd config that I spoke about before so in this uh odd config. You can see that I have like the url of my application, the url of key clock. You know just like basic information about how to contact and interact with uh with key clock, and then I have my virtual service.

B

You remember. I described that just before it's one of the most important custom resource in glue edge and you can see here. I will add this option to it. So to say, when I have a request uh with uh starting by slash, then I want to send the request to the book info product page and I want to perform authentication using the uh hot config that I have like uh just created before so now. uh If I uh open like chrome, I will see you know.

B

I have ssl here and I can authenticate with user one in the password password and I have access to my application. So you see it's very easy. I was able to configure it it's a very simple case. Right, I just want to to secure the access with uh or2, but there will be at the end. I will show you like something: a little bit more advanced and even using like authorization and so on. But before that I want to show you also a few other capabilities that we discussed before.

B

Let's say I want to apply right limits, then I have another custom resource that that uh case it's called like high limit config. I say I want to have like a limit of 10 requests per minutes and I don't have any specific key right. That's a very basic example, but I could say I want to limit to 10.

B

If I have a header um with, I don't know: 10 antiqual, tenant, 1 or things like that right and I could have like a lot of different combinations uh of rules uh to to have like really fine grain right limiting. But here I just show you like a basic example: you create a red image.

B

Config, like we created the art config before, and in that case I I reference the red limit config here, so I know that it's applied to this root and you see you can do it here at the root level and that will apply only to this root, but I could put this option at the domain level and then it will apply to all the roots. So we have like a lot of flexibility uh here.

B

So if I just like refresh many times you see after 10 times, I get this 429 response codes, meaning that I've been rate limited right. So I can, you know, delete this basic rate limit config, and here I can update it and you know give also like different options depending if I am like authenticated or not right, I would say if I am an anonymous user, I want to have like just five requests per minute, but if I am authenticated, then uh I can have like uh 20 requests per minute.

B

So, as I said, you can have granularity about. You know different editors of combination or you can have like. Also this option where um you you set like different rules for different users or different rules for authenticated, not authenticated. You see here. I am not not authenticated and I get like this um rate limit after uh just uh five uh requests, and another thing we spoke about before is like a web application firewall right. So what we did is that we took mod security, which is very popular and we put it inside an envoy filter.

B

So that means that now I can update my virtual service and I can add any uh mod security rule right. So here I can say I I don't want like uh any payload.

B

You know bigger than one byte right, so it's just like for demo purpose. Obviously, but you see it's an example: you can limit the size of the payload, you can white list, some ip addresses range, or you know this kind of things right. So now, if I uh run the curl command- and I just like send a body request right with some data- it will be directly bigger than uh one byte right and you see I get this error right. I I get it's refused and I get an error message telling me.

B

You know why it has been rejected by uh my web option firewall. There could be other options like you could uh block certain user agents, for example right. So if I have a user agent header with a value scanner, then I want to reject it right. So again, I just send like a curl request with this user agent and I am blocked by web application firewall. You have like a lot of different options. I'm just like giving you like a very quick uh overview.

B

Another thing that is really nice is the way we can interact with the request right. So, for example, here you know we said we want to specify like a rate limit, and we just got like this 429 error right. So it was not really nice. You know you just get this error.

B

We could say when there is a response code 429, then I want to change the body right and I want to change the body so that now, instead of like this uh just for 29 error, I get like uh a 200 response, but I have like a body that uh displayed that in a in a html format, that is like a little bit uh nicer.

B

Oh in fact, I put it in this uh user applications.

B

So here you see, I got this like modified response, so that's just an example right you can. You can do whatever you want in term of transforming the request, header request, a response, adder response body and, and things like that right we can also like define where we want to do this transformation. So now, sometimes it's nice to do transformation before we do authentication or after we do authentication or things like that right. So here we have what we call an early transformation. So that applies uh before the authentication right.

B

So I can apply this transformation. You can see.

B

I will transform the the response and I will add this json content type, and I will uh you know, change the the body as well right, so I can just go there and if I you know like, if the status is 401 right, I can simulate that because I use the uh http bin. So I want to get a 421, so I just have to call this right and you see the the transformation here right that is happening.

B

While, uh if I run like a normal request with like the code 200 right, it will not like uh perform any transformation right. um We we have like a another example where we can take the data from another editor using like a regular expression and create a new editor based on the value we got from the regular expression right.

B

So you can see here we can have in the request, like a header called x, my initial header- and it has this format bearer and something right, and there is the regular expression here and we want to create a new editor with just the value here. We want to remove beer basically right, so that could be very nice when you want to maintain compatibility right.

B

So you I just do that, and here I send uh you know I just like again send a request here, and you see my initial header as this bearer and I create now a new header that has just the value right. So again, it's it's quite useful. We can also do that.

B

You know use uh some transformation to get like uh some to extract some information from the the token that we get after the authentication.

B

So you see here we say we want to use the jot filter so that we take the email claim that is returned by uh in the jot token after we authenticate with key clock, and I want to create a new header called x, solo claim email for that right. So we do that for just updating again the service, and uh if I refresh my my token here, like my page sorry so you can see here now, I have this x solo claim email that is received by the backend application.

B

So you remember, we do the application at the gateway level, but now it's important also for the backend application to know who is the user that has been authenticated right so now. It knows it right, so it doesn't have to be from the authentication, but you still need to know in many cases who has been authenticated right. So that's a a very typical use case and then uh we can also, as I said, chained together several steps in the hot config right.

B

So we did like create a hot config where we want to do authentication with key clock here, but we can also have a second step which is performing auto authorization with opa. So we just like update the autoconfig and we don't need an opa server. This is what's really nice. We use basically the opa library directly in our external authentication service so that you just need to provide the rego policy in a config map.

B

So you see here in the policy what we do that we extract the claims and we check the email claim and the email claim has to finish by solo.I o. If it's not the case, then we will reject the authentication.

B

So if I just do that and then we just take again the virtual service we had before, but we still reference this hot config object, then you can see that here I can still access it right because I am like authenticated with user one. But let's say if I go here and I try to access the same page.

B

With user 2, I know this one doesn't finish by solo. I alright it's a different email, then I am not authorized so like it's a lot of different examples right.

B

I wanted to show you really the fact that you can drive everything through yammer, that you can take advantage of authentication at the edge perform authorization as well and also like take advantage of like a web action firewall and and all these different, you know rate limiting and all these different things you can go to the dock, and you will see like many guides that show you how to uh you know, handle lambda functions, for example grpc in terms of security, you, you have a lot of other options right in terms of authentication with api, key ldap, creating your own plugins and so on.

B

Right. So thank you for your time. I hope it was uh useful.

A

Thank you very much, denis.

A

I just want to stop by apologizing for the video quality during the video um this during the stream. uh Denis has actually posted his video in the slack channel. So if you want to, in the short term, have a look at any of the command line or terminal um in in a higher resolution, and you can do that, we will also, when we post this recording afterwards on youtube. It will be in a higher resolution as well. So uh apologies for the technical issues that we had with the stream.

A

um So I just wanna uh thanks for joining denise. I just wanna have a look and see if there any questions um about about your talk that weren't related to the video quality.

A

People did seem to be very interested in in the talk, though, so um that's all.

B

Yeah, like always on slack right and you can find me in the cncf slack or in the solo slack, so don't edit to come here. As you said, you know, I gave the link for the recording, so perhaps it will be easier to have questions after you watch it with seeing all the command lines and all the stuff, so don't hesitate to take the time to watch it and come and ping me on either the cncf slack or the sort of slack, and I will I would be happy to to answer any question there.

A

Great well, thank you very much for joining and for uh doing a talk.

C

Thank you for inviting me for the talk, and hopefully uh you will have a lot of other great sessions moving forward. I'm sure.

A

So now we're going to a short break and we will be back on track two at around one o'clock, I believe, is that correct on my right. I'm thinking uh I.

C

Think we're back.

A

At ten to two one, fifty 10 to 150 all right well until then thank you very much.