Cloud Native Computing Foundation ServiceMeshCon NA 2022, 3 Nov 2022

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Hands-on Workshop: A Guided Tour of... Christian Posta & Ram Vennam, Christine Kim & Nim Jayawardena

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Hands-on Workshop: A Guided Tour of Istio Ambient Mesh Workshop - Christian Posta & Ram Vennam, Solo.io; Christine Kim & Nim Jayawardena, Google

You will be given a quick fly-over of what challenges service mesh solves, existing sidecar architecture and the new Istio sidecarless approach, why you should pay attention to it and when you should use it to help reduce operation complexity and overhead with sidecars. We will dive into how Istio ambient mesh works, how to get started with your existing Kubernetes or VM workloads without any change, and migrate existing sidecar workloads to ambient mesh through interactive hands-on labs.

A

um Well, thank you for attending this Workshop we're going to be talking about istio ambient mesh before we get started, um I'd like to introduce the folks who will be running the um the workshop for all of you, so I'm I'm, Christian Posta, the global field, CTO at solo.io and I have with me.

B

Hi I'm Nim I'm a diverald engineer at Google Cloud.

A

Awesome so we'll uh this is a Hands-On workshop and as we get into the labs, if you have questions or things aren't working, then you know put your hand up, and one of us will come and try to sort it out for you.

A

How many of you in this room were at um earlier sessions today, maybe Lynn's session, specifically about ambient mesh most most people? Okay, um that's that's good! We'll do a quick overview of um of ambient mesh.

A

um It sounds like some of you saw the uh I think it was the the life of the packet through uh istio ambient mesh earlier, um and so that that went into a lot more detail. But what we want to focus on here is setting the context getting some understanding uh revisiting. Maybe the motivation for building ambient Ambient mesh and then actually getting Hands-On and uh and deploying it and working through the configuration and the experience of using the istio ambient mesh.

A

So the the first thing that I do want to point on how it's related to ambient mesh is that istio's been around for quite a while now and when you take something that is, you know, ends up being really critical in your environment in your platforms, something related to networking something. That's on the data path. You know it takes a while to get that infrastructure to be mature and stable, and uh you know able to run in in these environments and so istio's been around for a long time.

A

It's gone through its set of growing pains and the maturing process, and you know now we see you know, certainly in the SEO community, at solo working with our customers, we see istio, it's probably the most deployed service mesh, certainly at Enterprise scale and extremely complex scenarios and istio was just recently I think September 28th added to the the cncf officially. So it's part of the cncf landscape or cncf projects, and earlier in September, we we being the istio community, but it was.

A

It was a joint effort before that, to kind of prove out the concept through various pocs and building apis and understanding the various components and trade-offs that we might need to make uh it was.

A

It was a joint collaboration between uh our engineering team at solo and and Google, and this came about because we had been researching and digging into how we would kind of solve some of the the problems around service mesh adoption that um we felt like the sidecar model was kind of inhibiting that and uh and and we started working on that um and sharing some of the things that we were doing publicly and uh and ended up working with with Google on trying to prove this out and then announced it to the open source project in September.

A

The motivations for building out istio ambient mesh are primarily around operations and onboarding and incremental adoption of a mesh. So I know. We, like I, said if you've seen the overview that we've done earlier today. You'll see that things like sidecars are not first class Concepts in kubernetes, for example, controlling the life cycle of the containers of the sidecar itself and how it's related to the workload container.

A

You know, there's a there's, an inherent race condition there things like job resources, so you run a job resource with a sidecar and the job completes and the side car keeps running.

A

So there's there's these use cases that make the sidecar not as transparent as we like, and even more burdensome in upgrade scenarios when we need to either upgrade because there are new versions, new features we want to take advantage of, or there are cves that have been discovered that necessitate upgrading and patching the the service mesh and so for for operational reasons and there's a lot more.

A

Actually, Lynn sun and I wrote a uh a quick, little 40 page guide, a book introducing istio ambient mesh that we have physical copies that we'll be signing at the end of this Workshop I think outside of the solo Booth. But you can also go online and get an ebook about that. That'll go into more detail and more of that motivation, certainly around the operational side. Now there are some side benefits. I feel like there's side benefits like I said, the operational aspects are the or the motivation and the number one reason now.

