Testing mutual TLS
Through this task, you will learn how to:
Verify the Istio mutual TLS Authentication setup
Manually test the authentication
Before you begin
This task assumes you have a Kubernetes cluster:
- Installed Istio with mutual TLS authentication by following the Istio installation task. Note to choose “enable Istio mutual TLS Authentication feature” at step 5 in “Installation steps”.
Verifying Istio’s mutual TLS authentication setup
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 Citadel is running:
$ kubectl get deploy -l istio=citadel -n istio-system NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE istio-citadel 1 1 1 1 1m
Citadel is up if the “AVAILABLE” column is 1.
Verifying service configuration
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_TLSis uncommented (doesn’t have a
Testing the authentication setup
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
productpage service, and send request to other services by curl.
There are several steps:
- get the productpage pod name
command $ 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”.
ssh into the Envoy container
$ kubectl exec -it productpage-v1-4184313719-5mxjc -c istio-proxy /bin/bash
make sure the key/cert is in /etc/certs/ directory
$ ls /etc/certs/ cert-chain.pem key.pem root-cert.pem
cert-chain.pemis Envoy’s cert that needs to present to the other side.
key.pemis Envoy’s private key paired with Envoy’s cert in
root-cert.pemis the root cert to verify the peer’s cert. In this example, we only have one Citadel in a cluster, so all Envoys have the same
- make sure ‘curl’ is installed by
command $ curlIf curl is installed, you should see something like
plain curl: try 'curl --help' or 'curl --manual' for more information
Otherwise run the command below to start over
$ kubectl apply -f <(istioctl kube-inject --debug -f samples/bookinfo/kube/bookinfo.yaml)
Istio proxy image does not have curl installed while the debug image does. The “–debug” flag in above command redeploys the service with debug image.
- send requests to another service, for example, details.
command $ 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 ... error fetching CN from cert:The requested data were not available. ... < 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 accounts 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 names, which is the information that
curl needs to verify server identity. As a result, we use
-k to prevent the
curl client from aborting when failing to find and verify the server name (i.e., productpage.ns.svc.cluster.local) in the certificate provided by the server.
Please check secure naming for more information about how the client verifies the server’s identity in Istio.
What we are demonstrating and verifying above is that the server accepts the connection from the client. Try not giving the client
--cert and observe you are not allowed to connect and you do not get an HTTP 200.
- Learn more about the design principles behind Istio’s automatic mTLS authentication between all services in this blog.