solo.io Webinars, 3 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Protecting Applications with L4 and L7 Network Encryption (TLS/mTLS) with Gloo API Gateway

Description

API Gateways act as a control point for accessing backend application services by external clients and end users. Depending on the request path and the service the client is connecting to, organizations may want to secure it by encrypting the communications.

Gloo is a next generation API Gateway and Kubernetes Ingress controller that connects, manages and secures the request and response traffic from external users to a broad portfolio of backend applications including; monoliths, microservices and serverless. Built using Envoy as the edge proxy in the gateway, Gloo supports L4 and L7 layer traffic to enable TLS and mTLS encryption for your ingress traffic.

This session covers:
* Network encryption options for ingress traffic
* Tutorial for HTTP based upstream
* Tutorial for TCP based upstream

Download the presentation https://speakerdeck.com/soloio/mtls
Try the tutorials https://github.com/solo-io/gloo-ref-arch/tree/master/webinars/encryption
About Gloo https://solo.io/products/gloo
Questions? https://slack.solo.io

A

Thanks betty and thank you all for joining us, uh as betty mentioned, my name is rick and I'm going to walk through network encryption with glue.

A

So the purpose of this webinar is to really do a deep dive on all the different ways that you might use glue while utilizing network encryption and obviously you know stepping back most applications that you're exposing to the outside world. You need to be thinking about this from a security perspective, and so you know we're going to go through all the different scenarios that you might want, depending on your environment, depending on whether you're using http features and so forth, and so in this webinar we're going to kind of look at different scenarios.

A

First, with l7 or http routing uh different ways that we might utilize tls encryption with glue and then in the second part, we'll look at glue as kind of a tcp proxy and how we can apply the same concepts. There.

A

Now this webinar is kind of going to assume at least a basic knowledge of glue if you're new to glue glue is an api gateway. Basically, it's a set of components that manage one or more replicas of envoy, a proxy which is an open source, proxy implementation and basically, what it's doing is it's configuring different routes on that proxy between end users and your application so end users can send traffic to envoy envoy can forward that to the right destination.

A

Now, for the purpose of this webinar, we're going to be talking specifically about how network traffic is encrypted between end users and envoy and then also, but how encryption works between envoy and the services separately. There's also kind of encryption concerns or just a question of how does glue the control plane communicate with envoy the proxy that also we can do through mutual tls.

A

But that's not going to be the focus of this webinar and if you find that the content here is going a little bit too deep, we did just upload a video yesterday that kind of goes through a basic overview of glue. So, if you're struggling to keep up with some, some of the concepts like upstream and virtual services would recommend that you go back and check that out and then look at this video again.

A

Before we get into it, just a shout out to a bunch of customers that we have these are from our website. You can go to the website and read more about the case studies, what they're actually doing with glue but, as you can see, we're working with a number of uh both small and large organizations, new startups and established companies.

A

Cool, so this is kind of just summarizing. uh You know some of the different concepts that we're going to talk about so tls termination and origination and pass-through. These are basically the different scenarios that I was referring to we'll go into this in a second and we'll also kind of touch on what about mutual tls and what about connections with a service mesh great and with that I'm going to jump right into a demo.

A

So I mentioned this, or betty mentioned this at the top, but the notes for this are in a repo called glue, ref arch. So if you do want to follow along, I pasted the link in the chat you're welcome to follow along and we'll send this out a bit later.

A

The first thing I'm going to do is install glue I've gone and kind of cleared my cluster here. So this should just take a moment.

A

Well, that's going we're going to kind of give some basic setup so since we're dealing with ssl I've gone and kind of simulated uh having a primary key infrastructure or having a public key infrastructure. So you know basically I've gone and generated root certificates locally uh and from there I've generated certificates for the first domain that we'll be using um so we're using a service that you know a simple go service that we wrote called splunker and we're just going to use the domain spelunker.com for all of the traffic.

A

So this is to simulate a user's navigating to spelunker.com, and so you know I've done this. I've gone ahead and done this so that I don't mess it up here in this demo. But basically we just created some really basic certificates for that domain.

