cancel
Showing results for 
Search instead for 
Did you mean: 
john_boritz
Mission Specialist
Mission Specialist
  • 3,351 Views

Securing an Application

Jump to solution

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.

Labels (1)
2 Solutions

Accepted Solutions
flozano
Moderator
Moderator
  • 2,985 Views

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.

View solution in original post

flozano
Moderator
Moderator
  • 2,972 Views

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

 

View solution in original post

10 Replies
flozano
Moderator
Moderator
  • 2,986 Views

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
Mission Specialist
Mission Specialist
  • 2,976 Views

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
Moderator
Moderator
  • 2,973 Views

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
Mission Specialist
Mission Specialist
  • 2,965 Views

Thalnks a lot. Appreciate your help.

Chetan_Tiwary_
Community Manager
Community Manager
  • 1,489 Views

@flozano Thanks for your response !

0 Kudos
  • 2,959 Views

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

0 Kudos
Chetan_Tiwary_
Community Manager
Community Manager
  • 1,486 Views

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

Chetan_Tiwary__0-1703007264531.png

 

Hardik1
Cadet
Cadet
  • 1,941 Views

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.

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_
Community Manager
Community Manager
  • 1,485 Views

Thanks @Hardik1 

0 Kudos
Join the discussion
You must log in to join this conversation.