solo.io Istio 1.6, 13 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

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

In this part, we see how to rotate intermediates with the same root and no disruption

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

This is the third video in a series of videos of understanding, this Tio's root, CA and certificate authority, signing capabilities and making changes to it, rotating the certificates and doing so in a way that minimizes or eliminates downtime.

A

So my name is Christian posta I work for solo dot, IO I've been contributing working on SCO for approximately a little over three years, and it's all that we help our customers with these types of problems.

A

So in the previous videos, which I encourage you to go back and look at which set the stage for what our root CA structure looks like like you here, you can see from you can see that we have intermediate certificates signed by different routes or, in this case, route a which will focus on and in the immediately previous video we swapped out is SEOs self sign, Jen and stop generated root.

A

Ca for the intermediate CA, that's been signed by route a and in this demo, we're going to take them look at is rotating that intermediate CA.

A

The first thing we want to do is take a look at our existing routes, see a signed by route, a which is Eve. It looks like it ends in EB o. If we make a call up, actually that's the other video they have a demo. What we're going to do is update our intermediate with a with intermediate two so well.

A

First of all, we're going to delete the CA secrets, which is what sto uses to bootstrap from, as mentioned in the previous video and now what we're going to do is recreate that CA certs with an intermediate CA that has been signed by the route a CA, but this is gonna, be a different intermediate.

A

Then the one that's already installed in in sto right now: different intermediate same route. So now, let's start is Tod. It's actually coming to go to keen eyes.

A

Okay, this is you know, sis, and we should see us your diri, starting that should pick up. Our new intermediate CA over here put check proxy status between the difference services. We should see that it's this coming up or that to configure, has actually been synced and then what we're gonna do is restart the HTV pin workload and you notice in the previous demos, but when we did this, when we changed the CA that the connections would break between the different workloads now we don't want that to happen.

A

Alright, so let's, let's try it again between sleep and HTTP. Pin, oh, it works. It works this time and the reason for that is because we changed the intermediate to a different CA and now new workloads are being signed with that CA, but it's still anchored in the same route route a and so we can. We can validate that or show that so in HT pin, which is a new workload I guess we started it. It's shell into it. Come over here. Do the curl.

A

Take asserts of certs come back here. The route route here is a start and.

A

Should be done if we do inspect.

A

We wanted well.

A

Inspect should see 65. This is the serial number for the route 65 ec v ec, so these are definitely anchored in the same route, which is why we didn't see the traffic disruption now in the next video. What we're going to look at is introducing the a new route and in video number 2 we saw that that would break our connections. We're gonna do that in such a way that it doesn't break the connections in the next video, so go, go! Watch that and in stay tuned to this series.