Mutual TLS is a feature of Aspen Mesh with many benefits. It allows pods to authenticate with each other for better policy enforcement, protects pod-to-pod communication from malicious monitoring or manipulation, and can be used to enforce segmentation.

However, there are a few restrictions put on a workload when mTLS is enabled. If a workload is affected, these must be worked around,or mTLS must be disabled on the workload which will be explained in the following steps.

Aspen Mesh deployments have Mutual TLS (mTLS) enabled by default! This means all the traffic between services within the cluster is encrypted and secure based on TLS.

You can verify this by going to https://my.aspenmesh.com and viewing the state of the cluster.

You can also verify this from the CLI.

curl -L https://git.io/getLatestIstio | sh -
cd istio-*
sudo mv -v bin/istioctl /usr/local/bin/
cd ~

Deploy the following demo application to the cluster:

kubectl apply -f <(istioctl kube-inject -f tls-demo.yaml)

Istio automatically installs necessary keys and certificates for mutual TLS authentication in all sidecar containers. Once the Pod is running, run command below to confirm key and certificate files exist under /etc/certs:

kubectl exec $(kubectl get pod -l app=httpbin -o jsonpath={.items..metadata.name}) -c istio-proxy -- ls /etc/certs

You can also use tls-check to ensure that a Pod-to-Pod communication has TLS. In this case, we are checking that a client is accessing HTTPBin URL running in a separate Pod over TLS.

SLEEP_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
istioctl authn tls-check ${SLEEP_POD} httpbin.default.svc.cluster.local

While Aspen Mesh recommends you configure to have mTLS enabled by default, it is possible to disable it for certain situations.

To disable mTLS on a service or port of a service, you will need to create or modify an authentication policy for that service, and also create or modify a DestinationRule.

As example, let’s disable mTLS on port 1234 for the “example “service in the “default” namespace.

First, create the following authentication policy to disable mTLS on that port. Note that it specifies the service name and port in the target. It doesn’t include a peers section, which disables mTLS.

cat <<EOF | istioctl create -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
    name: disable-tls-httpbin-8000
    namespace: default
spec:
    targets:
    - name: httpbin
      ports:
      - number: 8000
EOF

If the target ports are omitted, then this policy will disable mTLS on all ports for the service.

The previous step disabled mTLS configuration for the service. However, consumers of the service within the cluster will still be expecting TLS to be required. As a result, if you send a HTTPS response then it will fail.

kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl https://httpbin:8000/headers -o /dev/null -s -w '%{http_code}\n'

This will error with code 35 relating to TLS. This is what the current consumers of the service will be experiencing.

To fix the error, TLS needs to be disabled for the consumers of the service. This is done by modifying the DestinationRule for the host.

To do that, create the following DestinationRule. Note that the default policy leaves mTLS enabled by specifying ISTIO_MUTUAL, and disables TLS only on port 8000.

cat <<EOF | istioctl create -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
    name: "example-dst-rule"
    namespace: default
spec:
    host: httpbin.default.svc.cluster.local
    trafficPolicy:
        tls:
            mode: ISTIO_MUTUAL
        portLevelSettings:
        - port:
            number: 8000
          tls:
            mode: DISABLE
EOF

Now, consumers of the client will not use TLS for communication.

kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://httpbin:8000/headers -o /dev/null -s -w '%{http_code}\n'