 Hello everyone. This video is about using SSL with OpenShift. There are a couple of different options that OpenShift provides for using SSL, and we will look at those different options. To begin with, I have deployed a KitchenSync Java application. It's already running and it's not using SSL. Let me open this and show it to you. Put in a new window. This is the Java application running. If I try to use it with HTTPS, it says no service available, but with HTTP, it works. Now let's see what kind of changes we need to make through this application to enable SSL. We have an application that has no SSL, and the way in which this is set up in OpenShift is there are a bunch of parts, for example, for your application running, and there is a route that is configured inside the router and as a user, you are trying to reach this application with the HTTP-based URL. It goes and hits the router and the router redirects it to one of the parts. This is how a simple application with no SSL works. The first step, we'll see how to enable SSL for this application using a process called EdgeTermination. In EdgeTermination, the user asks for the app using HTTPS-based URL using SSL between the browser, the client, and the router. The traffic is encrypted between the browser and the router, and the SSL terminates at the router, and from there on, the traffic between the router and your application, which is within the scope of your environment, could be unencrypted. In order to enable EdgeTermination, we have to make a small change to this route. So let's have a look at the route. I'll switch the project. Let's see what routes we have. Now, we'll edit this route for the change that I'm talking about. Here, under the spec, you see the host. This is the host name or the URL. Right under this, I'll add a section called TLS and we'll set the termination as EdgeTermination. I'll save this. At this point, SSL will work with EdgeTermination and TLS termination occurs at the router prior to proxying traffic to its destination. The TLS certificates are served by the front end of the router. So they must be configured into the route if you have TLS certificates to be configured. Otherwise, in our case, since we did not configure any certificates, TLS default router certificate would be used for termination. So if I test the application now with HTTPS, this application is running. Earlier when we tried HTTPS, we got a service not available, but now it is running with HTTPS. That means the TLS Edge termination is working. Now, we'll see how to configure a certificate into this route. So first, for this purpose, I'll use a self-signed certificate. I'll create a self-signed certificate using the key tool. So let's say I'm using key tool to generate a certificate. It's a self-signed certificate. It'll generate a keystore.js file. It has a password supersecret and all that stuff. So I keyed in all the values it asked for, and now it has generated a keystore file. Now, in order to use the certificate and the private key that got generated along with this, there is a little curve on a Mac. I have to convert this into pkcs12 format thanks to my colleague Ram who has provided this information. So all I did is I used the key tool to convert this key format from JKS format to the pkcs12 format. Here is my output file. Now, I'll use OpenSSL to see the values of certificate and private key. This OpenSSL, it shows me... I'm just passing that password that I set as supersecret before, and now it is showing me the private key and the certificate. I'll be using this information to... Let me first copy the private key and certificate. Now, I'll edit the route again to add this private key and certificate to the route for edge termination. Right below where we added the termination as edge, I will add the certificate and key sections there. I pasted the value of key and also placed my certificate here and I pasted the value of certificate. The alignment is important in a ML file. I'll say this route with these changes and now my route is ready with my certificates as well. So that is how edge termination can be used with certificates. Now, let's talk about the next type of termination model which is pass through. In this case, the encrypted traffic with pass through termination, the traffic is sent straight to the destination without the router providing any TLS termination. Therefore, no key or certificate is required at the router level. So you would not configure anything into the route. On the other hand, the destination part would be responsible for serving certificates for the traffic at the endpoint. So we would have to some way provide the certificate that we created earlier to the destination and we'll go through how to do that. So for this purpose, I created a new project. I called it pass through. Let me switch over to that project. Now, if you remember, we used this command, the key tool command to create the key store earlier. We'll be using that key store. I'm not running this command now, but I just wanted to show you what we did before. We created a key store by using this command and we had a password of super secret. We will be using this password as well. Now we have a key store here that we created earlier. So we will use this key store to create what we call a secret in this project. Secrets are storage for sensitive information such as keys, passwords, and certificates, and these are accessible by the intended pods. So remember what I said before? We have the traffic reaches all the way to the pod and pod is responsible for serving certificates and the secrets are a way in which we are making the certificates available to the pod so that it can serve those certificates. So all I'll do is create a secret now by using this command. I'm saying OC secrets and I'm creating a new secret. The name of the secret is EAP app secret and I'm using this key store.js file which has my self signed certificate. I'm mounting that certificate now as a secret into this project with name pass through. Now if I say OC get secrets, I should find all the secrets associated with the project. There are some secrets that are created when a project is created by default. Builder secrets and deployer secrets and the default secret are those. What you'll see is this is the one that just got created and if I look at what the secret looks like, OC get secret as a JSON. I see that this secret has some metadata and the data of this is coming from the keystore.js file and this is all the content. Easy. Now there is one more step to use this secret. We need a service account and the service account will allow your application to use that secret in order to enable that SSL traffic. Let's look at what service accounts we have right now. I can say service account or simply SA. Right now there is a service account for builder, service account which is default for the project and a service account for deployer. We'll create another service account. I am echoing a JSON here to create based on this file that is echoed here. I am trying to create a service account and I am naming the service account as EAP service account and I am also saying that this service account would be using this so and so secret and this is that EAP app secret that we created in the last step. The secret got created first and we are making the service account use this EAP app secret. I will run this command now and now if I look at the list of service accounts, EAP service account is now created and if I look at the contents of the service account, one of the secrets that it is using is this EAP app secret that we created before. Now we are ready to launch a HTTPS based application and that part is easy because we do have a template for creating an HTTPS based application. So I am creating a new application and I will create an application based on a template and for this I am using a EAP HTTPS STI template. STI stands for source to image. So if I will change a few parameters, I will call this secure application and then let it pick up the default host name. I don't want to change that. I will just run the default KitchenSync application that this template deploys. I don't want to change it but what I am interested in here is look at this EAP HTTPS secret. I want to use the EAP app secret. This is the one that we created. The default name is given as EAP app secret. That's the reason why I mounted it that way. If you wanted to create a secret with a different name, I could have called this my secret and then I could have changed the name here. I am also saying that the key store files name is keystore.jks. If the key store name was different, then we could have changed this name. Now the HTTPS name, I call the alias as self signed. I will call it the same here and the password, remember when we created the key store, we gave a password as super secret and I am using the same thing here. Now I will just press on this create button. Now this will go ahead and deploy the default KitchenSync application that comes with this template and as you can see there are two routes that got created. One is the regular HTTP route which is not secure and the other one is the HTTPS SSL based route. So two routes for the same application got created. Now in a couple of minutes, there will be a build process that will get started and once the build is complete, the application will get deployed. This will take a couple of minutes so I will pause and I will come back once the build and deployment is complete. Now the application is built and deployed. I will scroll over to the HTTPS based route and let me open that part of the application. So the security warning and here is the running application using HTTPS. Now in this case, this application is using pass-through termination. If I say OC get routes, I see these two different routes. One is the secure route, this HTTPS route and this secure route is set with the TLS termination of pass-through. Let me also show it as YAML so that you can compare with what you've seen before. Here the termination is set as pass-through. Now who set this pass-through termination? It's coming from the template. When you deploy that particular HTTPS STI template, the termination is set to pass-through when the route got created and all we did was we set up a secret and we enabled secret via the service account. Now the pod can serve the certificates by using the secret. Now the third kind of termination method that OpenShift allows is called a re-encryption termination. In this case, a re-encryption is a variation of the edge termination where the router terminates TLS with a certificate and then re-encrypts its connection to the endpoint which may have a different certificate. Although the whole path on both sides of the router are encrypted, the re-encryption to the endpoint happens with a different certificate. Although I don't have an example to show how it works, the architecture guide talks about how it can be accomplished. Just like in case of edge termination, you would have TLS and the termination set to re-encrypt. In this case, you will provide two different kinds of things. One is the key that is used just like in edge termination, the private key, the certificate, and if you have a CR certificate, you would provide that as well. And for re-encryption, you will provide a destination certificate which will be used for encryption behind the router, that means between the router and your pod. I hope you enjoyed this video. Thanks a lot for watching.