A

We can see glue's installed, so let me just make sure that it's running and it looks like it is everything's running uh all good. So uh next excuse me next, I'm going to install uh our spelunker application actually see if it's already there.

A

Looks like it is. Let me just make sure I don't have any uh okay, so just to see what this is or our application is really simple service. All it's going to do is when a request comes in it's going to respond with some basic information, so it'll respond telling us if the request came in via http or https, and then it'll also just print out some some basic stats about the request, and if we look at the manifest, we can see that when we installed this, we created a namespace in the namespace.

A

There's a single pod, that's running our container and there are two ports, so the standard, http port and the standard https port and for the purpose of https traffic we've mounted a couple certificates and from the we did that with a secret called tls.splunker.com, and this is where I'm going to introduce a bit of a naming convention here, uh because we're looking at a bunch of different scenarios that are all somewhat similar. I've used just the names here of the resources to try and uh keep it clear what we're looking at so so here.

A

What we're doing is we're mounting a tls certificate uh into a volume called certs so that it's accessible to inside of this container and similarly the service that we've deployed the kubernetes service uh also exposes those two ports, and so it's basically you know it's opening up networking to those two endpoints inside of that container.

A

I think this secret already exists, but I'm going to just make sure you know we're just creating a standard.

A

A

So we're just creating a standard kubernetes uh certificate yeah. It already exists, which means that our container should be running and it should be.

B

A

I just want to make sure okay cool.

A

So now we want to expose this application to the outside world using glue and, as you probably know, glue has two key abstractions that we need to set up in order to create that route.

A

So we need to model the service itself as an upstream as a destination for traffic, and then second, we need to actually create a route to that destination using a virtual service.

A

So the first thing that we'll do is set up just a plain http route, using none of the kind of no, we won't use the secret. We won't use any ssl to start. Let's just take a look at what that looks like so. First we'll create this upstream. That represents our http destination, and here this is a really vanilla, upstream definition. In fact, you know we might have just utilized glue's built-in discovery mechanism to produce this. We're not creating any custom customizations here, but but this is what it would look like.

A

So let's apply this.

A

Next, we need to create an actual virtual surface that routes to that destination, so here we're creating a virtual service called http.splunker.com just to indicate that we want to kind of receive incoming traffic via http.

A

So this is traffic from end users to envoy and then we're telling envoy that for requests that match on spelunker.com is the domain and on any path route forward. That request to our http, upstream, which you know we didn't- provide any ssl config anywhere here. So we expect it's just going to. You know forward that request as a plain http connection, and we should be able to verify that when we actually create this route because our we should be able to curl the endpoint, and we should see that we hit an http endpoint.

A

So let's do that.

A

A

Now, behind the scenes glues uh reading this virtually saw that we created this virtual service, uh seeing that it's referencing this upstream, it's basically computing a proxy crd, it's it's an intermediate representation and then it's translating that directly into envoy config and we should be able to now hit. It should propagate basically immediately. So you should be able to hit this now to make it a little easier for our remaining scenarios. I'm going to just set up a variable here in my command line.

A

Basically, I'm running a command here to grab from the cert that from the kubernetes service, that's called gateway proxy. I want to grab the ip address for the ingress that the load balancer establish. This is just another way to get essentially the ip address of the envoy proxy. That's running that glue is managing, and this is in in my case here. The cluster is running in gke, so this is a ip address that google load balancer just granted us.

A

We can see what that is here. Oops.

A

Cool and now we're going to run a curl command and again we're going to just run this as a setup so that we can see how it compares to the other examples. So we're going to curl swollen cur.com with an hdp request. So we're not using we're not initiating an ssl connection here. We're telling curl to resolve this url to that ip address of the envoy proxy, and this essentially just bypasses the need for dns.

A

But it does so in a way that will will generalize to cases where we are using ssl as well, which we'll see in a little bit.

A

