Table of Contents
Introduction
Istio TLS configuration is one of the essential features when we enable a Service Mesh. Istio Service Mesh provides so many features to define in a centralized, policy way how transport security, among other characteristics, is handled in the different workloads you have deployed on your Kubernetes cluster.
One of the main advantages of this approach is that you can have your application focus on the business logic they need to implement. These security aspects can be externalized and centralized without necessarily including an additional effort in each application you have deployed. This is especially relevant if you are following a polyglot approach (as you should) across your Kubernetes cluster workloads.
So, this time we’re going to have our applications just handling HTTP traffic for both internal and external, and depending on where we are reaching, we will force that connection to be TLS without the workload needed to be aware of it. So, let’s see how we can enable this Istio TLS configuration
Scenario View
We will use this picture you can see below to keep in mind the concepts and components that will interact as part of the different configurations we will apply to this.
- We will use the ingress gateway to handle all incoming traffic to the Kubernetes cluster and the egress gateway to handle all outcoming traffic from the cluster.
- We will have a sidecar container deployed in each application to handle the communication from the gateways or the pod-to-pod communication.
To simplify the testing applications, we will use the default sample applications Istio provides, which you can find here.
How to Expose TLS in Istio?
This is the easiest part, as all the incoming communication you will receive from the outside will enter the cluster through the Istio Ingress Gateway, so it is this component the one that needs to handle the TLS connection and then use the usual security approach to talk to the pod exposing the logic.
By default, the Istio Ingress Gateway already exposes a TLS port, as you can see in the picture below:
So we will need to define a Gateway that receives all this traffic through the HTTPS and redirect that to the pods, and we will do it as you can see here:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: bookinfo-gateway-https
namespace: default
spec:
selector:
istio: ingressgateway
servers:
- hosts:
- '*'
port:
name: https
number: 443
protocol: HTTPS
tls:
mode: SIMPLE # enables HTTPS on this port
credentialName: httpbin-credential
As we can see, it is a straightforward configuration, just adding the port HTTPS on the 443 and providing the TLS configuration:
- We will use a SIMPLE mode, also known as one-way TLS, where only the server is authenticated but not the clients. This is the usual configuration for any web page or web service.
- We will provide a credentialName that is a TLS secret that has the certificates required to expose and generate the TLS gateway. We used the steps available on the Istio official documentation to create this secret: https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#generate-client-and-server-certificates-and-keys
- We will provide a credentialName that is a TLS secret that has the certificates required to expose and generate the TLS gateway. We used the steps available on the Istio official documentation to create this secret: https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#generate-client-and-server-certificates-and-keys
And with that, we can already reach using SSL the same pages:
How To Consume SSL from Istio?
Now that we have generated a TLS incoming request without the application knowing anything, we will go one step beyond that and do the most challenging configuration. We will set up TLS/SSL connection to any outgoing communication outside the Kubernetes cluster without the application knowing anything about it.
To do so, we will use one of the Istio concepts we have already covered in a specific article. That concept is the Istio Service Entry that allows us to define an endpoint to manage it inside the MESH.
Here we can see the Wikipedia endpoint added to the Service Mesh registry:
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: se-app
namespace: default
spec:
hosts:
- wikipedia.org
ports:
- name: https
number: 443
protocol: HTTPS
resolution: DNS
Once we have configured the ServiceEntry, we can define a DestinationRule to force all connections to wikipedia.org will use the TLS configuration:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: tls-app
namespace: default
spec:
host: wikipedia.org
trafficPolicy:
tls:
mode: SIMPLE📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.