A

Some of these side benefits include the um the cost reduction. I think we did a talk on um on on some of the cost savings, and we did a Blog on this as well uh so and as well as the some of the security posture. We did a Blog on istio.io about uh um about istio, Ambience security, posture and um and in in some areas how that can be approved but improved by not uh using sidecars.

A

So what is uh istio ambient mesh? It is a sidecarless implementation of the istio data plane that, um like I said, focuses more on deploying the mesh and operating the mesh transparently from the applications, not tying the data plane to or not tying the application to a particular infrastructure, component's life cycle. So you can make these upgrades and patches independent of uh of the applications, and then there are these.

A

These benefits to reducing the the number of proxies that are running the provisioning of resources in advance um and uh and getting some of the uh when you run at scale being able to optimize the uh the amount of compute and uh and resource that you need to run the service mesh.

A

So the way that it works is instead of running a sidecar proxy, a full-blown layer, 7 sidecar proxy next to each application. What we've uh each application instance, what we've done in ISO ambient is that we've split up the responsibilities of layer, seven- and this includes things like request, retries and header base- match based load, balancing and traffic splitting those those fault injection those types of capabilities from the the capabilities that are needed to secure the the traffic in in the service mesh.

A

um So we've we've created a secure overlay layer that focuses on the security properties of the mesh, so mutual TLS.

A

um You know authorization policy, some limited authorization policies and that forms the foundation of the zero trust aspects of the mesh that can, then you can layer on the layer, 7 capabilities as needed, so so you'll be able to opt into into that. We do that with, uh like I, said two different layers of the data plane. The layer 7 layer is implemented by Envoy proxy and you'll, see that in our uh in our Workshop today and layer four is is implemented.

A

It technically is Envoy today, but that is going to be optimized to be uh to be something else going forward. It doesn't need to be envoid.

A

um The istio control plane is still so istio D and what you see if you're familiar with the sidecar approach, the the istio control plane, is still there, and that is what serves the configuration to the um the the secure overlay layer that we'll see and to the layer 7 proxies, which we call Waypoint proxies um just like it does. Today it connects up to the side cars and gives it configuration, updates and takes care of routing and and the security properties.

A

uh You see the same things acod is doing the same thing with the with with these layer, 4 and layer, 7 proxies as well.

A

Now. This is uh this is one aspect of what we at solo have been working on.

A

That is the the glue platform that allows you to abstract away a lot of the details of operating and running a mesh and now not just at the top layers of your workflow layers, but now down at the uh the workload layers as well, where you don't the the developers when you deploy your applications, you don't see any uh any of these Sidecar proxies so now going a level lower into the details and setting up the the workshop that you'll be walking through.

A

Is uh that secure overlay layer that I mentioned that operates at layer three layer? Four that is implemented with the data plane components called the Z tunnel and I mentioned when we released istio Ambien Z tunnel was or is based on Envoy, but only using the layer. 4 capabilities in the mtls capabilities of envoy, mostly for expediency, is why that that landed. The way it did on an initial release, but that's being optimized right now.

A

I think last week in in the community, we're discussing a rust, based implementation um and uh and and further optimizing, the uh the way we configured that component and its actual runtime characteristics, and so we'll see in the workshops that we can use the secure overlay layer that uses these z-tunnel agents to implement the zero trusts capabilities of the mesh without introducing layer, 7 capabilities and then layer in those more advanced capabilities.

A

On top of the the secure tunnel, secure overlay mechanisms when we do that, we'll be introducing a layer 7 proxy that we call the Waypoint proxy. The Waypoint proxy is a policy enforcement point for these for individual workloads. In the previous talks, we pointed out that the Waypoint proxy is deployed per service account, so that's very similar to the model that we see today with the sidecars, where each service account gets its own identity in the sidecar model. It's the same thing that happens in in the istio ambient data plane as well.

A

