This example demonstrates the example for acheiving 2way ssl on both ingress ( inward traffic) as well as egress ( outward network traffic ) using Envoy
If you are not aware about how 2 way ssl works or how it is different from 1 way ssl . Please refer to this article
For generating self-signed , I found this link to be quiet helpful. Ensure however that the common name used for client/server certificate should be different from the common name used for the CA certificate
This project is simply an extension of my previous project where I create getting started example on using Envoy as a load balancer. Please visit this link to have a look.
However this project is a little bit different from the previous setup . Here tls context ( downstream tls context ) has been introduced in the edge envoy to carry out tls termination against downstream insecure traffic. Also one of node applications ( service 2 ) has been protected and hence the sidecar/service envoy for that application now handles the upstream tls context ( cluster upsteam tls context ). The set up of the project can be described roughly in the diagram below
The project comes with a docker-compose file which can be used as it is
Step1: Build the project
docker-compose build
Step2: Bring up the envoy containers using docker-compose
docker-compose up
Step3: Verify service 1 is up and running
curl -k -v --cert front-envoy-proxy/certificates/clientB-crt.pem --key front-envoy-proxy/certificates/clientB-key.pem https://localhost:8443/service/1
Expected response : TLS Handhake steps + Hello I am a simple express api service 1 with a sidecar envoy proxy and I am unprotected
Step4: Verify service 2 is up and running
curl -k -v --cert front-envoy-proxy/certificates/clientB-crt.pem --key front-envoy-proxy/certificates/clientB-key.pem https://localhost:8443/service/2
Expected response : TLS Handshake steps + Hello I am a simple express api service 2 with a sidecar envoy proxy attached and I am protected
Step5: Verify service 3 is up and running
curl -k -v --cert front-envoy-proxy/certificates/clientB-crt.pem --key front-envoy-proxy/certificates/clientB-key.pem https://localhost:8443/service/3
Expected response : TLS Handshake steps + Hello I am a simple standalone express api service 3 and I am protected
The reason for using -k option with curl is because of the reason mentioned in their manuals as shown below -k/--insecure
(SSL) This option explicitly allows curl to perform "insecure" SSL connections and transfers. Starting with curl 7.10, all SSL connections will be attempted to be made secure by using the CA certificate bundle installed by default. This makes all connections considered "insecure" to fail unless -k/--insecure is used.
The certificates I have used in this project are self signed and hence it will not work with the --cacert option
If needed you can make changes to the service code and build the dockerfile using your own tag . You can even build your own certificates if you want using the CA certificate bundle installed by default
- Express - The framework used for developing simple services ( service1 and service 2 )
- Soumya Mukhopadhyay