Mutual TLS for service communication in Kubernetes - Commands & Configuration

Introduction

Mutual TLS helps two services talk to each other securely by checking each other's identity. It stops outsiders from listening or pretending to be one of the services.

When you want to make sure only trusted services in your cluster can talk to each other.

When you need to encrypt data sent between microservices to keep it private.

When you want to prevent attackers from impersonating a service inside your network.

When you want to add an extra layer of security without changing your application code.

When you want to comply with security rules that require encrypted and authenticated service communication.

Config File - istio-mutual-tls.yaml

istio-mutual-tls.yaml

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: default
  namespace: default
spec:
  host: '*.default.svc.cluster.local'
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

This file has two parts:

• PeerAuthentication: It tells Istio to require mutual TLS for all services in the default namespace.
• DestinationRule: It configures clients to use mutual TLS when talking to any service in the default namespace.

Commands

This command applies the mutual TLS settings to the Kubernetes cluster using Istio. It enables strict mutual TLS for service communication in the default namespace.

Terminal

kubectl apply -f istio-mutual-tls.yaml

Expected Output

peerauthentication.security.istio.io/default created

destinationrule.networking.istio.io/default created

This command checks that the PeerAuthentication resource is created and active in the default namespace.

Terminal

kubectl get peerauthentication -n default

Expected Output

NAME      AGE

default   10s

→

-n - Specifies the namespace to look in

This command verifies that the DestinationRule resource is created and active in the default namespace.

Terminal

kubectl get destinationrule -n default

Expected Output

NAME      AGE

default   10s

→

-n - Specifies the namespace to look in

This command checks the mutual TLS status between the client and the service pod named my-service-1234 in the default namespace.

Terminal

istioctl authn tls-check my-service-1234.default

Expected Output

HOST:PORT                    STATUS     CLIENT     SERVER     AUTHN POLICY

my-service-1234.default.svc.cluster.local:80   OK         mTLS       mTLS       default

Key Concept

If you remember nothing else from this pattern, remember: mutual TLS makes both services prove who they are before talking, keeping communication private and trusted.

Common Mistakes

Not applying both PeerAuthentication and DestinationRule resources.

Without both, either the server or client won't enforce mutual TLS, so communication won't be fully secure.

Always apply both PeerAuthentication to enforce server-side TLS and DestinationRule to configure client-side TLS.

Using permissive mode instead of strict mode in PeerAuthentication.

Permissive mode allows both encrypted and unencrypted traffic, which weakens security.

Set mtls mode to STRICT to require all traffic to use mutual TLS.

Not specifying the correct namespace when applying or checking resources.

Resources may be created or checked in the wrong namespace, causing confusion or failure.

Always use the -n flag with kubectl commands to specify the correct namespace.

Summary

Apply PeerAuthentication and DestinationRule to enable mutual TLS in the namespace.

Verify the resources are created with kubectl get commands.

Use istioctl tls-check to confirm mutual TLS is active between services.