Through this task, you will learn how to:
Verify the Istio mutual TLS Authentication setup
Manually test the authentication
This task assumes you have a Kubernetes cluster:
The following commands assume the services are deployed in the default namespace. Use the parameter -n yournamespace to specify a namespace other than the default one.
Verify the cluster-level CA is running:
kubectl get deploy -l istio=istio-ca -n istio-system
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE istio-ca 1 1 1 1 1m
Istio CA is up if the “AVAILABLE” column is 1.
Verify AuthPolicy setting in ConfigMap.
kubectl get configmap istio -o yaml -n istio-system | grep authPolicy | head -1
Istio mutual TLS authentication is enabled if the line
authPolicy: MUTUAL_TLS is uncommented (doesn’t have a
When running Istio with mutual TLS authentication turned on, you can use curl in one service’s
envoy to send request to other services.
For example, after starting the BookInfo
sample application you can ssh into the envoy container of
and send request to other services by curl.
There are several steps:
kubectl get pods -l app=productpage
NAME READY STATUS RESTARTS AGE productpage-v1-4184313719-5mxjc 2/2 Running 0 23h
Make sure the pod is “Running”.
kubectl exec -it productpage-v1-4184313719-5mxjc -c istio-proxy /bin/bash
cert-chain.pem key.pem root-cert.pem
Note that cert-chain.pem is envoy’s cert that needs to present to the other side. key.pem is envoy’s private key paired with cert-chain.pem. root-cert.pem is the root cert to verify the other side’s cert. Currently we only have one CA, so all envoys have the same root-cert.pem.
curl https://details:9080/details/0 -v --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem -k
... < HTTP/1.1 200 OK < content-type: text/html; charset=utf-8 < content-length: 1867 < server: envoy < date: Thu, 11 May 2017 18:59:42 GMT < x-envoy-upstream-service-time: 2 ...
The service name and port are defined here.
Note that Istio uses Kubernetes service account as service identity, which offers stronger security than service name (refer here for more information). Thus the certificates used in Istio do not have service name, which is the information that curl needs to verify server identity. As a result, we use curl option ‘-k’ to prevent the curl client from verifying service identity in server’s (i.e., productpage) certificate. Please check secure naming here for more information about how the client verifies the server’s identity in Istio.