When traffic goes from an application to another application, it will First Traverse the Z tunnel, and you know that's where the the security properties will be implemented and then, if it needs to go to a layer, seven Waypoint proxy. That communication will be encrypted with mutual TLS and then the Waypoint proxy will then apply whatever layer, 7 functionality or behavior. That needs to take place and then send the traffic off to the the destination, and that will happen over Mutual TLS as well.

A

The the communication protocol, the overlay that we use between the Z tunnels themselves or between the Z tunnel and the Waypoint proxies, is a um is a mechanism that uh is built on HTTP and is built to support uh various intricacies of protocols and uh and uses Mutual TLS to uh to authenticate the the traffic on both sides.

A

So I purposely went a little quick. This is not supposed to be a deep dive on uh on istio ambient, because I want you to get Hands-On like I, said see. The previous sessions from earlier today check out the istio ambient to explain book, uh but now, let's, uh let's get Hands-On and actually run the workshop.

A

So if you go to this, this URL that you see on here that should take you to the workshop environment and I'll have Ron walk you through those parts.

C

All right, uh we'll use this tool called instruct. You know think of it as just a web browser educational environment. Where, in that, in that in your browser, you should be able to access the full terminal, as well as the instructions and we'll spin up kubernetes clusters in that environment and then run through the process of installing istio ambient and deploy some applications and kind of play around with it. So if you go to this URL, can everyone hear me? Okay?

C

Okay, if you go to this URL you'll get taken to an instruct page where I'll say you know, add this particular Workshop to my study, room and then you'll go to the study room and you should be able to kick off the workshop.

C

So I will switch my windows and share my workshop environment once you add it to your study, room and launch the workshop. You'll get a screen. That kind of looks like this and then, if you hit start you'll, see a terminal on your left.

C

Think of this terminal right now as just connected to a virtual machine where there's nothing on there. Yet you know, except some CLI tools like Cube cuddle, that we'll leverage today is everyone on the screen. Any troubles it might take about I, don't know like 30 seconds to a minute for for the loading to complete, but can I get a thumbs up if someone's like done and they're they're, seeing the screen?

C

C

Okay couple all right: I'll I'll pause like another 20 seconds or so.

C

Is it working yeah I I saw a few thumbs up.

C

Okay, great so, like I, said the stuff on the left. Is your terminal and things on the right or your um of the instructions that you're going to follow. So the format of this lab today, I will do this step and I'll kind of annotate it and give any information about what that step is doing and then I'll be like I'll pause for like a couple seconds and then for you to do this to the same step with me.

C

First step is just to export an environment variable for simplicity's sake, for so so that we can reuse this environment variable later on in the lab, and then we will deploy um a cluster, a local client cluster. That's going to run inside this virtual machine. So this process takes about a couple minutes, but essentially we're just spinning up a kind cluster called which we're going to call cluster one.

C

So that'll be the name of the context and then, if you want to see exactly what this is doing, what so, while while this is running, because this takes a couple minutes, you can click on the files tab and then, if you open up the directory structure on the left, you'll see these these three folders this. The the contents of this folders are going to be the files that we're going to use in the lab today.

C

So this first file that we're looking at right now is this deploy multi sh, and this is what is deploying this kind cluster.

C

The kind cluster is going to be a four node kubernetes cluster um and the fact that it's four nodes is going to be a point that we're going to come back to later, so think about how nodes relate to the Z tunnels. And then you'll see the the mapping between the two. With a little bit later in the lab.

C

Okay, so my my script is complete. The next step just verifies that the cluster is up and running. It's just checking to see if all the pods in the cube system namespaces are up and running. So if this second squip returns, that means that you're you're good to go to continue with the lab. So for me, it's still waiting that just means that the pods and the keep system namespace, are still kind of spinning up.

C

All right so I'm done, my kubernetes cluster is is up and running. So if I do Cube cuddle I'll, give nodes, you'll see my four node group cluster and then, if I do if I list the pods in the group system namespace for example, you'll see you know things like Coupe proxy and running.

C

Cool, so most of you should be about this step right now, so we have a clean, kubernetes cluster. The next thing we'll do is we'll deploy istio, um you know just like with it's with any standard istio. You don't have to download the the right binaries right.