And if I run that looks like it's working well, so we've we're curling the http endpoint. As we saw we, we wanted the we set up a virtual service that received http traffic and forwarded it to just an http endpoint and that's what we're seeing here. So this is working exactly as we expect.

A

So I did that kind of the the long way just so that we can start to see what we need to change in order to start playing around with different scenarios for https, and the first thing that we're going to do is we're going to create basically an https connection between curl and the envoy instance envoy is going to terminate ssl.

A

Potentially it's going to perform routing it potentially might apply any other features that we enable on that route and then, when it sends the traffic onto the upstream destination, it's going to reinitiate an ssl connection to communicate to the https port on the container.

A

So we need to set up a few things for that. First, we're going to set up an upstream that represents that that tls or that https port on the container. Let's take a look at what that. What that looks like.

A

So, basically, up through here, it looks exactly the same: we're still routing just to that same service that we were before now, we're routing to the https port and we're providing an ssl config that basically, it's expected that this would contain that tls secret.

A

And by doing this, we're essentially informing envoy that when it's communicating to this upstream, it needs to initiate an ssl configuration with this certificate.

A

The second thing that we need to do is we need to create a route so that I can issue a request from curl locally to envoy, and it knows how to get routed to this upstream, so we'll create a second virtual service for our domain uh and this time on the virtual service. So we're making two changes from before.

A

The first is we're routing to a new upstream. This, in this case we're routing to an upstream called uh tls. That was the one that I just showed, and that's the upstream that contains information so that when envoy knows when envoy decides to matches here- and it decides to forward the request to this upstream- it knows how to initiate that ssl connection.

A

The other difference is we're providing an ssl configuration on the virtual service itself. uh Here we're actually referencing the same secret, because ultimately it's the same certificate that we're going to use here. But but this is telling envoy that for incoming requests that this is, this is a route for incoming requests that are https and that will basically mean that glue will have envoy bind that to the https listener and we'll see in a second what that means. So, let's apply.

A

A

So now we should be able to issue an https request kind of like what we were doing before uh here with curl, except to the https port, and we should be able to see that we, you know, basically hit an https server just before we get into that. I'm going to show the proxy crd, so I mentioned at the top. This is the proxy is glue's intermediate representation.

A

This is kind of exactly what it's going to translate into envoy configuration, so it shows the listeners or the ports that envoy's listening on and by default it's always listening on an http on an hdp port, 8080 and https 8443, and as we can see um you know, we basically have used those two we've got those two routes bound to the correct uh listener.

A

So, and we can see you know in the status here that it's been accepted, so we expect that we can already issue this curl request.

A

So my request here is very similar to the one before um obviously I'm uh initiating an https connection here locally from curl, I'm telling just like before. I'm telling uh curl how to resolve that, except this time with the h with the ssl port and I'm also just providing the root certificate here, so that it can kind of avoid that insecure warning and this works again exactly as we expect we're now uh we're you know and we're forwarding we're sending our request to envoy's https port.

A

This time envoy is decoding that figuring out where to route it to, and it's routing it to the https endpoint on the container that we opened up, and we know that. um Basically, this is the text, that's different. You know we implemented it so that it says that it's it's hitting that https port instead of http cool. So at this point we have these two different virtual services, one for kind of plain text, http passthrough uh and then one for you know ssl to ssl connections.

A

Basically, all the way, through now we're going to flip the scenarios a bit and look at the two other cases, one where we're kind of starting from an insecure http connection. Sending that to envoy and then envoy is forwarding that to the ssl, endpoint and then kind of vice versa. Maybe we might, we might be starting the kind of https connection locally, but on voice terminating and then forwarding to the hp port. So those are the other two scenarios that we could kind of utilize by changing how we're configuring, our upstream and our virtual service.

A

Let's just take a look at what those how to how we go about doing that.

A

So to to make it a little bit more clear, I've created kind of a second domain here, spelunker2.com and that's basically just to handle the the kind of this inverted case that we're going.

A

Through so, if we look at what this initial virtual service looks like.

A

