 Good morning. This is the scene of working group on Monday, February 28th, and we'll get started at five past the hour. So allowing about three minutes for other folks to join. Thanks for the scene. Can you or someone else please share the document in the chat. I'm trying to get my computer to connect but having a little trouble. All right, let's see. So we can get started. I don't know if today is a holiday for some folks know that. Well, we got a few more coming in. Hey Tom, hi Ben. Hi everyone. So you can add your name and any topic you'd like to discuss to the meeting notes for sure. That's it in the zoom chat. Right. I'll come back to the announcements once you've dropped them in listening. Okay, let's see. They let savings time is starting in March. US on the 13th and Europe on the 27th. The meeting time will remain 1600 UTC. We've heard that that should be good for some people may not be as good for others. Half the year. All right, cute kind of you. Let's see. Cloud native telco day CFPs are closed at this point for that. And we did get quite a few sessions submitted. Those are in review. Sponsorships are still open for cloud native telco day. Yeah. Yeah. So the tag network sand CF. Technical advisor group. Network. They're looking for speaker around air gap deployment. They have a something going on. That's on their public slack channel. Well, I was planning on. Giving an update on. Seen a certification. Covering some things like categories and tests that we're looking at. For the certification. Kind of feel like. We should maybe wait until there's a larger group. I mean, we can do it recorded. Do we have any other topics that someone wants to discuss and. Taylor, I noticed that someone opened the issue regarding. Multiple interfaces. So I don't know if you want to. Talk about that or maybe we can wait also for. A great audience. You need a number high. Yeah. Sure. Number or blank. Very good. Is it an issue or pull request? Okay. So Daniel's not on the call today. I don't know his schedule. But it's going to be easier once the daylight savings time, but I anticipate it probably will. Be for him. I believe he's equivalent to Pacific time. In Canada. Anyways, yeah, this one's a good one. And I see that you posted some stuff on it. It seems like this one might be able to be talked about. In a more generic fashion. It's fine that it says multi interface from now, but I know that. With your experience with network service mesh. You know that we could talk about this in a different way. The requirements that Daniel's listing. I think are still valid, even if you don't use multiple interfaces, the multiple interface is an implementation. It's not a problem. A potential solution for a problem. So traffic segmentation isolation. Performance. You know, that's maybe arguably a stronger one, but still there's potential ways of getting around. Actual interfaces. Hardware dependency. All right. I don't want this how we did it in peanut peanuts. Okay. Yeah, well, these are, I think questions is this for. Right. So this is good. Let's see what else we have. Yeah, I just, just mentioned the discussion that we have before. Similar topic. Yeah. Yeah, this would definitely be one to pull. Out of the content from for the discussion. So one of the things, and you probably have recall this have run into it. The reason for. Post deployment interfaces and I'm going to drop interfaces and I'm going to say connections. The reason why you may want to. Add a new connection to an existing pod. And it will, I'll give one example. One example would be. If you have a set of pods that are running providing a service. Together, they work together in concert to provide some larger service. And then you have one of those pods. Die for whatever reason. And it could come up somewhere else, or you may say, we need to. Skeleton that would be as a related one. And you need to then connect from. One of those pods or maybe multiple pods to the, either newly deployed one or a. Maybe you're scaling up. So now you need connections to. New pods that were not there before. And then you need to make sure that the communication can continue. Without having to redeploy all the other ones for network connections. Now, I think a lot of that solved whenever the pods use. Services and labels and. And allow help. Let Kubernetes reconnect to wherever the new services. But I think the problem comes whenever the. The services go beyond what. The flat. Network provides and now you need the additional ones. So whenever it's outside of what would normally be there as. When we run into situations where you're either going to do it custom. Or you're going to use something like it could be. NSM or anything else that can dynamically. Insert new connections. Anyways, a lot of good things here, but what do we, what do we want to do on this right now? We can discuss it now. Continue. I don't know. Whatever, like, at least maybe we can provide some feedback offline or. When you start. You're burning like a PR or I don't know. I think this one. This topic needs some user stories. Use cases and user stories added. So that would be one area to have like a specific goal. We need to merge these. I think under the dark. Directory. I'm going to open up. Matrix. Doc here. Hey, Oliver. This one. Has. Some light use cases as well as user stories. Around state. But something like this. Would be very useful for. The problems that Daniel is outlining. You know that people have raised. Here's. Why are we doing it? You know, let's give some information on that. Any other. Comments or thoughts for this right now. I'm going to point right to the state document as an example. I think I'll tag. Daniel. Anything else. Other topics. Either I've opened the PR. And based on what I showed you. Last meeting. Okay. I incorporated Oliver's commands. I'm going to start with the PR for security best practices and configurations. I'm open for comments. Okay. We'll start to work on the Q bless. I'm going to. Thanks. Oh, you got it. Thank you. Can you please add some information into the description of the poll request? Sure. You want to give a quick overview. And then right now, and then folks can. Read more and, and give comments offline. So sure. So the general idea is that I want to create a set of, you know, best practices documents around. Kubernetes core components. Okay. And how to deploy them securely. And what are the do's and don'ts. And, you know, I'm planning this to be a, you know, a series of pages or even same page series of subjects. I've started with the API server. And how to deploy API server in a secure way. If I haven't, you know, touch something you think that it's important to open for any comments or know if you want yourself to have something I'm fine with it. I'm going to continue with the QB let's deployment. And by the end, I want to have, you know, set of best practices, okay, too, for, you know, for our on-prem deployments, you know, the kind of deployments we are working on. We usually not covered by others because all those who are using Kubernetes as a managed service. These are not things that they are usually dealing with. And therefore I think it's important to cover it. This looks really good, Ben. Thank you. So for those who haven't seen the best practice proposals, the idea here is to provide a whole lot of context and information for anyone that's trying to adopt a best practice. You may already think a best practice is you understand it, you agree with it, you're ready to adopt. If you may be talking with a colleague that's not quite sure. So ideally this will be content or helping that. And there may be someone, you know, that totally disagrees. So we want to be able to communicate all that. So we have context that may go beyond what we see in other user stories be specific. We can reference user stories. And we want to be able to... One thing that you want to look at, Ben, that we'll want to add into this is some of the... This looks like it's maybe the start of the idea here for the best practice. And as we get more feedback, we can iterate on it. What we'll end up wanting to do eventually is have... We want to cover all of these areas that our mark is required. So just go through right here. So is it implementable? Is there... Do we have a summary in the motivation? You're already providing a lot of that. So implementable, I think it looks like it doesn't get through all the details, but it looks like those are covered. Do we have a way to test it? I think we're already covered on this specific one, but we just want to add that in there. Scoring is probably something we need to adjust off of here because that was early, early on. The other ones, though, we have some things like non-goals are important to point out. If there's something that's out of scope, we don't want people to think we're covering everything, trying to cover everything. So this one... This is on the non-root point out some things there. And then just what is the main proposal? So that's a summary area. User stories, we normally just reference those. This one on the least privilege, we've been pointing to a lot of the supply chain attack user stories. So if there's existing user stories, feel free to reference those. We don't have to... And this isn't just for you, Ben. This is for anyone that's trying to propose that would like to help propose their best practice. If we already have a user story that works, then you can reference existing ones. If we need a new one, then we can work on those. Ideally, the user stories are general enough that they can work for many best practices. Of course, if there's one that's very specific, that's fine. You can inline it. Just put it right in there. And then another thing to point out is when we're doing something, what are the cons? What are the trade-offs? When you're choosing to implement a best practice, you're hoping for benefits, which we're going to list, but there's also potentially problems. And we want to make sure that those are communicated. Okay. And then you can see here, the other thing that we have is we try to put references. So this is beyond what we have in the working group, potentially. I mean, this one, we do have some discussions at the top. And if we had a best practice around network interfaces or connections or something, we would probably reference the issue that Victor mentioned earlier. We'd go to the discussion and stuff like that, but we also reference other documents like the tag securities, white paper. There's the pretty sure it's somewhere in here. Well, I'm not seeing it, but the security recommendation that ARMA references for Cubescape in a lot of the work that y'all do. So we want to put those in there so that people see why is this important? Why do I need to know? Why should I be recommending this? We tell them about it and then we back it up with even more information. So this, all of this in the working group is to help people have more confidence and give more strength to the idea of these best practices, which often, and I will say like the one that you're working on, maybe I went away from it. The one that you're working on, been a lot of people may agree, but we want to make sure and back it up with as much as possible so that if people have context from wherever they're coming, an understanding of why it's important. Okay, sure. Eventually what we'd like is put the proposal over in this directory by the way. So, and you can see the format. We have some templates and there's a few practices in there. We'll want more in there. Okay. Does anyone have any. Questions or comments for Ben right now. There's nothing else than I guess I'll go ahead and give an update on the CNF certification. I'm going to kind of move through some of this. Try to go a little quicker. Let's see who else is maybe joined anyone. So I think everyone on the call is at least familiar with. The notion of the certification that's going to be coming out. So, the certification is going to be launched by Kube kind of you officially. Another open source program. From LF slash CNCS. Like the Kubernetes. Certification. We want it to be as self service as possible. And it's focuses on cloud. The cloud nativeness or how well networking applications are following cloud native best practices. So specifically focus on applications that are in those workloads. The CNF test suite is what's going to be used for the certification. These are the categories. Where all of the tests reside. Cloud native principles overlap into multiple categories. These categories are primarily to help us as humans to just focus in on one area. We realize there's overlap. But these apply to the areas that we've been hearing about for years with problems and concerns. Life cycle onboarding of the CNF is networking applications. Reliability of the overall services and how do you approach that in a cloud native way? It's not that it's not being done. It's how do you do it in Kubernetes in the most effective way? It's not easier to be interoperable between multiple vendors when you're an integrated integrator, whether that's external or directly within a communication service provider that's running these applications to provide larger services. So that's what all of this is about. The test suite is leveraging a lot of upstream tools to do this. So if you want to contribute and you're familiar with any of these, it helps. We've got a lot of stuff around security and other things. And we've been getting contributions from all over. And I consider this a snapshot. But we have contributions. A lot of contributions I think that have gone in that way. And I think it's really important to be captured maybe and commit because someone was collaborating with someone else. And I appreciate and would like to encourage any type of contribution, even if it's working on a document. Or have, you know, having calls with folks to go over ideas. And then it may end up with one person finally doing the same thing. And then it may end up with one person. And then it may end up with one person. And then it may end up with one person. I think everyone's aware of these, but we're here on the working group call, of course, but the contributor meeting. If you're interested in getting more involved on the. Technical part of the. Certification and the test suite. We have a call on Thursdays at 14, 15 UTC. So welcome to join that call. Talk about how you're using the test suite or how you want to contribute new tasks, updates, docs, whatever. And there are select channels for any of the initiatives that we're running, there's going to be a public select channel on the NCF. So there's one for the working group. If you're not already aware and for the test suite. You're already mentioned cloud native talk a day. That's it. So it's a quick overview. Does anyone have any questions? I wasn't muted. I hope no. Nope. Sorry. No problem. Thank you. Sometimes you're, you're muted and practicing. It'd be okay. There's stuff to do every day. Right. So. We have over 50. Application work, let's focus test in the test suite. We've narrowed it down to a. A smaller set. Of tests that'll be used in the first iteration of the certification. I'm sure there's going to be multiple iterations as. The test. The test. The test will be in all the different areas. We have an abundance. In security. The reliability and availability areas. And we're continuing to add them into all of the areas. If anyone has ideas. For tests. We would love to. We would love to. And that could. Strictly be like problem statements and we try to match it up. You could say this is a more specific area to test or. Here's some user stories or, or whatever, and we don't have anything covered. You can see. All of the tests that are in. We have the usage guide. In the scene of test suite. If I go down in the workload, you're going to see. All the different individual tests. There's. Category. So this is a compatibility category. Jump in security. You're going to see those tests there. Information about this. So if, if there's a category. Or. Specific area where you'd like to see some more tests and you have thoughts around that, then. Please communicate them. Now or later. We also have a document. That's maybe related to the work that's been happening in the working group around. I'll say. We have a lot of content that helps users understand. So the documentation, which is slower to build out because of. You know, we're doing a lot of effort to make sure we cover everything in the working group. We'll eventually provide a lot of context and, and understanding. The, this document rationale is similar. But a smaller subset around why we're doing a specific test. What is it doing and why are we doing it? It's a short snippet that we're trying to add for every single test that's used. And then I think. What we'll probably end up with, like if I probably non root, not be a good one. Well, we don't have much documentation there yet. But this could end up linking to the. Best practices and in the working group. The documentation there. And similar to the one been that you're working on. I think we have. You know, maybe you have a harder time on this. There we go. There's a few things. About APIs and stuff. So there could be. A test that we end up here and we'll point it to that new. The best practice documentation. Does anyone have any thoughts or ideas or anything right now? If you're interested in helping, let us know. Definitely could use help on the documentation side. And driving in specifically to the tests that are there right now. That'll be part of the certification. And then ideas for new tests. Thanks everyone. Thank you so much. Thank you. I'll go ahead and stop here and, and we can pick up again next week. If, if you want to join us on the contributor call again, that's 1415 UTC. Thank you. Thank you. Thank you. Thank you.