C

um Ambient is still an experimental, so it's it's still in preview mode, so it's in an experimental Branch. So this wget command goes to that location and gets the the right binary.

C

So we're downloading the istiocado binary from that experimental branch, location and then extract it. And then you see we have the istiocado binary. This is the experimental one and then we will install istio using that binary, so istiocado install but notice here I'm setting the profile to ambient. So the way you install istio is the same way you install istio today, just like you have your default, minimal demo profile, there's just another profile for ambient and this profile.

C

If you go, look at like the Manifest directory and pull up amient.yaml you'll see that how it configures things like the deployment of zetanol sets up the cnis to Route traffic from your pod to Z tunnel Etc.

C

So let's give that a minute to finish.

C

Once we completed that installation command, if we check the pods in the istio system, namespace you'll now see obviously you'll see istio D and the istio Ingress Gateway. But now we also see four Z tunnels and the reason why we see four is because z-tunnel is deployed per node basis and we have four kubernetes nodes. So there's four Z tunnels.

C

So what we've done so far is just install istio with the ambient profile, but we don't have any applications yet. So let's do that next we will deploy the sample application and uh pay attention to this diagram. That's right above the deploy sample application command. Essentially we're just going to use a sleep, a client app, that's going to call the web API service. The web API calls a recommendation and a recommendation calls purchase history. So it's just a chain of upstreams.

C

And if you're interested in looking at you know what exactly you know, the deployment the service the service accounts looks like you can always click on the files tab like I did before and pull up that enamel.

C

So once you deployed that, if you look at Cube cuddle, get pods you'll see my five applications that are running in the default. Namespace. Of course, there's no sidecar for any of these because I didn't label my namespace for a steel injection or anything like that. It's just standard kubernetes containers deployments.

C

To make sure that they're working we're going to exec into the Sleep container and then from there we'll call going back up to this diagram from the Sleep container. We're going to execute to that and from there we're going to call Web API web API is going to call recommendation recommendation is going to call purchase history.

C

If you look at the output that from the curl command, which called Web API, you can see that you know this stuff from the top is from web API, but web API calls a recommendation and it embeds that response into its own response. So if you look in the Json one step and deeper you'll see this is a recommendation and then, if you go look at One, More Level into it, you'll see purchase history and then the the 200 200 200 means that all three of them succeeded well.

C

Next, we'll use the istio, Gateway and virtual service resources to expose the web API service through the istio Ingress Gateway. So again, you know take a look at those files if you're interested, if you're interested in the yaml but but yeah, it's just a standard, Gateway object that listens on a particular host and then it uses a virtual service to to route from that gateway to the web.

C

Api service we'll set this environment variable to the IP address of the istio Ingress Gateway service, and then, if I, do a curl and specify the right host I should be able to get the same command that I got going through sleep. So now we're just accessing directly to web API from the istio Ingress Gateway. There's no sleep involved, so we're still kind of setting the stage for everything we did install istio, but we're not using it. Yet we're still, you know all basic kubernetes stuff.

C

I'm pausing a couple seconds to make sure everyone's on the same step: okay in this next portion of the lab, what we'll do is use TCP, dump to sniff the network traffic, so we we've called Web API from sleep and from Ingress Gateway web API called other services so by doing TCP dump. If I look at you know if I sniff, some packets you'll see, for example, in my output, I see that somebody called the recommendation service on port 8080 and, furthermore, I can see all the headers and information about that particular request.

C

So this means that this connection was not encrypted and someone was able to use TCP dump to actually read that data.

C

So we're still kind of like laying down all the groundwork and then the next portion of the lab will start using ambient.

C

So if you're done with that click on check and can I get some like thumbs up that, you know we're at the stage awesome cool, so you all are able to keep up just fine, so I'll kind of increase. My speed a little bit.

C

Next thing, we'll do is we'll add those sample applications to ambient and the way to do that is to label that namespace. The default namespace with istio.io dataplane mode equals ambient so similar to the sidecar mode, where you're labeling it with injection equals, enabled or whatever the revision flag is. We just have a new label for ambient. The beauty of ambient is that you don't have to restart your applications.