So this is our http virtual service, so it's going to be receiving envoy is going to receive http connections, but here we've we're forwarding it to a tls to our kind of tls upstream. So we're expecting that envoy will be initiating the connection and then communicating with the back end over https.

A

And we can see that was really all we needed to do here, because we already had the upstream and the secret for that upstream created, and so what we see is we're curling the hdp endpoint for envoy, so we're initiating an hp connection to envoy resolving that to the glue host, but behind the scenes, because of the route that we set up, we configured that virtual service to talk to our our tls upstream and so we're hitting that end point. That indicates that we, the connection, came to the back end as an https connection.

A

So that's the third scenario and then the fourth scenario is the opposite of this. Imagine we want to issue a curl request uh that initiates uh our ssl connection locally. It terminates at envoy and then envoy to the back end communicate in uh in plain http, and you can probably start to guess uh how we would go about making this configuration really there's two places that we need to configure for any of our ssl concerns.

A

One is on the upstream for all the traffic going to the back end and one is on the virtual service for all the traffic going to uh envoy itself. So for this last case, I need to create an https virtual service. I need to create a route that that tells envoy the ssl config for that incoming https connection, but then establishes or then forwards it to a back end. That is our plain http.

A

Let's take a look at what that looks like.

A

So here's that route- it's just forwarding it to our old http um upstream, but here we're going to provide a tls secret so that we can so we're telling envoy that it will accept or it'll bind this essentially to our our ssl.

A

A

Now I'm I've uh I've gone and created a bug here, so I just want to show what that looks like um you could probably guess what the problem is. I never went and created a second certificate, but we're using a new domain, and so when I you know, I've made that request and it's fine. But when I issue the requests, I'm getting this error, that's for the wrong domain and that's good that that means we're kind of actually validating uh the ssl connection, and it means that we need to go create that certificate.

A

So I've gone- and you know again like before I've created one I'm going to just go and deploy that to the cluster.

A

Looks like it's already. There.

A

If we look at what the fixed version of this looks like all all I'm changing here, is I'm referencing the correct secret? So you know this is just uh to point out that we really do need to generate certificates for the specific domain. So let's apply this and we should make.

A

A

Now subtly this is fixed, but we're going to run into a problem so we'll be able to detect that by running glue, ctl check and generally you know, as a side note, would recommend that you use this anytime you're, really trying to either develop confidence that your glute configuration is right or, if you're starting to diagnose, what's going wrong.

A

In our case, I ran it and we're seeing this error and what's happening is we haven't properly configured sni for envoy, so we've got multiple domains that were you know, managing with the same listener, and we need to actually set up snl er sorry sni configuration properly on those virtual services.

A

So, let's just look at that real quick, the sni configuration is very simple. It's just this additional sni domains, field.

A

And again here uh so we'll create we'll we'll update both of our virtual services with proper.

A

A

So now we can rerun glue, ctl check.

A

We should see that our proxy error is no longer being reported, meaning that uh the glu the proxy. So the error before um told us, essentially that envoy and glue were out of sync, so glue had updated configuration, but it couldn't translate it in a valid way to envoy now we're seeing that there isn't a problem, and so we should be able to finish our test here and actually see this in action and, as we can see now we're issuing an https request to our new our second domain and telling it how to get results.

A

But we've we're now forwarding that one to our plain text- http endpoint. So that's to simulate. You know encrypted traffic between the user and envoy, but then unencrypted between envoy and the actual back end, and let's just see all four of these.

A

So if we go back and we run our um our other splunk or two on, we can see http uh requests get forwarded to the tls endpoint uh and then you know we should still see our old ones working.

A

A

A

Cool, so all four of those are working and those are the four different scenarios that you might want to evaluate for your l7 proxying concerns before we move on uh to l4. There's one last detail: that's worth mentioning which is glue is so so far. We've basically done mtls between myself here and uh an envoy, and that's you know I provided the ca cert here in order to not skip that insecure check, but the we also need to provide the roots.

A

