solo.io Open Source Demos, 10 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: What if my Istiod pod can't communicate with k8s API server?

Description

In this demo, Lin will repeat the same test scenario as described in the "Could network cache-based identity be mistaken" video on Istio. Will Istio be able to enforce the security policies?

For more details, check out the blog: https://thenewstack.io/my-istiod-pod-cant-communicate-with-the-kubernetes-api-server

A

Hey guys, len, here a couple of days ago, I published a video on how network cash-based identity could potentially be mistaken. In that example, I showed when cillian pot couldn't communicate with the kubernetes api server today we're going to go through the same scenario with the istio control plan. Are you ready for this? Let's get started.

A

This is my kubernetes kind cluster. I have three worker vm. My application have sleeve version one and version two and hello world virgin well and virgin to use where sleep is the client and hello world. It's the server.

A

I also have psyllium installed. As my cli, I have istio control plane deployed with the minimum profile. I've have enabled cyca injection in the default namespace, where my client and server application runs, which is why you see two slash two with the sidecast.

A

I have celia network policy deployed while version one only allows sleep version, one to talk to hollow version. One and version two will only allow sleep version, two to talk to hello version, two.

A

I also have a couple of authorization policies, so the first policies are now nothing in the default namespace and the hollow version. One allows the sleep version, one to call hollow wood version, one.

A

And hollow version, hollow version 2 allows sleep version, 2 to call hollow version. 2., going back to the terminal, I'm going to check how sleep cost hello world, as you can see, uh version one to version. One is success. Version two to version two is success version one to version two was version. Two two version, one is connection fail. This is because silly network policy recognize they are not allowed. So this works perfectly in the perfect world.

A

Since we don't live in a perfect world. Now I'm going to trigger an error scenario, while the node, hello version, 1, runs, couldn't communicate to the api server.

A

Let's review our test script, we're going to capture the sleek version, one's ip address and then we're going to scale sleep version 1 to 0 and the sleep version 2 to 15, and then we're going to try to find that particular sleep version 2 pod that has the same ip as one of the sleep version, one part and then we're going to curve from that sleep version to pod to hollow version. One let's go ahead, run the test.

A

Bring up our k9s window and uh now we're seeing a bunch of sleeve version, 2, pop-up and sleep version. 1 is scaled down to 0, just as we ask the system to do now, we're rolling restart the sleep version, two part uh to hoping to get a match of the winner soon that meets the condition of reusing one of the sleeve version one's part, ip.

A

Checking onto one of the sleeve version, 2 pod, we can see the pod is taking up longer than usual to come up. This is because one of the issue d couldn't serve as the certificate authority to create uh to fulfill the certificate. Signing requests- oh it did come up so onward is ready now and looks like everything is up. Let's go back, oh, we have a winner too.

A

So, as you can see, we were able to find the sleep version too, and uh and this time we call hollow version one and we got our back axis d9. That's a error message from istio, so this really shows how istio authorization policy is enforced so that sleep version 2 couldn't talk to hollow version, 1.

A

all right. Let's recap what you have seen on the vm where hello version one part runs. We introduced an error scenario. Well, it could not talk to the kubernetes api server. There's one ceiling pod running on the vm there's. Also one hdld pod running on that vm psyllium network policy layer 4 could not be enforced because the identity of our sleep version- 2 pod, was mistaken.

A

So it allowed the access, but because we have issue authorization policy in place, the issue authorization policy was enforced, so at the end sleep version 2 could not talk to hollow version 1.. This really shows how important it is to have a defense in-depth strategy in your organization.

A

If you enjoyed this video, please give me a thumbs up and uh subscribe to our channel, so you don't miss any of our future educations on istio envoy, psyllium ebpf. Thank you so much for watching.