C

um It is just turning it on and turning it off right like right now, I just turned on ambient mode and all the applications that are in this namespace are part of the mesh and to prove that we can look at the logs of the istioc and iPod, and you can see that it is configuring. The routing rules, the you know, the outbound and inbound routing rules from those applications. So from this from the cni log, you'll see sleep web API and whatever the other applications are that are running in that namespace.

C

So it's the cni, that's watching for new pods and existing pods, and then configuring it to the route traffic to Z tunnel and we already covered. You know Christian already covered what exactly Z tunnel is and how it works. Etc.

C

So next thing we'll do is we will generate a lot of traffic so that we can look at some metrics, so this next curl command will gener will go from sleep and call Web API a hundred times and then you'll just see the the Response Code information. So you can see they're all 200s so now after I send 100 requests to the web API service. If I take a look at the logs of one of the Z tunnels or or all the Z tunnels.

C

If I look at the Z tunnel, pod logs you'll see information in here about traffic that is going through the Z tunnels right. So, if you look at this IP address here, there's source and destination IP address and those IP addresses would map to the z-tunnel Pod IPS.

C

Just like before we'll run the TCP dump command again and then see if we're able to sniff any traffic, so I see some packets, but this time this is not readable. So this is showing me that whatever this data is from TCP dump output is encrypted.

C

C

C

The Next Step verifies that, basically, that this IP address that you see in the top of this TCP dump is actually coming from. Oh, it actually references the z-tunnel Pod IP addresses. So if you're interested in looking into that in more detail.

C

Okay, so what have we accomplished so far? So just by installing istio and labeling, the namespace we've achieved mtls from z-tunnel to Z tunnel, meaning that node to node communication between the pods is encrypted. I didn't have to restart any workloads. I didn't have to configure any additional policies. You just get this encryption, Straight Out of the Box, so encryption authentication is one thing right.

C

We talked about how zetunnel uses the applications certificates to initiate connections on behalf of the application, but now we can do things with that identity with that strong identity and one of the things that we can do with istio with strong identity is layer, authorization policies, so the very first authorization policies basically creates and allow nothing. Zero trust.

B

C

One's allowed to talk to anybody else, Foundation there so now that I have this, allow nothing authorization policies if I try to do the same kernel command again from the from the Ingress Gateway.

C

You can see that I get you know reset can reset reason, connection Upstream error.

C

So now we have to explicitly allow communication from one service to another service. So that's what the the next set of authorization policies will do. I mean really. The the takeaway point from from from this part of the lab is that the enforcement points for your authorization policies are now happening at the Z tunnel. We don't need a waypoint proxy for you to do layer, 4 authorization policies so for mtls and and TCP layer, 4 authorization policies.

C

You do not need a waypoint proxy so now that we've explicitly create authorization policies on who's allowed to talk to to who else, then, if I do another curl command, um if I redo the curl Commandments before you can see now I'm getting good responses back from my username.

C

I also have a deployment called, not sleep. That does not have authorization policies.

C

So if I, if you try to exec into not sleep and try to curl one of the web, API services or one of the services in the mesh, then you'll see that it's not able to to make that connection as you'd expect.

C

C

Able to reach this section.

C

Great for the next section I'll hand it over to Nim from Google thanks Ron.

B

How's everyone doing so far be good. Okay, that's awesome. I saw someone walk in kind of last minute, so I just want to put up this uh tiny URL back up on the slides for anyone that wants to start the workshop, um but I also do want to quickly recap what we just did and we have a few visuals here. So of course, we created a kind cluster with four nodes.

B

We then installed istio, as we normally do using a steel, CTL install except, of course, our profile that we used was called ambient and all it does a bunch of things, but like the the main thing that the main takeaway here is that it deploys a z tunnel for each node that takes care of all of istio's L4 functionality for you, and we also deployed a bunch of test test apps that we could play around with, and we also saw that the way to enable ambient mode or the Z tunnel on a specific namespaces by just labeling it with this label.

B