We've never provided that root certificate to envoy itself, so envoy, currently is only doing one-way. Ssl between envoy and the actual upstream and glute provides a simple mechanism to actually turn that into an mtls connection, which is to update the secret and to have the root ca in addition to the actual uh private key and certificate. So if we look at that, you know we can, we can quickly go change it to set that up.

A

So first we'll deploy this secret here, I'm just typically, you would create this. This is one of the intricacies about glue secrets. Is that there's a slightly different format for some types of secrets, so here this is something that I created with glue ctl.

A

It's got just a nested structure, but inside of this contains our original two files, as well as our root ca.

A

And the the glue ctl command to create that is, is in the notes.

A

So once we have that, uh then we just need to go and update, and so where we were communicating to the mtls to the tls backend. Now we want to just change that to mtls.

A

And we want to do that in both places. You know in on both of the virtual surfaces where envoy is configured to to communicate with the back end over.

A

A

Great and now, if we we can rerun those four curl commands and this time the main difference is that in the background and the background, glue is performing uh mtls now from envoy.

A

Great, so that's that's it for uh l7, proxiing and I'll. Just recap briefly: before moving on to l4- and I promise the the next.

B

A

Is going to be a lot shorter, but basically what we did is we kind of tried to compare and contrast all the different ways that you might set up: you're. Essentially, your traffic between end users and your actual back end through glue and because there's the because envoy's sitting in the middle, that means we've got choices about whether we want to encrypt the traffic between end users and envoy and then again whether we want to encrypt it between envoy and the actual back end. And so we kind of looked at all four different ways.

A

You know we basically created all four of those as different virtual services so that we could see them all side by side to compare.

A

Cool and with that I'm going to shift over to the second demo, which is, if we're just using l4 capabilities, meaning we're not really, uh we don't really have a need to we're, not really using any routing features that we would utilize with http. So we have a lot fewer things to configure.

A

First, I'm going to delete these virtual surfaces.

A

I also have found that I need to restart my gateway pod.

A

I'm switching from an hdp to a tcp proxy, which may be a.

A

A

So if we look, we shouldn't have a proxy crd object. Remember that proxy is includes intermediate representation.

A

Now we've gone and deleted all of those virtual services, so we have no routes and we don't really want to create new virtual services which have domains and paths and potentially features that we really can't utilize with tcp.

A

So there's a different mechanism that we can use to set up tcp proxy- and it's very simple, basically we'll use that other. The other object that glue uses to construct that intermediate proxy representation, also known as the gateway crd, so the gateway crd, is the thing that basically specifies one one. What is the port that envoy is going to listen on and by default? There's there's always two gateway crds by default, one for http on the default port and one for ssl.

A

So the gateway specifies that listener port. It also specifies whether the that listener is a tcp or an http listener, and then it you know, depending on that configuration there might be a lot of other things that you want to configure. If this was an http listener, we might want to.

A

You know specifically pick which routes to bind to this port or do a whole host of other things, but for the purpose of the second demo, we're actually using tcp proxy, so we're changing the gateway definition to just say that it's a tcp proxy, which means that we need to provide it. uh The back end right here, we're not creating virtual services and so on I'll update the the http backend.

A

uh Sorry I'll update the http gateway crd to just use our our old http backend, and likewise with our tls listener with the and the main difference here again, is that I need to provide that ssl configuration, um so I'm essentially just providing uh that uh so that, when envoy's receiving traffic on this port, it knows you know what to do when it's encrypted, and it's worth mentioning um the uh oh just that I needed to also provide this protocol in order for it to work correctly. Over curl.

A

So I'm going to apply those two.

A

I just wanted to make sure looks like we have. A I'd have restarted my pod too soon, so I'm going to go. Do that.

A

A

I think there's a issue when you're changing the ssl configuration in envoy on a particular for a particular listener report. There's some uh there's some issue inside of glue that I was running into so that was just cleared up by a restart, wouldn't really normally run into this. Typically, these changes to our gateway, crds are very deliberate. We don't flip them back and.

A

A

