The Istio service mesh offers cloud native deployments a standard way to implement automatic mutual transport layer security (mTLS). This reduces the attack surface of network communication by using strong identities to establish encrypted channels between workloads within the mesh that are both confidential and tamper-resistant. mTLS is a key component for building zero-trust application networks. To understand mTLS traffic encryption in Istio, this article will cover the following:
TLS, the successor to Secure Sockets Layer (SSL), is a widely adopted security protocol used to create authenticated and encrypted connections between networked computers. For this reason, people often use the terms TLS and SSL interchangeably. In this article, we will refer to them collectively as TLS. TLS 1.0 was released in 1999, and the latest version is 1.3 (released in August 2018); versions 1.0 and 1.1 are deprecated.
The HTTPS we see when browsing the web uses TLS, as shown in Figure 1, which is built on top of TCP as the session layer in the OSI model. To ensure compatibility, TLS usually uses port 443, but you can use any port you want.
TLS encryption is required when a client needs to confirm the identity of the server in order to guard against man-in-the-middle attacks and ensure communication security. Figure 2 shows how TLS-encrypted communication proceeds.
The above is only an outline description of the TLS communication flow. If you’re interested in the details, please see this in-depth discussion of the complete TLS handshake process.
From the above process, you will find that the certificate is the critical element representing the server’s identity. The server must use a certificate issued by an authoritatively certified CA in order to provide public services over the Internet. In contrast, you can manage certificates using your own public key infrastructure (PKI) for services inside of a private environment.
Mutual TLS, also referred to as mTLS, is the use of a two-way encrypted channel between a server and a client that necessitates certificate exchange and identity authentication between the parties.
TLS termination is the process of decrypting TLS-encrypted traffic before it is forwarded to a web server. Offloading TLS traffic to an ingress gateway or specialized device improves web application performance while securing encrypted traffic. TLS termination is typically implemented at cluster ingress. All communication between the ingress and servers in the cluster will be conducted directly over HTTP in plaintext, enhancing service performance.
By default, Istio enables mTLS for mesh-based services and ends TLS at the ingress gateway. Furthermore, you can pass through traffic to back-end services for processing.
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: sample-gateway
spec:
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: PASSTHROUGH
See Gateway TLS Configuration for details.
Figure 4 depicts the security architecture of Istio. This figure clearly shows that at the entry point, JSON Web Token (JWT) + TLS authentication and encryption are used, and that mTLS is enabled between all services within the Istio mesh.
Istio includes a built-in CA, and Secret Discovery Service (SDS)—one of the discovery services in Envoy xDS—enables the issuance and rotation of SVID certificates. The mTLS flow in the Istio mesh is as follows:
In Istio, authentication and authorization between services can be configured using one of three resource objects:
In PeerAuthentication, you can specify the mTLS mode that will be used for the target workload. Peer authentication is supported in the following modes:
Istio’s peer authentication uses PERMISSIVE mode by default, automatically sending mTLS traffic to these workloads and clear text traffic to workloads without a sidecar. After including Kubernetes services in the Istio mesh, we can use PERMISSIVE mode first to prevent services from failing mTLS. We can use one of two ways to enable strict mTLS mode for certain services:
The reviews service’s mTLS configuration in the default namespace can be seen in the example below.
For instance, the following configuration can be used to specify that a workload under a namespace has strict mTLS enabled.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: foo-peer-policy
namespace: default
spec:
selector:
matchLabels:
app: reviews
mtls:
mode: STRICT
According to the Istio documentation, you can also enable strict mTLS for all services in the mesh by configuring strict mTLS for the namespace istio-system where Istio is installed.
Traffic routing policies, such as load balancing, anomaly detection, TLS settings, etc., are set using DestinationRule. In the TLS settings, there are various modes. As shown below, use ISTIO_MUTUAL mode to enable Istio’s workload-based automatic TLS.
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: reviews
namespace: default
spec:
host: reviews
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
The short answer is that you should use mTLS for network communication between application components that you have some control over—like between microservices in a cluster.
One-way TLS is typically used by Internet clients to connect to Web services, which means that only the server needs to show identification and is unconcerned with the identity of the client. One-way TLS allows you to use passwords, tokens, two-factor authentication, and other methods when you need to confirm the identity of the client. However, when using a service mesh, mTLS operates outside the application and doesn’t require many changes to the application logic, whereas such an authentication method requires internal application support.
As you can see from the example above, mTLS implementation calls for certificate exchange between services. As the number of services rises, managing numerous certificates becomes a laborious task. You can implement automatic mTLS and fix the certificate management issue with the aid of a service mesh.
Although mTLS is the preferred protocol for securing inter-service communication in cloud-native applications, implementing mTLS necessitates a more complex, symmetric encryption and decryption process than one-way TLS. In some cases where there is high traffic volume or CPU utilization must be optimized, terminatingTLS at the traffic entry point and turning on mTLS internally for specific services only can help minimize request response times and decrease compute resource consumption for some traffic with lower security levels.
Additionally, it is necessary to disable probe rewriting for pods when using services that cannot obtain certificates, such as health checks performed via HTTP on Kubelet and the inability to access the service’s health check endpoint via TLS.
Finally, when mesh services access some external services, mTLS is also not necessary.
mTLS is a crucial component of creating a zero-trust application network, which makes it possible to encrypt traffic within the mesh. Istio makes it simple to enable automatic mTLS for Kubernetes services, doing away with the need to manage certificates. At the same time, we can selectively enable mTLS for a subset of the mesh’s services, enabling us to move services from Kubernetes to the mesh. In a subsequent blog, we’ll go into more detail about Istio’s certificate management system. Stay tuned.
If you’re new to service mesh and Kubernetes security, we have a bunch of free online courses available at Tetrate Academy that will quickly get you up to speed with Istio and Envoy.
If you’re looking for a fast way to get to production with Istio, check out Tetrate Istio Distribution (TID). TID is Tetrate’s hardened, fully upstream Istio distribution, with FIPS-verified builds and support available. It’s a great way to get started with Istio knowing you have a trusted distribution to begin with, have an expert team supporting you, and also have the option to get to FIPS compliance quickly if you need to.Once you have Istio up and running, you will probably need simpler ways to manage and secure your services beyond what’s available in Istio, that’s where Tetrate Service Bridge comes in. You can learn more about how Tetrate Service Bridge makes service mesh more secure, manageable, and resilient here, or contact us for a quick demo.
This blog was originally published at tetrate.io.
Last updated on Nov 27, 2024