Securing an Application

[john_boritz]

Is there a way in Openshift Container Platform version 4.5 to take an existing application running over an insecure route and convert it to run on a secure passthrough route? I can get it to work with an edge route with a self signed CA key. However, when running a curl against the passthrough route I get an SSL connection error.

Thanks.

[flozano · Accepted solution]

If the route is passthrough, by definition, the router only forwards packets to the destination. If you want true end-to-end encryption the application MUST support TLS itself.

Edge routes provide encryption between the client and the router, but not from router to the application, and re-encrypt provide encryption between client and router, and again between router and app, just using different TLS certificates so it is "end-to-end" but with the router seeing all your traffic.

So both passtrough and re-encrypt provide end-to-end ecryption. Passthough is the "most secure" (maybe "most private") if the application supports it because the router cannot inspect your traffic.

If you cannot touch the app and still require end-to-end encryption, the next best thing is using Service Mesh. It adds a side-car container to your pod that can things such as encrypting communication between client and side-car, or between router and side-car. Then the side-car talks, without encryption, to your application, but this happen inside the pod, with no packets sent over the network. So theoretically it is almost as good as passthrough routes.

[john_boritz]

Thanks Fiozano I appreciate this. In my orgainization we have some applications that have a secure and insecure version. However there are a few applications with only an insecure version. How can you tell if the application is an insecure version or a secure version that will allow TLS certificates?

[flozano · Accepted solution]

You have to ask whoever developers the app, or its vendors. TLS support is not something you can configure in. It is coded as part of the application. And if the app have this feature as optional, each app has it's own way to enable it.

The best I can think of an "external" way to test it is trying an https connection and if it works, it has TLS enabled. If you don't want to accept an "untrusted" certificate from your web browser, just to check it it is self-signed (insecure) or signed by an internal CA, you can try curl or the openssl ssl_client.

https://serverfault.com/questions/661978/displaying-a-remote-ssl-certificate-details-using-cli-tools

[john_boritz]

Thalnks a lot. Appreciate your help.

[Chetan_Tiwary_]

@flozano Thanks for your response !

[evelinafranco]

 I appreciate this. In my orgainization we have some applications that have a secure and insecure version.

[Chetan_Tiwary_]

@evelinafranco posting any malicious / shopping / spam link is not allowed in this community. As a moderator - I have removed the link from your post. 

[Hardik1]

In OpenShift Container Platform (OCP) version 4.5, converting an existing application running on an insecure route to a secure passthrough route involves a few steps to ensure proper SSL termination and certificate handling.

Here's a general guide to help you convert the existing insecure route to a secure passthrough route:

1. Obtain a valid SSL certificate: Obtain an SSL certificate signed by a trusted certificate authority (CA) for your domain. You may use tools like Let's Encrypt or purchase a certificate from a CA.

2. Create a TLS secret: In OpenShift, create a TLS secret to store your SSL certificate and private key. You can use the oc create secret tls command to create this secret, specifying the certificate and private key files.

   oc create secret tls your-tls-secret --cert=path/to/your/cert.crt --key=path/to/your/private-key.key

3. Modify the existing route: Edit the existing insecure route to use the TLS secret you created. You'll need to change the route's type to "passthrough" and specify the secret to terminate SSL traffic at the router level.

   oc edit route your-route-name

   Inside the route configuration, change the following fields:

   spec: to: # ... existing configuration tls: termination: passthrough insecureEdgeTerminationPolicy: Redirect key: your-tls-secret # Name of the TLS secret created in step 2

4. Verify and test the passthrough route: Once the route is updated, verify that the changes have been applied correctly by checking the route's details.

   oc get route your-route-name

   Test the secure passthrough route using curl or a web browser to ensure it's properly configured and SSL connections are established without errors.

   curl https://your-route-url

If you encounter SSL connection errors after configuring the passthrough route, ensure that the TLS secret is correctly created, the certificate and private key files are valid, and the route's configuration is updated accurately.

Additionally, if you're using a self-signed certificate, ensure that the client making the curl request trusts the certificate authority that signed the server's certificate. This often involves adding the CA certificate to the client's trust store.

Always use valid and trusted SSL certificates in production environments for secure communication.

[Chetan_Tiwary_]

Thanks @Hardik1