So this is, this looks half correct, I'm seeing uh the hdp listener bound. You know to the correct back end, uh meaning that the the first listener report set up correctly, I'm not seeing it on the second, which might mean that I forgot to apply some config. Let's take a look.

A

Oh yeah, that looks like the problem. I never actually updated the configuration for this, so let me do that.

A

I must have just done the the other one twice.

A

Okay, now we can see. The second listener has been updated. It's got that protocol that I mentioned it's it's it's uh forwarding to the tls back end. It's it's got the secret, so it knows how to handle incoming connections. So let's try issuing the two curl requests again.

A

And we can see that one's working, just as we expect and if we do the second one.

A

We're getting some problem here, let's see what the let's see if we.

A

Also run into a couple issues like this, when I uh basically modify the ssl configuration in flight for envoy and kind of flip, it between ssl and back, have run into some issues and that have sometimes been cleared up uh by just bouncing that pod I'll give this one more shot. If it doesn't work I'll, we'll make sure to provide uh the correct config in the repo. Let me just see now it looks like I've done something wrong here.

A

I see I think I was trying to do some.

A

A

I think what was going on is, I had forgotten to create the uh this gateway object, lives in the glue system, namespace, and I we have a security restriction that you can't reference secrets in other name spaces, uh but and so in the previous example, I was only using kind of resources in spelunker namespace. Now, I'm in the glue system, namespace and it didn't have the secret available.

A

Okay and there we go so now, you know once I provided the secret to envoy, I was able to handle the incoming requests and forward it on to the https port.

A

So with that, I'm just going to recap, and then we can wrap this up and switch over to questions. But basically you know in the first part, what we're doing is looking at all the different ways that you might configure encryption for different l7 proxy scenarios, where, in the middle, we're having kind of envoy terminate our ssl connection, potentially applying some different features in glue and then forwarding on the request, and in the second example we looked at some. You know really some simpler examples where we're not using any l7 capabilities at all.

A

Instead we're just configuring glue as an l4 proxy, and you know we're showing we've shown what that looks like if it's like http all the way through or https.

A

Great uh and with that, I think we that's it for the demo, so I'm going to switch back to our presentation uh we always like to highlight you know we looked. We went really deep on on a few features here, related to encryption and tcp versus http proxying, but- and these are all available in open source glue, but there's a whole host of other features that are worth exploring, many of which we've covered in other webinars.

A

So this slide gives kind of a decent overview of all of that.

A

We also have this on our website, so if to get a better sense of the breadth of capabilities that you can utilize glue for, I would take a look at this and dig into the docs and, of course, there's tons of resources out there to learn more so check out our website uh check out. The uh glue has a pretty large docs uh repo.

A

So if you go to doc solo, dot, io, slash glue, slash, there's a ton of guides and different ways to really dig into this and other features, and if you're interested in trying out enterprise glue, feel free to request a trial with that I'll turn it over to betty to kind of moderate uh questions.

B

Yeah, so thanks rick um first question here um is what is sni, because I think um you just used an acronym there and not. Everyone may be familiar with some of the terminology.

A

Yeah um now I need to remember what it stands for, um basically, the what sni is doing is it's helping. It's basically hinting what the domain for the incoming encrypted request is it's a way of supporting some amount of routing without having to basically terminate and re-initiate the ssl configuration, so it's you can think of it really just as an extra hint. So, if you're managing multiple domains and you need to decide which certificates to choose uh for the purpose of receiving that incoming ssl or https request, sni helps with that selection.

B

Great- um and um you know one another person here had a question regarding the demos and if you were using gke, which I believe most of your demos are on gke. But is there an ability for them to test things out locally? You know: do we allow glue to be run kind of locally on a machine and not kind of like spinning up a whole cloud cluster.

A

Yeah for sure- and um you know for all of these demos- a good option uh if you're new to kubernetes uh is mini cube, that's kind of where we used to start so minicube's, an installation of kubernetes that you can run locally on in a vm that you have and it's a full cluster. It just has a slightly different networking model from from gke or eks or one of the cloud provided kubernetes clusters. So the main difference is that in our when we looked at our glue installation.

