Okay, my name is Joe Thompson I'm, currently employed by a team, Oh Rob and I work together on all this container stuff been an IT since 1993 made a few stops at companies, you'd recognize and a whole bunch of the companies you wouldn't all. My contact info is down there, but don't worry about that because there's a QR code for this link to these slides at the end, so I'm here to talk about network policy resources and propose some best practices, actually I found out well I'll. Get to that in a second.

The goal is to allow users to easily implement secure Network policy for chart installed. Apps. There are some constraints on that goal. There's always a few constraints. We don't want to violate the principle of least surprise. We don't want to do something by default that breaks a lot of people's installed. Apps cuts them off. You know a default deny that overrides things that they've allowed, but we do want to give them security. The easy way make it easy for them to turn on the things that they do want to turn on and secure their cluster.

The way they want to secure it- and we also want these things to be composable with network policies from other apps, so the people that charts aren't stomping on each other.

So it turns out that if you go out and look there isn't really any documentation about this yet, but there is one guy I, don't know as Dan Osborne here, I don't know, but anyway, there's a guy named Dan Osborne, ods Dan born on github and he's actually been doing a lot of this stuff in the charts that he's been submitting and he's been submitting PRS for this, so the first three things are: there should be a master network policy, dot, enabled value, and if it's set to false, we don't install any network policy resources same thing.

We do for our back right now we want to have a policy manifest per app component. This is part of the composability thing and then I would like to see and Dan does this an optional flag, that's on by default, to choose whether or not to allow external traffic? So if you have it on, then external traffic is allowed into the port. If it's turned off it's set to false or it's not set, then only traffic from specially labeled pods is allowed to contact this pot or the set up.

So those three are already out there. The additional thing I'd like to see done is put in an optional, deny all policy so that if people are installing a bunch of apps purely through charts, we don't make them to have them set up a secure cluster. We don't make them go in and submit the default deny policy manually.

They can just turn it on for any one of their charts and then it'll get installed automatically for them, but we don't want to do that by default, because if we do that by default, then we run the risk, like I said, of cutting people off from their own apps and, and that would be ugly so propose next steps. We should document what Danna Oz dan Bourne Dan house warns already done as best practices. We should look through the stable chart network policy implementations because there are other people contributing to this.

Nobody is frequently as him, but there are other people and see if there's anything else. Besides what I've covered here or what Dan's done to add- or maybe people are doing things we don't want them to do and then we should say no. No, we shouldn't do that. We should do this differently and then set up some kind of further ongoing discussion. The couple things that occurred to me are we probably need to talk about.

Egress filtering network policy could change in kubernetes in the future and we would have to make sure that whatever changes happen, they're reflected in our best practices, they're, probably any number of things that I haven't thought of that. Maybe some of you have thought of or have worked with, or battled with that and I wanted to say thanks to a team of for sending me here. Thanks to my team, lead Sam Brown at Oh team. Oh, he was the guy that originally suggested hey. You should there's this thing called helm.

You should write a helmet art and Here I. Am you know eight months later and thank you for listening and there's a link to the slides and there's a QR code that, if you scan it, will take you to that same link. So, thank you very much.

You.

You.