um So everything we've seen so far was just L4 stuff and what we've at least learned from our users at Google is istio.

B

A lot of users just need the L4 stuff and the majority of istio users at this point, can you know stop or if they want to continue adding on the L7 functionality they can do so and they still benefit from this ambient model, because adoption is a lot easier because most people adopt with L4 first.

B

So this next section is purely about L7 and we're going to start off by looking at it an L7 authorization policy.

B

More specifically, what we're going to do is so right now sleep can talk to web API right, that's what we did in the previous section, but we're going to be a bit more granular about how we allow communication from sleep to web API and we're going to say. Allow only get requests and we're going to do that by just deploying a authorization policy which you'll see down here um and for us to actually apply that authorization policy and see it work. The web API needs a waypoint proxy attached to its service account.

B

um So the way to do that, the way to deploy a waypoint proxy right now is to use the kubernetes gateways Gateway resource, and uh it's important to note that this is the the kubernetes resource and not the istio Gateway resource, and you can see that we're attaching it to the service account of the web API and were saying hey, let's use the Waypoint proxy from istio's ambient mesh.

B

um So let's go ahead and do that now. The very first command here is exactly that. We're going to apply our Gateway.

B

And next we're just going to check that the Waypoint proxy deployment has been deployed so we're just doing a coupe CTL get pods and we're looking for our Waypoint proxy and there it is- and the next thing of course is applying the authorization policy that says: hey we're only going to allow traffic um from the Ingress Gateway or the sleep service to our web API. That is in the form of a get request, all right, so we're just applying more granular rule here.

B

And then, let's test this out so now, if I were to just make a get request from the Sleep service to the web API, it should work all right um and that's your 200 response. But of course, if I try to now make a delete request, it shouldn't work.

B

Yep so somewhere in here, you should see access denied.

B

Yep, it's actually just hidden right. There.

B

Okay, so that's just a bit of a more granular authorization policies. We'll also uh make note that the Waypoint proxy, once it's deployed for the web API service account you've also now got access to L7 observability of that web API service.

B

So we're just going to confirm that here by just looking at an endpoint inside of our Waypoint proxy, that Prometheus would use for that. Observability.

B

And then you should see something that looks kind of like what I'm seeing here and then the next section here we're just doing a bit more playing around with L7 policies.

B

But um I've got a visualization here for that too.

B

um What we're doing now is we're saying: um let's, let's make a delay- uh let's add a delay of five seconds for any requests going into web API that contain the user Amy inside of the HTTP headers.

B

um So of course that is done in istio using a virtual service.

B

um So here we're just applying an istio virtual service and we're saying: let's apply this fixed delay of five seconds and it should only apply if we see the user Amy inside the HTTP header that reaches the web API. So let's apply this now.

B

Okay and now, if I try to access, or rather if I try to make a HTTP request with a user Amy inside of our header, I should see a five second delay and I was just pressing enter now. So one two three.

B

And there we go um so that's a bit more of uh istio's L7 functionality with the Waypoint proxy, um and this final section here is doing a bit more L7 stuff, and you can see that uh I guess I can show you the visualization as well um we're playing around with a bit of traffic splitting here um we're saying for the purchase history service, we're going to deploy two versions of it version one and version two and then we're going to say, put 90 of any traffic going in the purchase history service, um but ninety percent of that traffic to version one and ten percent to version two and of course, because uh the the policy is being applied on the purchase history service.

B

We now need to deploy a waypoint proxy for that purchase. History service account.

B

um So that's uh the very first thing that we should be doing so. Let's go ahead and let's look at that. So we're again using a Gateway apply to say: hey, look um apply this istio mesh Waypoint proxy to the service service, account called purchase history, so let's first actually deploy version two of our purchase, history and again kind of like what Ron mentioned.

B

If you go into this files tab, you can see the exact contents of that folder that we just Coupe CTL applied, and let me go back here and I'm going to apply the Gateway now to deploy the Waypoint proxy for purchase history and then I'm going to apply our istio virtual service to apply the traffic splitting the 90 percent 10 traffic splitting and you can see right there we're saying version. One should get 90.

B

