Plugging in existing CA Certificates

By default, Istio’s CA generates a self-signed root certificate and key, and uses them to sign the workload certificates. Istio’s CA can also sign workload certificates using an administrator-specified certificate and key, and with an administrator-specified root certificate. This task demonstrates how to plug such certificates and key into Istio’s CA.

Suppose we want to have Istio’s CA use an existing signing (CA) certificate and key ca-key.pem. Furthermore, the certificate ca-cert.pem is signed by the root certificate root-cert.pem. We would like to use root-cert.pem as the root certificate for Istio workloads.

In the following example, Istio CA’s signing (CA) certificate (ca-cert.pem) is different from the root certificate (root-cert.pem), so the workload cannot validate the workload certificates directly from the root certificate. The workload needs a cert-chain.pem file to specify the chain of trust, which should include the certificates of all the intermediate CAs between the workloads and the root CA. In our example, it contains Istio CA’s signing certificate, so cert-chain.pem is the same as ca-cert.pem. Note that if your ca-cert.pem is the same as root-cert.pem, the cert-chain.pem file should be empty.

These files are ready to use in the samples/certs/ directory.

The default Istio CA installation configures the location of certificates and keys based on the predefined secret and file names used in the command below (i.e., secret named cacerts, root certificate in a file named , Istio CA’s key in ca-key.pem, etc.). You must use these specific secret and file names, or reconfigure Istio’s CA when you deploy Istio.

The following steps plug in the certificates and key into a Kubernetes secret, which will be read by Istio’s CA:

Create a secret cacerts including all the input files ca-cert.pem, ca-key.pem, root-cert.pem and cert-chain.pem:
Deploy Istio using the demo profile.

Istio’s CA will read certificates and key from the secret-mount files.
```
$ istioctl manifest apply --set profile=demo
```

$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo

Deploy a policy for workloads in the foo namespace to only accept mutual TLS traffic.

In this section, we verify that workload certificates are signed by the certificates that we plugged into the CA. This requires you have installed on your machine.

Sleep 20 seconds for the mTLS policy to take effect before retrieving the certificate chain of httpbin. As the CA certificate used in this example is self-signed, the verify error:num=19:self signed certificate in certificate chain error returned by the openssl command is expected.
```
$ sleep 20; kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- openssl s_client -showcerts -connect httpbin.foo:8000 > httpbin-proxy-cert.txt
```

Parse the certificates on the certificate chain.

$ sed -n '/-----BEGIN CERTIFICATE-----/{:start /-----END CERTIFICATE-----/!{N;b start};/.*/p}' httpbin-proxy-cert.txt > certs.pem
$ awk 'BEGIN {counter=0;} /BEGIN CERT/{counter++} { print > "proxy-cert-" counter ".pem"}' < certs.pem

Verify the root certificate is the same as the one specified by the administrator:

Verify the certificate chain from the root certificate to the workload certificate:

$ openssl verify -CAfile <(cat samples/certs/ca-cert.pem samples/certs/root-cert.pem) ./proxy-cert-1.pem
./proxy-cert-1.pem: OK

To remove the secret cacerts, and the foo and istio-system namespaces:
To remove the Istio components: follow the uninstall instructions to remove.

Provision and manage DNS certificates in Istio.

A vision statement and roadmap for Istio in 2020.

Remove cross-pod unix domain sockets

A more secure way to manage secrets.

Introduction, motivation and design principles for the Istio v1beta1 Authorization Policy.

Secure Webhook Management

A more secure way to manage Istio webhooks.

Deploy environments that require isolation into separate meshes and enable inter-mesh communication by mesh federation.