A

And we were getting the glue hosts, we were basically grabbing this external ip and this was a load balancer ip that google provided so obviously, when you're running locally, if you're, using mini cube, you're not going to have that and glue ctl has a command to make it just easy to figure out uh what to use instead. Essentially, so, if you're you're welcome to kind of run these examples locally, you just need to kind of know how to grab that the correct network address.

A

I will note that more recently, we've kind of been moving from mini cube as a default, moreover, to kubernetes in docker or kind, so, there's really great tooling, around docker for running kubernetes locally and with a little bit of tweaking to these scenarios, it should all work. Just fine.

B

Yeah, actually I sent that to that person. I sent them the link to our cluster setup, which referenced mini cuban instructions, but I don't think we have kind instructions up there at this point.

A

B

A

And we're we're always uh trying to improve that part of our docs. You know, along with everything else, but I do believe that we've got some different kind of installation uh cluster setup guides. So actually we've we've written quite a few of them at this point, so I would recommend checking this out. uh It doesn't cover kind, it looks like, but it should cover everything else.

B

And if you would like um instructions on those, we glue is open source and you can go to the you can just file an issue requesting. um Will it work on this or that um and it's something that um we can add to our docs backlog yep um and you know rick one more thing that I think would be nice to comment on. Is you know you talked about network encryption with glue from an ingress perspective. Now we do know that we integrate with um you know the glue as a gateway integrates with service mesh.

B

Can you comment on how we can also enable encryption between the ingress ii mesh.

A

Absolutely so one of the, if we're kind of extending the scenario that we had uh one of the advantages of having a service mesh is that we don't actually it's simplified. We could simplify how we deploy our splunker service, so you could imagine sorry. Let me pull that up again.

A

You could imagine having a single kind of backend deployment running in kubernetes. That only has our http port and we're not doing anything related to you know. Tls in this container at all and the service mesh could have a sidecar running. Next to this. In the same pod, the sidecar configuration could have been provided by an injector, so you know as a human writing out my this application. I don't have to worry about all the ssl stuff and that's one of the nice benefits of using a service mesh like link or d or istio.

A

You get really easy kind of mutual tls out of the box. Now, if you want to connect glue to a surface mesh, you can utilize glue or the envoy that glues managing as your ingress. So that could be the entry point to your cluster and it you know, we've got. uh You know basically simple configuration that you can supply to glue so that it knows how to communicate directly with the side cars for your service mesh.

A

Essentially, in that scenario, glue is you know, for talking. Istio glue is functioning as istio's, ingress gateway, so glue and a service mesh you know, are perfectly cohesive components they work well together.

A

We do get people asking well if I've got the surface mesh. Why do I need glue and it's a fair question, but I would look at just the features that you get or, if you think about kind of what you need at your ingress.

A

You know glute the the use case for kind of your north south, your ingress traffic is a little bit different than east west. We've found that the ingress capabilities that glue provides, complement the mesh and we'd love more feedback on that.

A

So you know, but there is that nice story and we often recommend you know start with something envoy based and if you don't have anything yet it might make sense to start with the gateway which could be kind of a stepping stone to to running envoy everywhere and getting a full service mesh up and running.

B

Awesome um are there. Let me check here to see if there's any more questions.

B

Looks like we are good. Can you just flash that last um slide again rick.

A

B

Awesome folks, so um we will have the recording posted online um on our youtube channel by the end of this week tomorrow um and if you want to learn more about glue, we've got the links to the product page to download the open source and request an enterprise trial. um I will update the link to that demo um to point to the reference architecture that rick showed during the tutorial today and if you have questions later on, please feel free to hop into slack.solo.io.

B

It's our slack community and we have a channel for both glue, open source and glue enterprise and we're our engineers are in there, as well as other folks from the community to help answer any range of questions on configuration and use cases. So with that uh thanks rick for presenting and thanks everyone for joining, we will see you next time. Thank.

B