 Hi there! Welcome everyone to the webinar today. I am Chintan Thakkar, the founder at company called SARS and we build the on-road ingress controller API gateway. In this talk, we'll go over how to have end-to-end encryption using the on-road ingress controller and the link-ready service mesh. So this is sort of a workshop. You can follow through it and even go through the steps while you achieve the same things that we do in this webinar. If you have questions, feel free to join the Slack channel or if you want to try out the enterprise features for the on-road controller, you can drop us a note using the form on the website. This is about me. You can also follow us on Twitter. We also have an open-source version of our software apart from a community and enterprise version to check out the open-source. You can use this address on GitHub. At the high level, we are going to talk about these cloud-native solutions. Figure out the different components involved to take a high-level view of where the solution fits. What are the different components? So at a high level, the application networking and security involves the container networking interface. These are these are softwares like Cilium or Calico or Flannel, which essentially provides the network plumbing between the ports. That's the container networking interface. Then there is how does your traffic enter the cluster. That's where the on-road controller comes in. One example of that is the on-road one step. And then we have service meshes like Linkerd and Istio which essentially help with not only traffic management but MTLS observability and a lot of operational concerns are met. So we'll quickly talk about all these things and then finally we'll go over a demo. So this is a graphical representation of the major components in Kubernetes application delivery and security. So of course you have the cluster and you have the CNI. The CNI wires of all the ports and the services performs the network plumbing and a lot of times they also do security functions like network segmentation at layer 3. Of course you have the service mesh inside the cluster which performs MTLS and traffic management and the ingress controller is essentially the piece how your traffic gets inside the cluster. So on-road one step is an ingress controller API gateway. It is built on on-wide proxy and essentially helps out with not such south traffic security and management. It's extremely simple. Typically the policy and connectivity that you want to specify for a service can be done using one step. That's the idea behind it and it's declarative so you can just declare the things you want. Execute one command and it'll provide the necessary policy and on-road one step is completely Kubernetes native. It runs as a container and it can be used to run as an ingress controller service. How is it different? It is built on on-wide proxy of course. It's again on-wide proxy the CNCF graduated project. It works for both Kubernetes and non-Kubernetes. On-road also can function as a shim outside of Kubernetes when you run it in standalone mode. Say for instance in a Docker container if you just wanted to run on-road and on-wide you get simple REST or GraphQL based APIs to configure on-road. It is purely declarative. There is no YAML involved when you are setting it up. You can just select a set of service and L7 policies. Specify those policies, run one command and it's all good to go. You can then tweak it by editing different config objects and then you know tune it more to your needs. There are three versions of course the US as the community and enterprise and you can check out the complete list of features and get on-road.io slash features. Linkerd is again a CNCF graduated project. It's a service mesh ultra light weight and it's an extremely popular service mesh which has over 200 contributors and I think if I'm not wrong over 10k stars. Why do we need a service mesh and why end to an encryption? So with microservices the surface area for attack increases to establish you know like a secure environment to run your microservices. There is the zero trust paradigm which has never trust always verify. So you essentially verify every single request coming inside your cluster and when the services stop for each other they also verify every request and the verification comes in forms of authentication and authorization. So of course you need your identity set up for each of the workloads that you can use to perform the enforcement. So the zero trust principles for traffic entering the cluster can be can be essentially done at the ingress. This is where on-road comes in and enforcing zero trust principles inside the cluster would be a component like a service mesh which performs some orth C or 10 for inter service communication or the east-west traffic. So this pictorially represents how the end-to-end encryption looks like. So of course when the traffic enters the cluster you have TLS from the user to on-road. This is the downstream leg and then once the traffic hits the ingress controller it's all encrypted as it is meshed with MTLS. This example specifically talks about linker D and on-road. So now that was just a quick overview. We'll go over a quick demo and this involves installing the linker D service mesh. We have a Kubernetes cluster. There is linker D installed on top of it. There is an example workload in form of Emoji Auto. That's an example workload and then we will mesh that example workload in the linker D mesh. So essentially insert a proxy with the workload. So and then the other aspect is we'll install on-road. We'll mesh on-road with linker D. We'll externally expose the application to the client and then we'll secure that communication using a certificate an AP certificate that will generate a sign and install in one step again. So that's a high-level introduction about on-road one step and linker D and what we'll be covering in the demo. So the demo steps are also present on the website. There is a high-level article that talks about it. So you can just navigate to the website and in the blog section you can go to end-to-end encryption using on-road and linker D and that will essentially walk you through the same things. So we have a cluster right now. So let's just quickly check that. So we have a cluster and we also have linker D installed. So that's linker D installation. So we have also connected to the Boojant cloud. Boojant is a company that created linker D. So we are also connected to the cloud just to verify the MTLS. So right now here is the connection and we can see that there's one active cluster with a couple of nodes. There's a few workloads. So we'll use this to verify our MTLS. So moving ahead, let's go ahead and install the Emoji workload. So that's the command that installs the workload. And then of course we have, I think we have these. So we have the Jetstack cert manager which we'll be using to install the ACME cert and we also have the on-road API gateway, Helm charts which we'll be using to install on-road and the service policy essentially. How to expose the service, how to secure the service. So let's just go ahead and install on-road. So here it's going to create an instance of on-road ingress controller API gateway and let's quickly look at that. So it's still getting an external IP. In the meanwhile, let's go ahead and set on-road up for running with linker D. So when you are integrating an ingress controller with linker D, there are a couple of suggested practices. One is around adding a header to provide hints to linker D. The other one is around delegating the endpoint selection for routing to linker D. So there is one flag setting in on-road which takes care of all of this and it can be further customized if you like but essentially there are a couple of requirements when you're trying to run an ingress controller with linker D and with on-road one step we have made it extremely simple where you just set one flag and everything just works. So let's just set this one global config and that's it. So that's all you need and now on-road is ready to work with linker D. Now you can take a look at this more on the website to see what are the other customizations available but essentially you've already enabled the linker D enabled setting to set up the ingress controller and if you want you can disable the header addition and the endpoint selection delegation you could disable any of these if you like but by default it's all enabled. Now we earlier created the Emoji Voto workload now we are just going to mesh it so just going back to this what we are talking about now is we got a workload setup say Emoji Voto workload now we are going to mesh it as we are going to add the linker D proxy to it and that's the command to do that so what it does is it adds an annotation to the deployment and that inserts the linker D proxy and then we do the same thing for on-road. So what we are doing here is we are injecting the linker D proxy for both the workloads the Emoji Voto workload our test workload and the on-road workload. So now let's quickly look at the cloud and how it looks right so we see that Emoji Voto is now seen by the and then here it's here we can see Emoji Voto Emoji Voto is meshed and we also see that on-road is meshed the dark circle here with our solid dot in there shows that it is meshed we can also verify this by looking at the pods I think there's a command here yeah so here what we see is we have the on-road pod which is running the on-road image and redis and of course on-way proxy but at the same time it is running the linker D proxy as well in the same pod so what it is showing is that we have successfully meshed the on-road pod so now let's quickly look at yeah we now have an external IP so what I'm going to do for this demo is create a DNS entry for this external IP and let's call it on-road linker D meshed demo and then we're just going to set it to the external IP and let's just quickly ping this and see if it is set up wait for some time to set that it's set up but in the meanwhile let's go ahead and expose this service externally so the way to do that is just use one command from the chart and what we are doing here is we are saying program the ingress in such a way that I can talk to the emoji auto service over that DNS name and we are specifying a couple of properties about the service what's the name of the service what prefix to reach it on what port the service is accessible on so let's square and run that command so so this shows me that the service the ingress is getting program and it right now installed a couple of filters which I can quickly look at if I like so that tells me that oh I have a lua filter setup which is going to add a lua filter says hello header and then there is also the rate limit layer seven rate limits setup which which again you can take a look at over here so you're saying for the htdv protocol limited to five requests per second so this all got set up automatically let's ping the domain name and now let's try to call right so we are able to see a 200 and of course we are all also able to see the lua filter says hello let's try and navigate to the service from the ui so here we are so let's just then let's look at the let's look at the workloads and we see that unroot is meshed right and then we let's look at the topology so now this shows me that on root is meshed and we are able to pass traffic to unroot and it is mtls to the web service and the other aspects since we had meshed the emoji to workload and that also shows up here and now let's just go ahead and add an ssl cert we have the we have the unroot setup and let's just install the certificate on it so here we just changed the name and everything else is the same and we enable tls to true we set up our email to a valid email for us and then let's go ahead and request a certificate using acme from let's encrypt then again this will go ahead and talk to the acme server to get a certificate verify a certificate and then the certificate will get installed on the app so let's quickly look at what's going on with the cert so it is not ready yet there you are it's ready so let's go ahead and fire a curl request and we're able to see that there is n20ls here and we see the tls handshake and we see that the cn is set to the domain name that we specified and let's look at the cloud and see so I think here you can look at this and go let's look at application tls and linkerd tls and there you are the application tls showed up that's the linkerd tls so going back to this the cert that we installed that covered the tls from the user to unroot and we were able to mesh unroot and the emoji voto workload which was the mesh mtls aspect so that's how we achieved the end to an encryption using the linkerd service mesh and unroot so that concludes the demo if you have questions feel free to drop us a note through the website and thank you for joining us have a great day bye