Secure Routes for your Microservices on Red Hat OpenShift

[Music] hello everyone and welcome to webcast wednesdays my name is yusuf nimr i'm a developer advocate at ibm and i'm joined by my colleague masa abhishamna for today's webcast wednesday we're going to be talking about securing routes for your microservices on red hat openshift now this webcast is part of the series of kubernetes networking which you could find at dot io ibm.github.io kubernetes dash networking you can find the rest of the series uh in the previous webcast wednesdays conducted by my colleague grimco now to start off uh we're gonna discuss some uh some of this you know some of the security concerns in microservices so um you know in microservices uh you know you have uh you know you have your application uh loosely coupled so you have the front end as one microservice database as one microservice and the backend and so on um so in that sense you would have to address each microservice independently in terms of security um however in micros in a monolithic architecture we would have uh our code as one product and in that sense you in case you know if you have a vulnerability in in one part of your application uh this vulnerability could cascade to the rest of the application however in microservices um if there's a vulnerability in one uh microservice uh it will not cascade to the rest of the application so in that sense you know you could at least mitigate some of the um you know issues that you know that could arise uh from from that part now let us take a look at some of the security concerns in microservices first off we have uh data management you know so let's say your application is up and running and you know everybody's axing it however uh you want to make sure that your data is um you know is not jeopardized or somebody you know it's not there's no misrepresentation from the client's side so in that sense you would have to make sure that the connection from the client to the application is secure and uh you know your application is not vulnerable to um you know man-in-the-middle attacks or you know the client is not that somebody is not uh phishing packets from the client so uh this is in terms of data management simply because you know the the client's data could be jeopardized in that sense uh next we have the api vulnerability so in that sense we want to make sure that you know our application is resilient to the different requests that we could get um however in the case of the vulnerability of the api uh you know somebody can be conducting a distributed denial of service so you want to check for the legitimacy of the client and you know just make sure that this is a real person not just uh somebody conducting an attack so um this is the second concern uh lastly for uh we have the request authentication so uh here somebody could be trying to get um you know uh admin privileges on your application um and uh hence they could you know they could inject you know uh they could do a sequel injection and um accordingly they could get the admin privileges also they could inject certain protocols in your application and uh get the imam privileges accordingly so to address all of these concerns we would implement security to the routes of our application now let us take a look at the different types of routes on openshift first off we have the simple edge passthrough and the re-encrypt uh the simple the simple route does not implement any security measurements and we're going to see that in a minute um so the three secure routes are the edge passthrough and the re-encrypt now before we move on to the uh the routes and discuss them in details i just want to show you what you know what does routing in you know in your cluster look like so first off you have your application um out there and the client is request sending a request to it so that request gets forwarded to the router service and you know that router service sends it to the router um you can think of the router as you know as your point for external traffic to your cluster so if you want um to set up any networking that would access your application from from outside uh the router is there so the router sends the uh the request to the different uh pods that contain your application and upon the availability of um the first spot the the response gets sent back to the router and accordingly it gets sent back to the client so we have here so the client sends the request it goes to the router service and the raptor and here we can see that you know uh you know worker node you know part number one uh did not respond then you know the router checks for uh pawn number two pawn number two responded and then we sent back that request accordingly so this is how routing works in general uh of course this is demonstrating on a single zone cluster uh if it's a multi-zone cluster you know it gets bigger and more complex of course so let us take a look at the simple routing simple routing is very easy to set up and you know it doesn't really require anything to configure the only thing you do here is just expose your application and that's it the thing about simple routing here is that it uses http so the connection from the client to the application is totally insecure so um this could make you very prone to um you know uh phishing or man in the middle attacks so somebody could you know disrupt this connection you know so so somebody here could you know terminate this connection from the client to the router or intercept it and you know what what what you end up with here is that you know you have the client and you connect to somebody here and they send it back to the router so instead of you know having the client send data to the application directly um it gets forwarded to um this attacker or whoever that is in you know between a client and the router so uh this this is very safe is very unsafe and you know you could end up jeopardizing lots of data just as we have discussed uh next we have the edge routing now this is the first type of uh secure routes on openshift um for edge routing it requires an https connection from the client so if the client tries to access the application using http uh they will get a 404 and the application is not available so for the client to access the application uh they have to use https now the thing about edge routing here is that uh the connection is encrypted from the client side so if you see here um you know we have the client and the router and the application so from the client tilde router uh we have a tls connection but it gets terminated um from the router to the application so from the router for so in this link um we can see here you know it doesn't use any security whatsoever um for the ca certificate uh they all they also get set up on the router's end so here you know i don't see any encryption from the data in terms of you know from the router to the application uh next we have the pass-through routing um so for the pass-through route uh the traffic is sent straight to the application without using the router so the application includes the certificates the key in the certificate uh set up by the cluster you can you know you can use the certificates from the openshift ingress or if you have your own certificates you can set them up um but the thing here is that uh the password route does not rely on the router so here you have the the same tls connection between the client and the application um so um you know the router does not is not involved here by any means the only thing it does is just uh forward the uh the connection uh to the application from the client lastly we have the re-encrypt routing so the re-encrypt here we have two certificates set up so we have certificates set up on the application and we have another one set up on the router now what happens here is that the connection between the client and the router uses one tls and then uses another tls between the router and the application so you know as the name implies um you know the the connection between the client and the router gets re-encrypted um from the router to the application now uh the the thing here is that uh the router uses you know it uses health checks to determine the authenticity of the host so the author is there to check if the certificates on the applications end are also valid and you know the client would also have to present uh their own certificate to make sure that this person is legitimate now lastly we're going to talk about configuring the certificates for um you know the the routes in general so here we have you know we have different uh certificate providers so you could either use a self-signed certificate and uh this is pretty much you know like it's the weakest one uh you could use uh supplied certificate authority uh you know we have you know there are things like let's encrypt and hashicorp and you know the cluster admin configures um you know one or more of the certificate providers now in in openshift we have the certificate manager controller which just basically um you know watches for uh certificate requests and creates secrets accordingly for the developers to use so what happens here is that you know the developer creates a request for a certificate to be used in an application and you know the certificate manager controller provides a secret for the developer to use to integrate in the application um and before all that the cluster admin just configures the certificate providers now we're going to be moving on to the workshop so my colleague masa is going to be taking it from here to show us how to implement the routes that we have just discussed thank you yousuf thank you everyone for joining us today and uh now we will be getting started with the hands-on where we'll be learning how you can build uh your your uh applications on red hat openshift and how to uh allow external access in different ways so let's get started now first thing you're going to notice this is really important the github repository we will be using for this workshop which is github.com slash forward ibm developer mea slash forward aussie route you will find all of the resources you're going to need for this uh for this workshop and it's all documented here now in the hands-on section we will be learning and exploring three types of routes which are the clear out a drought and pass through route we will not be covering the re-encrypt route in this workshop because we're we're focusing on introducing the concept of how you can secure your routes on red hat openshift so keep in mind um some prerequisites for this uh workshop uh first we will uh we would like to ask you to sign up uh for ibm cloud or log in through this track link it will help us track our efforts for this event in addition to that uh it will allow you access to free red hat open shift cluster on ibm cloud we have a provision them for you um and they're available for 24 hours after the workshop so you can play around at your own time at your own pace till the clusters are you know are done so after the workshop in case if you do not have the aussie cli you can also use the shell on ibm cloud and it has all of the clies you're going to need for this workshop so first we're going to start with um creating our projects and you know some simple commands when you're working on your um you know projects um on red hat openshift so first we're going to need to log into our cluster and you have to go to your overview page in which as you can see it shows you the administrator view now to the top top top right you will click on your username here and then you will find copy login command we're going to need this command to login to our cluster through the command line it will generate a token for us so that we can just display it and copy it and then paste it in in the cli here and now we have logged in into um our cluster now you can create your project using the aussie new project command which is like that then we can name it anything like um secure route demo now next thing is we're going to need to set up our cluster you know so uh in this section we will learn about how we can extract information about our cluster on ibm cloud this will help us because uh we will be using the certificate that's already provisioned by default for this cluster and you can do that by going to um this dashboard right here on ibm cloud as you can see and we're going to need to grab the cluster id so first thing before going there we're going to need to login to ibm cloud and you can simply go also to the top right and select on login to cli and api and select ibm cloud cli so you can log in and go back to your shell and copy the command now you will be authenticated to your account um you will be selecting the region uh you can select any region and then next thing is we're going to need to target the resources group and you can see that using this command which is ibm cloud target the default section is depends on your account so in my case i'm using the default name resourcing group it could be your email if it was your personal account or if it was um if it was in in the cluster that you're using from the provisioned ones so you can find it actually here let me take a look at it somewhere yeah it's in the resources group it is it is right there so you can find the information about your resource group and copy it in the ibm cloud target command and then next thing is we're going to view information about our cluster using the ibm cloud or cnlb dns command so you can just copy it all the way to cluster and then you can copy it with the name of the id of your cluster or with you with you with the name of your own cluster so you can get the name of the cluster from this section here and just add it to this command so as you can see here you will actually get a nice view of i will actually zoom out a little bit to see to see it nicely to view the information it's okay if it was a little bit small font but in this one it's actually showing the hostname of your cluster so this is the hostname and then it's showing you the ips the heart monitor and the ssl certificate and then the name of the ssl certificate that we will be using in the next two steps we'll be using it when we're going to secure our route it has information about the key and certificate of our cluster and it's actually saved in openshift ingress in the future steps we will explore um the secret in the namespace and see it so like using openshift commands so first we're going to demonstrate um you know the clearout using a simple application which is the guestbook application we're going to use the aussie create deployment command which which we can create a deployment out of it and simply just copy and paste the command to your command line and if you use i see that pods you will view information about your pod that is being created currently it's in container creating state just give it a few minutes maybe till it's running as you can see so next thing is we're going to need to expose the deployment and to get a service out of it this service will help us to expose uh this will expose it to the external access so we can you know view it from our devices so simply you would uh use oc exposed deployment command and then we're we're specifying the port of this deployment so just simply copy and paste the command and then you will you can take a look at it using the oc get service command and as you can see it's providing with information about it so you can see my guest book the name of it with a type and the cluster ip but we haven't exposed it to the external access yet so the external ip is unidentified and then it's providing also information about the parts and the age so to simply create um the insecure route you can just use the aussie expose command and then we're going to go with service then my guest book and it will create a route for us so if we go with or see the trouts it will show us um the the the address of uh of the service that we have exposed just now so if we copy and paste it we can view the application and as you can see it shows here at the top left that it is not secure so the connection is not secure and we really don't want that in you know in real life scenarios where it's really important to care for our data and that's how we're going to that's what we're going to do in the next step and as you can see also it doesn't show you what is the type of determination like uh determination in this case it's clear but in the next two steps you will see that's going to show you either edge or pass through but first before but first before creating the edge route we have to extract the ssl certificate and the create and and use this certificate for our route and the first thing uh make sure to just delete it so there wouldn't be any um redundancy in in your uh in your in your address so use or see delete route and then the name of the service that you have created next thing is we're going to extract the secret and like i mentioned earlier that we discovered that the secret that we will be using is in openshift ingress project so you can get the secrets um using the aussie get secrets command in dash and open shift ingress to get information about what are the secrets that you have for your ingress in in the cluster the default secret is that is usually named uh after after the name of your cluster and similarly to my case it's called my cluster master then followed by an id so it uh you just have to copy it so we can use it in the next command keep in mind you can notice actually that the secret is of type tls there are different types of secrets like generic and tls tls is used for certificates and security when it comes to um allowing access to your services so the first thing is we're going to need to extract the secret using aussie extract command now after we got the name of our secret we just need to extract it and save it somewhere first let's review how it's going to look like so just simply replace this command sorry replace the name of the for the secret with your taylor secret here this command actually shows us um the the inside of the secret in in the command line using the two and then space dash uh command so you can use the same command to save it in a file and we will demonstrate in the next step as you can see this these are the secrets of my cluster and for example it has different files uh two files actually tls key with information about uh like npm encoded files uh all of these are the information of my certificate and the key as you can see so next thing is we're going to use the same command but we're going to save it in a directory and that is by using the uh like as you can see the difference is going to be uh just adding a directory instead of adding space so just remove the dash in your command and uh add the directory which is search for word temp it's a temporary directory it can be any directory actually not necessarily um temp um and if you actually do ls stamp i believe um td10 and then okay i mean it's already saved in the in the directory i cannot access it but it's when once you're going to extract the secrets you will see it saved in it will give you this output that it is saved and you can use them which we will be doing in the next step for creating the edge route creating the edge route is actually pretty simple and is stressed straightforward you would just use the command or c create route and then you're going to specify which is edge in other types of routes like pass it through and re-encrypt you just replace it with the with our respective names and then we're providing with a service and then the name of the service and the directory of the key and certificate so we provide them in the command itself so simply copy and paste it now keep in mind if you have it in a different directory make sure to change it so just go to um yeah as you can see here it has created the route for us so if we go with or see the trunks command it will show us the route that we just created and as you can see it's actually showing us that the termination type is of edge which means it's an edge out so if you copy and paste it in your um in your browser now it's showing me that the application is not available and that's because it's an https protocol you have to actually make sure that you're going to add https at the beginning but you can also change that so there are different ways of handling it um so once you're going to copy and paste it you have to add just https at the beginning um and you can see that it's showing us that the connection is secure and if you click on certificate you will see that it's valid and it's providing us with information about the certificate there are different ways when you're working with secured routes and how you're going to handle insecure traffic you can actually view it um in routes i believe so if you create a route and then secure out so there are different ways of handling insecure traffic like non allow or redirect so if it was none which means in our case you will see it's going to show you that the application is not available but if you allow it it you won't have you it will be over http not https and and the finally which is the redirect which once you type any insecure traffic it will automatically redirect you to the secure traffic you can also do the same thing in the command line so now that we have viewed the clear out and the edge out we're going to move on to the last round that we're going to demonstrate which is the passive through route now the passer throughout is a little bit different than edge out and so we will we're going to need to create a new application that is specifically designed for the passive throughout there are a few things that we have to keep in mind like ssl uh encryption inside the application and that's why uh we have this image that we have built uh which which will be building our application and we're going to view the contents of it in a bit now just simply copy this command which is aussiecreate.f and then it's going to show you the get row code of it in from github so this actually has created for us the deployment and the service and if you use aussie get pods you will see that the application is currently in running state if we take a look at the contents of the ammo definition of this project of this application sorry you will see that we have created a deployment config and a service now the application is using an image that is provided here you can view the content of the image as you wish and we've also provided the volume mounts because we will be mounting later on with the certificate so the volume mount is using the tls cert with the mount path of this path is specified here this is actually different than when using edge like you don't really have to specify a volume mount uh for your secret and uh you know for your certificate for your project and then next thing which is the service this is simply uh this is simply the service of our deployment and it is exposed over port 8443 so next thing is we're going to need to create a secret so after we created the application going to need to create the secret that we will be using in our um in our route so here's the a secret secret tls so this is the type of the secret as i mentioned earlier we have two types of secrets uh generic and tls and then this is the name of this secret which is my cert as i as you have seen earlier we actually uh have it uh here the name of the mount here is also now this is the taylor secret yeah this is the secret name here which is my cert so we did specify it earlier when we were creating our um our deployment config but we're going uh to create a secret so we're going to mount it later so and then we're specifying what are the components of the secret and in our case which are the cert certificate and the key so uh with the so you have to use the parameter assert and key and then provide with the path of each one of these so copy and paste it in the command line and if you use uh seagate secrets you will see that you will see that it has been created for you so this is the secret that i just created just now so next thing after we created the secret we want to use it so whenever you want to use a secret you have to mount it to your volume so you wouldn't you would be able to use it whenever you want so and that is by using rc set volume and then we're specifying that uh we're specifying like the deployment config in which is go line https and we're adding it and then we're providing with the secret which is the type secret and then the mount path which is the path that we specified earlier in our deployment in the ammo definition as you can see here yes and then uh the name of the certificate and then the name the name of the volume and then the name of the secret that we just created so now that we have created the now that we have mounted the secret to the volume we can create the pass through and we do not really need to do anything uh with with a pass it through uh like similar to edge we're just using a secret command and then adding the passive through instead of edge name of the uh service that we want to i mean name of the route and then the name of the service as you can see we did not use add any extra parameters because we have mounted the secret because you know that pass it through is actually secured on the pod level and we don't really need to create to secure it on that on the cluster level so just paste the command and you can use or see get routes again you will see that it has created the route for us and the termination is of type pass it through as you can see it here if you copy the route address and view it on your browser also make sure that if you haven't specified the insecure traffic configurations to add https at the beginning and there you go you have your application ready um it's just a simple interface it's telling you hello and showing you the time and as you can see here as well that if you want to view the certificate the connection is shown secure and the certificate is valid which is good this is what we want in our real life scenarios and so actually that leaves us at the end of this workshop so we simply covered uh three types of routes as you mentioned which were the um clear out which is insecure the edge route which is secure on the cluster level on the external level and then the passive through which is secure on the pod level now um hopefully that you have actually learned from this tutorial hopefully you found it useful you can find this resource to view the tutorial whenever you want it's available through this github link here and one more thing before we actually wrap up i want to announce to you um digital conferences by ibm so ibm digital conferences if you do not know what they are they're actually um conferences that cover different uh topics so like ai ops kubernetes uh coffee code and much more so we would highly encourage you to go to developer.ibm.com forward conferences you will find all of the on-demand sessions and workshops and talks on everything that you would be interested in you will see um for example one of the recent conferences was on ai ops and integration but we also have much more conferences you can check conferences replace at the at the bottom when you scroll down and you will see um digital developer conference hybrid cloud open source um call for code and much more so if you are passionate about technology and you probably interested to learn more about you know the hot technologies then uh just make sure to visit developer.ibm.com forward conferences and have a good day

Channel: IBM Developer

Views: 311

Rating: 5 out of 5

Keywords: Software Development, Application Development, Artificial Intelligence, Machine Learning, Cloud Computing, Data Analytics, Technology, programming, coding, programming languages, learn coding, learn to code, mobile application, IBM, IBM Developer, IBM Code, open source, open technology

Id: 9J_RPFZgRo8

Length: 36min 19sec (2179 seconds)

Published: Wed Apr 28 2021