Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 394 of 8026. Kubernetes Traffic and ScalingFree lesson

Enforcing Mutual TLS for Secure Communication

You will implement mTLS to ensure all traffic between services is encrypted and authenticated by default within the mesh.

In this lesson, you will learn how to transition your service mesh from standard, unencrypted communication to enforced Mutual TLS (mTLS) to ensure every request between services is both authenticated and encrypted.

The Shift to Zero-Trust

In a standard Kubernetes cluster, any pod can typically communicate with any other pod over the network. If an attacker gains a foothold, they could sniff traffic or spoof services. By implementing mTLS within your mesh, we move to a "Zero-Trust" model where communication is only permitted if both the client and the server present valid, signed certificates issued by the mesh's internal Certificate Authority (CA).

Enforcing Peer Authentication

To enforce mTLS, we use an PeerAuthentication policy. This policy instructs the sidecar proxies (like Envoy in Istio) to reject any non-TLS traffic. When configured in STRICT mode, the service will refuse all plaintext connections, ensuring that every interaction within the mesh is cryptographically verified.

Here is how you apply a strict policy to a specific namespace:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: secure-app
spec:
  mtls:
    mode: STRICT

How it Works Under the Hood

  1. Sidecar Interception: Once the STRICT policy is applied, the sidecar proxy captures all incoming and outgoing traffic.
  2. Handshake: When Service A calls Service B, their sidecars perform an mTLS handshake.
  3. Identity Verification: The sidecars exchange certificates, verify the signatures, and confirm that both workloads belong to the trusted mesh.
  4. Encryption: Only after successful validation does the application data flow through an encrypted tunnel.

Because this happens at the proxy layer, your application code remains completely unaware of the complexity; it continues to send HTTP/gRPC requests as if it were talking to a local process. This "transparent security" allows you to achieve high-level encryption standards without refactoring your backend logic or managing manual certificate rotations yourself.

Key Takeaway: By setting your PeerAuthentication policy to STRICT mode, you enforce cryptographic identity verification for every packet, effectively neutralizing man-in-the-middle attacks within your service mesh.