So at this point, if I right so I guess, I've also got to define the uh two versions as subsets um using istio's destination rules.

B

So this is just saying splitting up the the two different pods that I've uh um deployed and uh contextualizing it for istio is version one and version two um and now at this point, if I make a whole bunch of requests, I think we're making 100 requests here to the web. Api the web API talks to the purchase history.

B

So we should see that later that 90 goes to version. One 10 goes to version two, so it's uh do that right now,.

B

Right, so you can see that about 10. Of those nine of those uh 100 requests were when to purchase history version two and the curl output just tells you, which version that's why you can just grab it um and uh see that it's version, two that uh we're reaching okay. So at this point, yep go ahead.

B

B

um Have you applied your destination rule.

B

B

Thanks Christine does anyone else, have any questions or any did anyone yep go ahead.

B

uh Sorry, what's that.

C

B

C

Was where are the certificates coming from back in the layer, 4 stuff.

B

I can take that question. You want to cover that.

C

Yeah it's coming from a Studio D, so the Z tunnels will make a call to stod. Ist is still your ca. Z tunnel is just acting on behalf of your of the application. That's that spun up and said: hey give me certificates for web API pod and then stod gives it the certificates and then Z tunnel uses that certificate to make a connection to the other z-tunnel.

C

The sdod is still your ca and you can still configure hdod to use a different CA. If you wanted to just like, like you, do today, like how istio D gets, this gets its certificate, whether it's self-signed or integrated, with the pki that stays the same yep is.

A

B

Anything else you want.

C

To add: okay, cool thanks.

B

Bro, do we have any more questions in the meantime yep, so I guess that's the section about uh L7 functionality.

B

Using the Waypoint proxy and once you're done this entire section, you can just click check there and then we're going to be navigated to the bonus section.

B

So the bonus section is really just answering one question that a lot of folks have, which is whether I can still use sidecars, and the answer is yes and yes, the ambient mesh and the sidecar pattern will still interoperate um and sidecars will remain a first-class citizen of istio.

B

So this section is just going going to just confirm that um so in this section we're actually deploying The Familiar HTTP bin service into the HTTP separate namespace.

B

So let's first create that namespace and then we are going to um inject a sidecar or enable a sidecar injection in that new native that we created and then we're going to deploy the HTTP bin service. So you can see it's got its own service account. It's also pulling in this image here.

B

Http bin- and let me just apply this here-.

B

Yep and so now, because we enabled uh sidecar injection if I do a coupe CTL get pods from that namespace, the HTTP bin namespace.

B

I should see that there is a sidecar attached to it um and now, if I uh curl from um from the Sleep service, which is using the ambient mesh Z tunnels to the HTTP bin service, I'll see that in my response, my response should say um somewhere here. It should say x, forwarded client, sir yep. There you go. So that's how you can confirm that the traffic between the HTTP bin service, which is using a sidecar for its L4 HDO stuff, is being encrypted as well.

B

um And that concludes our bonus section and that actually concludes the entire Workshop. So um I guess in during this time, we'll probably just field around and uh get questions or if folks are stuck anywhere, we can help out.

C

Yeah, like Nick, said we're going to be walking around kind of kind of. If you have any questions.

C

um I did want to share that. We do have a survey link. Second, let me see if I can find my I, don't know where my share button went there. It is okay, so there's two more URLs for you. There's a certification, exam I, think it's like 10 or 20 questions or so, and if you answer like above 80, then solo will send you, like the certification badge that you can add to LinkedIn.

C

um I, don't know, share it within your organization, share it with your manager. um There's also a survey link. If you like this workshop and and you want to see more of this type of content, um you know, please share any feedback that you have positive or negative and and just know that solo will run these type of workshops pretty often virtually. So, if you go to solo, I o and go to upcoming events.

C

You'll see that every week or so we have workshops around beginner intermediate and advanced istio content things around Envoy ambient graphql and a lot of the stuff that we work on. We we build a workshop and we do these free workshops, along with an instructor that comes with it and and annotates. The content like we did today um so with that said, yeah thanks. Everyone um again we'll be walking around answering any questions.