Would want to use a trusted cert and set verify to a non-zero value. Generating a self-signed cert for this example. ![]() Stunnel-demo.rhel-cdk.10.1.2.2.xip.io:443 (replace with your stunnel route),Īnd for this demo turns off validation of the server’s cert since we are This configuration tells stunnel to act as a client, to listen locally on portĥ002, to forward all traffic received on that port to You can create a new Docker build based on this repository ( oc new-build -strategy=docker -name=stunnel ) or to get a fully working demo you can download the stunnel-example.yml file from the repo and run the following commands:Ĭonnect=stunnel-demo.rhel-cdk.10.1.2.2.xip.io:443 A default stunnel configuration file that tells stunnel to listen for incoming tunnel connections on port 5000 and forward all traffic to localhost:5001.It also modifies the stunnel configuration if environment variables are defined. If a certificate isn’t inject at runtime, this script will generate a self-signed certificate. A shell scripts that runs in the container.A DockerFile for building a stunnel Docker image that can run on OpenShift. ![]() I’ve published everything you need to get an stunnel container running on OpenShift to /cpitman/stunnel-openshift. For example, if we had an internal set of applications that used an insecure TCP protocol in our data center, we could use stunnel to quickly secure inter-server traffic. Quick Aside: Although we’re talking about a specific use case here (tunneling TCP traffic into Openshift), the exact same technique works anytime we need to take an unsecure TCP protocol and tunnel it over an insecure network. We run two instances of stunnel: a server instance inside our OpenShift pod that will terminate the tunnel, and a client instance running outside of OpenShift with our client to initiate the tunnel. If both conditions are not met, an alternative is to tunnel traffic over TLS. In order for TCP connections to use the router, they need to be encrypted with TLS and the client needs to support Server Name Indication (SNI). Ideally, we could use standard Routes for all traffic, including TCP. ![]() Both NodePort and External IPs require some amount of configuration of routing, load balancing, and firewalls to work. In a previous post I outlined the standard techniques used with OpenShift to connect TCP clients outside of OpenShift with TCP servers running inside of Openshift’s SDN. Stunnel and OpenShift (or any other virtual hosting)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |