istio.io/_docs/tasks/istio-auth.md

title	overview	order	layout	type
Testing Istio Auth	This task shows you how to verify and test Istio-Auth.	100	docs	markdown

{% include home.html %}

Through this task, you will learn how to:

• Verify Istio Auth setup

• Manually test Istio Auth

Before you begin

This task assumes you have:

• Installed Istio with Auth by following the Istio installation task. Note to choose "enable Istio Auth feature" at step 5 in "Installation steps".

Verifying Istio Auth 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.

Verifying Istio CA

Verify the cluster-level CA is running:

kubectl get deploy -l istio=istio-ca

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.

Verifying service configuration

1. Verify AuthPolicy setting in ConfigMap.

   kubectl get configmap istio -o yaml | grep authPolicy | head -1
   

   Istio Auth is enabled if the line authPolicy: MUTUAL_TLS is uncommented.

2. Check Istio Auth is enabled on Envoy proxies.

   When Istio Auth is enabled for a pod, the ssl_context stanzas should be in the pod's proxy config. The following commands verifies the proxy config on app-pod has ssl_context configured:

   kubectl exec <app-pod> -c proxy -- ls /etc/envoy
   

   The output should contain the config file "envoy-rev.json". Use the file name in the following command:

   kubectl exec <app-pod> -c proxy -- cat /etc/envoy/envoy-rev<X>.json | grep ssl_context
   

   If you see ssl_context lines in the output, the proxy has enabled Istio Auth.

Testing Istio Auth

When running Istio auth-enabled services, 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:

1. get the productpage pod name

   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".

2. ssh into the envoy container

   kubectl exec -it productpage-v1-4184313719-5mxjc -c proxy /bin/bash 
   

3. make sure the key/cert is in /etc/certs/ directory

   ls /etc/certs/ 
   

   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.

4. send requests to another service, for example, details.

   curl https://details:9080 -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.