solo.io Istio Service Mesh, 13 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Istio 1.6 Deep Dive Certificate Rotation (Part 0)

Description

In this 4-part series, we look at how to rotate Istio CA certs without interruption.

About us https://solo.io
Manage multi-cluster Istio with Service Mesh Hub https://solo.io/products/service-mesh-hub/
Istio 1.6 https://istio.io/latest/news/releases/1.6.x/announcing-1.6/
Questions? https://slack.solo.io

A

Thanks for swingin by our YouTube channel, my name is Christian posta and I've been working on contributing to sto over the last three years and I now work for solo Deo and in these videos we're going to take a look at some of the details of s, T O's, 1.6, certificate, handling and rotation.

A

So the first thing that we want to do is set the context. So it's do out of the box. When you install it will automatically create a root, CA certificate and key and use that to sign workload, leaf certificates and by default it stores the root and a config map in each namespace.

A

So forget the config Maps. We can see this coz a root, cert take a look at it in the amo and we can see that the certificate is stored here. When we look at the workloads and we explored their certificates, we can see that their leaf certificates are signed by this root. So we can come over here. Let's go use k9s our favorite console for kubernetes see we have a couple of workloads running here: sleep pod, which can talk to the HTTP bin, pod and SEO, is currently deployed with mutual TLS.

A

So if we do cube CTL get here, patient I should see strict you'll, see less so. But if we go to the workloads- and this lets shell into one of these workloads- one of these to do proxy if we do a curl on the proxy itself- and it asserts end point so- this is pure envoy envoy- documentation- see the different paths you can hit for clearing the configuration that the proxy has.

A

We can see.

A

It see if we come back up here, our root CA, so you can see all the certificates in the chain and so forth, root CA to find here should match. With the let's see we get that all right. Let's do this path, I think it is.

A

A

Let's try that alright and let's, let's inspect this using our very handy step tool for managing certificates,.

A

A

Let me take a look at the certificate: take a look at its serial number and FAC six, something or other, and that's what we see here, FAC six. So this is the root certificates line up between what was automatically created by sto on bootstrap and the certificates that gets signed by the certificate authority or in SEO 1.6. Let's go here.

A

We do keep city a pod in these system is the certificate authority is running in is Tod and when the workloads come up, they request a certificate and then the is Tod signs this certificate and is signed with the the root CA.

A

Another interesting thing we can show you here is that the the the leaf certificates are created and they're available or they're valid for 24 hour period by default, and so this can be changed with environment variables, but by default, when we do this requests assign a certificate, it does it for 24 hours. So in the next video, what we're going to look at is what happens when you start rotating certificates, specifically the CA that sto uses the signed certificates.

A

What we're interested in is rotating in such a way that we don't introduce down time specifically to the workloads that are using these certificates to establish identity, a mutual TLS so stay tuned to the next video.