 Hi folks. Greetings. Happy new year. We'll wait until five after to get started. You can start adding your names and any agenda items to the meeting notes which I've posted a link for in the zoom chat. I didn't see if anyone else joined. We'll get started at five after. So just a couple of minutes. Happy new year and you can add your. Name and any agenda items to the meeting notes. Hopefully folks can hear me. Yeah. All right. This call is being recording if recorded. If you didn't hear the notice when it started and we. Publish these to the. C and C F YouTube. Channel and the CNF working group. Q. If you want to go look at any of the old ones you can, and this will be published there. I welcome. Let's see. We are at five after. Why don't we get started? Meeting notes are posted into the zoom chat. And then we'll get started. For folks that are new to this call. This is the cloud native network function. Working group. It's one of several. Focus initiatives within the CNCF. And this call has been recorded and will be posted on YouTube. At some point after it's done. I'm going to bring up. The screen share. We'll see my call there. I'm in my screen share on the call. Add your. Name would be appreciated here. This meeting. Group meets Mondays. 1600 UTC. We shift. With the time changes, but it's. I guess it's. I guess it doesn't shift. I'm sorry. It says 1600. But we should be this way for a few more months. And. For those that don't know. The main purpose in this group is. Around. Documenting and publicizing on. Cloud native best practices for talk on applications running on. Environments. Kubernetes based environments. That's what we're doing our main focus right now. We have a lot of documentation that we've been working on around. Use cases, user stories. We're going to be publishing best practices. Also publishing or writing up things around. Problem areas. So if you're trying to. Utilize the Kubernetes environment and. Having. Problem. Adopting any type of technology or. Methodologies or whatever, then we want to note those and try to see. What are the problems and what tips and. Things that we can have to work with those. Usually that's. General generic. Vanilla Kubernetes, but if it's specific environments hosted environments, then we want to know those too. Some environments. Or I should say one of the best practices that we had. It's done a lot of talk about was. In the area of security and specifically least privilege. So we had one. Practice that we wrote up called non route. So not running your. Processes and containers as the root user. There's a lot of different things you can do regarding security. If. If someone say discover an exploit or there is a bug. Maybe just something goes wrong with your application. So not having a route. And will limits the damage within the container. So. There's a lot of other places that. You can have problems, but this is just one area. So it's recommended to not run route. And we've written up some stuff around that. So that would be one of the areas. I'm going to jump right in. If someone has any agenda items, actually, I'll just ask, does anyone have anything that's not written? We have. I'll go over the upcoming events as well. But anything else to add. I don't know. Taylor, you remember that I sent you okay. The. You know, the very, very early draft of my next best practices. Around. If we have a few minutes, okay. Somewhere along just a small feedback would be helpful for me. If it's if this is the. The best way to go and start to creating from this. Items. In the repository. Yeah, for sure. Would you like to. Drop a link in here and we just get some feedback right now on the call. I mean, even if it's minor. Sure. Kind of give an overview of it. And then if it's. Do you have a comment access available on the. Yeah, I will open it. It just opened comment access. Since if we're going to drop a link in here, don't want to random people on the internet modifying it. But if they can do comments, then you can approve or. Or reject. Sure. All right. So just add that. Below the meeting host review open floor quest. Okay. Okay. Does anyone else have anything they'd like to add. Or have any questions just about. The CNF working group. Okay. So. MWC Barcelona. Is anyone going to be there? Do you know of any specific interesting events? I don't know of anything that's made it from people that I know that submitted. For MWC. How about. One summit. Okay. So. Cube con EU. See if these are closed. So if you didn't get a man that's too late for that, but if you have something interesting. Feel free to add. Add an entry here just so that we know about it. And everyone in the group can see it. I can, I can share. I can share that I'm on the program committee for the networking track and there are lots of interesting things going on there. So. And it's a pity that only only a handful of them will make it to the conference, but yeah. On one summit or cube con. Keep calm. Sorry. All right. Cool. And I'm well. I guess when, when they make it through it can add them. I guess would be the next thing. Yeah. People that don't make it through Nikolai if it's the same super interesting, maybe you could tell them to come. Tell them to come, tell them to come talk to the working group after they've been rejected. Okay. Yeah. Yeah. All right. So there is a, there's going to be a co-located event that since CF is putting on cloud native telco day. So for anyone that doesn't make it. Through the CFPs, maybe for cube con itself, maybe try to get them over, but. Probably ask them anyways. So if, if you're. Available. At those times and you'd like to. Be presented the cloud co-located event, cloud native telco day, then. Let me know. I don't think we have details yet for submitting on that, but we'll get that soon added as soon as we have it. I should hear more this week about that. Okay. I'm safe. He's not open for the N.A. I'm going to go ahead and pull up the pull request. Oh, we have several here. What do we have? 25 days ago. So is there anything else on. Jeffery's. Air gap. What happened? Unicorn. There's another unicorn. It loaded this time. That hasn't been resolved. This hasn't been resolved. Probably need. Someone else to step in. That would be interested in air gap to help. Jeffrey. Is no longer at charter and. Getting things going at his new. Job and we'll see how much availability has gone forward. I don't really see anything else, but this is still something. Folks could look at and give some feedback on. Especially if you do. Like we have some of these that got there were able to be resolved. So if there's anything where you want to change. And you click on the plus. And then suggest and edit is the most helpful way to move it through. But you can take a look at this one. These user stories. So these user stories will be helpful in many areas. To help us. Supplemental documentation. I'm going to move on. What do we have? Best practice compliance. Oh yeah. All right. This one. Folks can look at it. It's not ready yet. Got to get back. Continue on it. This is one of those that are. When you. When you're looking at a set of best practices, or you're, you're working on the test. Maybe you're working with the CNF test suite and trying to. Pass as much as possible, whatever you're, you're trying to improve your software and going along, but you're found an area where it just doesn't work. This is an area where you don't feel like you can follow. A recommended best practice for whatever reason. Very valid reason. Maybe it's in conflict. You're following like HIPAA compliance or something. And you can't do it. You can't follow something because it would conflict. Well, this. Is about, and we need to update the title there, but this one is about. Documenting. Any type of exceptions. You know, and communicating where you can. Where you're not able to be compliant. And the reasons and stuff and making that easily accessible for. The people that care about this, you know, so this could be the ops team at a. Service provider or wherever else. Documenting the reasons around that. And then. Some suggestions there. If anyone has comments or wants to add to this. That would be good. But this one is definitely a draft right now. Any comments or questions? Otherwise I'll move on. Oliver, are you here? You are here. Yep. Here you go. This is all you. I'm going to let you. You want me to screen share or you want to take over. Yeah, no, it's fine. You can just, you can. Yeah, just keep it up there. I mean. Yeah, I think this is what we. Open this poll request just before the holidays. I think we, we've done this in the past. We have already today, we have a use case, which really looks at stateful CNF. I think we're trying to go a bit lower level sort of to tackle some of the user, not, you know, not some only use case, but some of the user stories. I opened this up with Taylor here on, you know, just before the holidays. And these are mainly derived out of, you know, what I would say 4G and 5G, you know, online charging system perspective or a convergent charging system company I work for is, is offering a product in this area. So these are some of the challenges that we face in terms of, you know, cloud native for places where we are dealing with state, need to manage state as part of a 3GPP compliant 5G core. So that's where these use cases are, are deriving from or use user stories are coming from. I have tried to genericize them a little bit more. And the reason for that was just simply to try to create some appeal for others who might recognize. You know, some areas where they are also facing some of the similar challenges. And I see that we've had some comments on here that, you know, maybe these are more IT related. And, you know, I don't totally disagree, but they are in fact network related. So we are talking about CNFs, talking about network functions. And I certainly see the CHF as defined at least in 3GPP. That is a network function. And therefore, you know, there are some, there's some interesting challenges that I think we need to work around with. So by all means, if you have thoughts, comments, please do have a look. This would be interesting to see if we can get this to push it a little bit further along. Do you want to give a, just a quick run through of the stories and use cases? Yeah, let's, why don't you come down then to the first one? Okay. So, yeah, I mean, basically the way I would look, sorry, go up just a little bit, I'll apologize right there. Yeah. So I will try to run through it fairly quickly. If you look at the, you know, the way that it works is we start off kind of at the highest level and sort of what I'm doing by doing the way I've done this is to say, look at this use case, talk about a CSP, a service provider, you know, just recognizing that there's, you know, almost at the highest level, there's a need to maintain, you know, persistent data, things like subscriber information, account balances, quota balances, you know, different things that are used along the life, the journey of a subscriber. And also recognizing that that data may be fairly static in nature or it may be very dynamic and changing, you know, all the time. This is just kind of a starting point to this. And then I go through and give just a few examples with the user stories. So, you know, from a user perspective, I have a, I have an address on file. I may need to change that, you know, I expect my provider to be able to allow me to do that kind of thing. So it's just making the case that the CSP needs to be able to handle that. At the same time, then if you move into sort of the point number two here, it starts to move into cases which are more, you know, dynamic in nature. So things like I have a balance and I expect just like my bank, I expect my bank to be able to maintain my balance. And it should be accurate. Or, you know, things that I have purchased, if it's a, if I've purchased a number of, you know, gigabyte, for example, I expect my service provider to maintain that an accurate balance of that. Because that will also be used to trigger different decisions, whether or not I can use a service or continue to use a service or perhaps my quality of service has changed because, you know, some threshold has been met. So that's kind of the very first user story or use case user story. Then you go to the next one, which is basically the way I see this is kind of nested saying, okay, well, that's great. I'm in that situation, but you may find yourself depending on what you're doing. You may also have a need for things like real time and low latency. And this is certainly, again, an area from an online charging system. The need for real time is quite key. So I've described this in a use case, you know, that basically just describing it as being able to do perform real time crud actions. So, you know, when we create things, we want to be able to update them and to delete them. And there's a number of different reasons why this would be necessary. And one of the main ones from an online charging perspective is that you're trying to limit the financial exposure to primarily the service provider, right? I mean, I shouldn't allow you to do something unless you actually have the right to do it, whether you have, you know, monetary funds or if you've actually purchased already some, again, some, you know, quantity of some data or, you know, events, whatever it might be that you're allowed to do. I don't want to allow you to start doing that or continue to do that if you've run out of money, because then I put myself in, you know, I basically put myself in financial risk. So this is where sort of the real time low latency comes in. And if you look down to, if you scroll down just a little bit, Taylor, to the user stories here, I just outlined a couple of examples. No, not that far, not that far. Just go up a little bit to those three green. Yeah. So the user stories here is just kind of, again, playing from subscriber doing different things. The first one saying I want to access a service. I'm not going to go into this in detail, guys, but, you know, just basically saying, hey, I want to do something. But before I can, you know, CSP needs to be able to determine if I'm allowed to do that. Likewise, if you look at number two, this is really, you know, I'm using a service. And the quota that I have, you know, from originally been allocated is, is going to be consumed. And therefore, you know, under the period of me using a service, there needs to be frequent checks to make sure that I'm not going over and beyond what I'm allowed to do. And again, it may serve to make different decisions, which is the third point. So looking at an example here, you might have in 5G and IOT device in a factory, a smart factory, and you're, it's attempting to access higher quality of service, network slice to accommodate a spike in production. So there's a need to, you know, get a better quality of service. Well, before we can enable that, we may want to first ensure that the device has, you know, the possibility to do so or if it has, you know, if it's already utilized, for example, a threshold that was, you know, allocated for the week, for the day, for the month, whatever that might be. So this is just an example of how it might be used, you know, and if you're not, if you don't have that threshold or if you don't have that balance, then you'd be denied or that particular device would be denied if you're stepping up to a higher quality of service. So again, it's just examples of how that really in the end, it's the persistent, you know, this persistent and dynamic data is being used and carried forward to make different business decisions. If you scroll down just a little bit, then, Taylor, we'll get to the next point here being the high transaction, just a little bit there, high transaction processing. So, you know, in addition to that, you know, I'm drilling deeper and deeper to sort of some of the use cases that we face. And one of the things is that we're dealing with, you know, quite a large amount of transactions that are taking place per second. And I think most of us are probably familiar with, you know, if you're looking at it from a 5G perspective, you know, the expectations, this is just going to continue to grow. And we have, you know, some, we have some examples ourselves. I think I've mentioned it in here. And I don't remember, give me a second here. So, you know, we have thousands, for example, per second of transactions per second. Perhaps there's others out there who have, you know, examples where, you know, there's even higher number of transactions per second. You know, these, but these are business decisions, right? From our perspective, each particular transaction is, you know, is eventually a charge that's being, you know, this being applied for some type of event that has taken place in the network. And I'm saying that it's important to be able to do, you know, to handle a very high, high volume. So it's not just, you know, one or two transactions per second, but we're a high number and we're, you know, needing to do things on a very low latency basis. So that's kind of, you know, that's that complicates and challenges things technically for us a little bit further. If you go one more, a little bit down acid compliant. So I think from our perspective, this is not an option. So again, this is something because we're dealing with financial transactions, the expectations that these can be relied on always, that they're accurate always. So when you're making decisions, you know, financial nature, it can't be, it's not okay to make decisions on things that are not yet accurate or, you know, maybe accurate later, but at the given time, you know, it may be incorrect data. That's not okay. So we are required to be acid compliant. So this is again, one of those things that, you know, you say, okay, well, how do we ensure that when you're dealing with perhaps distributed data and, you know, high volumes and low latency responses, you know, things become, you know, more and more challenging. So that's, you know, again, another one I think would be interesting for us to explore some of the best practices around how, you know, others, you know, again, as you fall down this tree, it's sort of how do we handle that? And then if you have to do that as well, how would you do that? You know, where's some of the technologies that, you know, might be possible to use or best practices that might be, you know, useful. I don't want to take all the time here, Taylor. So if you just want to slide down, I think we've got one, maybe two more. The availability and continuity, you know, I'll kind of try to go through these a little bit quickly. Yeah, I mean, as users, I guess, if we think about it, you know, we're expecting our services to work, right? I mean, we don't, we want to make sure that they're, you know, I say, at least from a customer perspective, the expectations is that services that I want to use are available 24 seven, 365. So, you know, CSPs need to have that high availability. And I don't want to pigeon us into sort of the five nines or something like that. And I was thinking mainly from the perspective of, you know, how you accomplish that, whether it's you have the resilience and you can, you know, you can spin up, you know, if you've got a number of instances running of a particular service, one goes down, well, it's not the end of the world. You have multiple and you're able to handle that. So that's kind of where this one was coming from. As is the next point is also really, you know, a little recovery is basically saying, you know, that persistent data is extremely critical. You know, back to the point, it is making, there's financial implications. There are business decisions which are being made from that data. And again, it's not something we look at at the end of the month. So I want to, you know, erase any notion that this is sort of billing data and, you know, we've got, we still have time, but this is sort of, this is in line service being used. This data is constantly being, you know, in order to make decisions for that subscriber, for that particular device, you know, what it can and cannot do or consume. So this is, this is sort of the last place where I wrap up. And then, you know, I'm sure there are other challenges, other, you know, things that need to be addressed, but these were the key ones that I think from a, from a matrix perspective, what we, what we see and what we face within our area that we work within, you know, convergent charging systems for 5G. Hopefully that helps. So hopefully it provides some clarity. Thank you, Oliver. Comments and questions from everyone. Yeah, and this was to, I don't know if Pankaj is on the, is on the call here, but yeah, I threw a comment in there. I don't, I just think it's, you know, I think there's certainly more examples of where we have some of these same kind of challenges. And I don't think that they, you know, some of them are going to be complimentary. Some of them may be, you know, completely new. I, you know, I don't want to, you know, see, I don't particularly see these particular, these use cases or user stories as being accounting related. I think these are very much, you know, these are, they're online charging, they're, you know, convergent charging, they're, they're in line to service, you know, experience and very much, you know, impact the customer experience in real time in the sense that, you know, if you have inaccurate data, you know, you may be denying a customer service when they should have service or providing them a certain experience. And again, I'm talking people, it's easier for us, but could be a device, could be a, you know, piece of equipment that is, you know, then stop from doing what it should be doing, because it's, you know, not accurate data. And that's why I think this is extremely important to the, to the work that we're doing. Yeah. One thing to always keep in mind is IT related things are used all throughout telecom, just like everywhere else. If you're using technology, then it's likely that both IT, generic IT and problems and generic IT solutions are likely to be, are more than likely to be applicable. They may need some modification, but they're very likely. And of course, these particular set of problems, use cases, user stories in the context, these are being used by telecom applications that Matrix and other 5G application providers are creating. We can always add more user stories. So I don't want this to be a block if anyone wants to write up any of this, these particular ones. So this is referencing a good, a good paper. It's, it's always great, by the way, to reference existing papers and content so we can pull more and more material and show relevance and why it's helpful, important. If anyone wants to take these and do a write-up on any of them, especially if it's relevant to you because you're working on these problems, then please feel free to. And this can be adding to existing documentation because you feel it's related. Go in or create new documents to add into this section. These are, this pull request is going to the docs folder covering any user stories, user cases, use cases, but you can add new ones there or add to existing. I don't want to block this though based on that. So if, if folks can look at it and as long as you don't see any problems, I mean, go update this one. Let's get it merged. I'll do it. I'm going to do a review all over this week to go through and make sure there's no, you know, spelling or grammar or anything that we don't want to adjust slightly. And otherwise you'll have a thumbs up for me in the next couple of days to merge. And we want to get some reviews here. If anyone doesn't have, if you're not listed and you'd like to be added as a reviewer, then just let me know. But feel free and add comments and you can put a thumbs up in the comments. Once we have a set of thumbs up and we've addressed any concerns that we feel should be addressed before merging, then we'll merge it. Similarly for the, this one that Ian's working on, if you add comments, we'll try to address those and then ideally by next Monday we can get both of these merged, but for sure the stateful. The air gap may take a little bit longer because Jeffrey's not available. But I think again, this is, these are just areas we're trying to give context. And then we can add to that context. Does anyone have any questions or comments? Otherwise I'm going to hand it over to Ben. Okay. Ben, are you, I'm sorry. Yeah. Are you ready, Ben? Yeah, yeah, sure. Okay, I'm going to stop my share and I'm going to let you share. Go ahead. Just a minute. Okay, while I'm getting back to this window. So again, as part of, wait a second, do you see my window? I do. So, again, I just, you know, our last meeting was way back. So I just getting back to the original story, okay, of, of, of adding security related, the best practices, okay, around the CNF recommendations. And I just simply, you know, started to get together. You know, the best practices from, you know, from getting from the top to bottom, I mean, getting from the most relevant and simplest things with some, you know, very specific with some specific recommendations of best practices. So not just the high level suggestion, okay, of, of, you know, tried to like, you know, when we sometimes we joke, okay, we say that's okay, try to do your system secure. Okay, but that's the recommendation and it's usually it's not enough, obviously. So what I'm trying to do here is I'm with my proposal was to start from the next network security part of, of, of the Kubernetes installation. Now to set up a cluster. Okay, in the, in the telco industry, which is, you know, somewhat more, I would say more native users, more natively than, you know, users who are, who are using Kubernetes in, in by for through a cloud vendor. So, so I started to collect all the recommendations around that and started with the Kubernetes API, because in the previous meeting, we discussed the two main parts, which was in one hand, protecting the Kubernetes API server and the access to the API server. And the second part was in the general, the, the protection of the Kubernetes control plane and control plane components. So not just the API server, but also the kubel ads, the scheduler, the CD and stuff like that. So, so I just simply started to, I opened this document. Okay. And going through, you know, one by one of the, of the configuration of the API server. And simply, you know, taking the configurations, which are, which I think are relevant to secure installation of the API server. And, and listing here, okay, what, what is the best practice and how to do it. So, for example, okay. Disabling anonymous requests, okay. In API server, so API server wants, won't do anything for unauthenticated users, which is an option, you know, in, in API server that you can enable for many reasons. An anonymous request the API server. Audit logging, okay. How to setting up audit logging and audit log. So you have a trace of any kind of security. Events in case of any concern of security event, you can have a log back of what was done against the API server. The authorization configuration and authentication configuration. So, so one hand, okay. Obviously today we are, we are promoting those also in the security, we're promoting the role based access control in any kind of, of setup. Obviously, okay, no, the authorization is needs to be allowed. But, but, but you bypassing a back. Authentication is, is important. Okay. And something up to how we think that, that the modern deployment of Kubernetes should look like. And today I'm going to, to go through, okay, now of the API, clients, authentic API server client authentication and progressing from here to, to the access to, to at CD and setting up secure access to at CD. And, you know, putting inside, you know, not just, you know, not just the state and but also okay. So what is going to need to be set in the actual deployment. Okay. What is the, the actual recommendation of configuration. And if, at least, okay, someone decides that, that, that for his deployment, it is for some reason it's not good at least we have to make sure that they understand what is, what chances they are taking and what is, what is going to happen if they not use the best practices. And, you know, I think that this might, this might be okay. The resolution here is, you know, is very detailed here. Okay. And, you know, really going into kind of different configuration settings, but on their end, I think that, that this is for someone whose hands on to create the deployment. It is going to be a great way of going through these things because in general, okay, these are not very new things. Okay, these are things which were many myself and the other people from, from a security discussed in different places. Okay. But, but I think that this is going to be in a one stop shop of, of, of how to set up these things. And I would be glad to, to, to get some input. If not, then I'm just will progress. Okay. And, and wait for you guys to go to edit to the actual repository. Thank you so much, Ben. It sounds great to me. I'd like to hear some feedback if folks are have any. Nikolai, you're quiet. Yeah. Have any thoughts. So guys, I really okay, so you can, you know, slack also. And, you know, you can also come I try to enable comments here. Okay. Documents so I will try to finish by the end of this week. Okay. All the. All the APIs are a communication part. Then okay, I would be glad next week to just discuss how to, how to edit in what format we can edit to, to the, to our repository. I assume that we are still recovering from. I tried to, and I tried to access it from an account that you didn't share with, and it's not accessible. Okay. Can you set the settings so that anyone in the world with the link, anyone with the link so that, yeah, sure. Yeah, click on share with Armo bottom left. And then change it to let on the left hand side. Anyone with link, but make it common only. Yeah. Yeah. All right. Now I'm going to refresh. I should be able to access it. Okay, great. Can access it now. And I should be able to say. Make a comment. I'm going to make a comment. Yeah. There we go. I also should be able to, the good thing about this is I should be able to. Yeah. See that that's like a suggest edit. Okay. See that at the exclamation point. Yeah. Yeah. So everybody that has the link, if you have. You know, want to add that you have thoughts or comments or you just want to update like a grammar. Spelling, whatever. Add some clarification. Either add a comment or directly suggest an edit. I'm going to delete my suggestion, but you can suggest an edit. And then we'll look over it. And if it's, you know, it's aligned, then we can just add that right in. And that'll help Ben move this along. Feel free to look at it and review at your, you know, whenever it works for you, your time. Thank you, Ben. I appreciate this. I think this can be a very good one to get in. Awesome. All right. If there's nothing else, then we'll end there. And we'll be back next week. Same time. Same. Hi, everyone. I have a question, actually. Go ahead. Hi. So I'm new here. My name is Charles. And. I wanted to ask how would I, how would I contribute? Because I'm pretty new to this technology though. But I was hoping maybe resources I can probably read all, you know, or anything. Because I find it very interesting. So yeah. Well, if you're wanting to contribute or you're looking, I don't know what you're looking for. If you're, if you're developing an application, trying to look for improvements or want to contribute some more. Yeah, maybe contribute. Probably contribute here, right. Same, I guess. Because technically I'm not that good right now. You know, these aspects. Yeah. All right. So this is a new area maybe. So the, the working group has. Documentation. You can look under the two main areas. I'm going to try to bring this up. I can screen share as well. Let's see. All right. So there's these user stories and use case folders. We'll probably move those under this documentation folder. I'm going to bring this up. But this would be some areas to kind of look and understand. The context around. Problems that are trying to be solved. Specific to communication service provider environments. But a lot of these are generally. Useful for any type of. Networking environment and problems you're running into. And some of them are. Even applicable to. General IT issues. But you have under this user stories. This is a security related set of. User stories. Supply chain attacks. So these are laying down a bunch of areas where there could be problems and then we could talk about. What are different ways that we can try to address these. If, if a. Attack occurs, then what are you going to do? How do you try to prevent them as one thing? And then whenever you can't prevent it and it happens. Then what can you do? And that's what a lot of this is leading up to. Under the use cases, we have different things like onboarding. So this onboarding, that's about. A new application, let's say you have a firewall or. A charging application like. What Oliver was. Presenting user stories related. You're bringing that into an environment. And what are the different things that you may want to think about. And this was actually put forward by a service provider. And talking about some of those. Different life cycle issues. More on the stateful things you should think about. This one's a more specific. To a. Application and set of, I guess, related applications. So BGP. And what you need to think about. There's, if we go into some of these, they have. Diagrams related. What are we looking at here? So these are all areas for context. Under. Let's see. This document. Areas probably not it. Here we go. So the best practice area right now, we don't have any that are published other than the, the non-root. I think in this quarter, we'll probably see a few more. And then more and more come along as we've gotten all the rest of the documentation. The context, but we should start seeing more in here. These are going to be specific. So if you're interested in. Some of the practices that exist in other areas. So non-root is not something specific to seeing us. It's a good practice everywhere. It's utilized in many areas. If you're in a hosting environment. That uses SC Linux like. Red hats. Environments or other. Hosted solutions, or maybe you're, you're seeing an environment that someone's. Building their own. In a non-root based environment, they may have root disabled. Capabilities. So if you're already doing this, but it's a good practice. I mean, even if you're directly running on the host, it's a good practice for a long time to do non-root. We want more like this. And it talks about. Why a very specific practice is useful. And while we're recommending as a general guideline that you can do non-root, it's also useful. And this ties into a lot of those user stories that I pointed out before, those supply chain attacks. And where non-root could help. And then trade offs that you're going to have if you go with root. And then a lot of references. So I think it was Pankai on. One of the other pull requests. I think you could, I'll read them. So these are all areas I think you could go check out if you're interested in. On the documentation side, reading, writing up new ones. The CNF test suite. This effort is around. Implementing. Tests that are checking various practices. most environments where you're already building software and you want to test and validate that things are running as you expect. The I guess implementation site moves at a different speed from the documentation side as we in the working group we're figuring out how things make sense to a large group of people and trying to improve how it's communicated on the test suite we have at this point I think it's close to 50 tests implemented across many different categories so we didn't really talk about the categories but if you think there's stuff that we're talking about compatibility the statefulness that Oliver and talked about earlier security there's a lot around security so there's a lot of different areas so the test suite itself has close to 50 tests if it didn't hit it already over the holidays and this would be another area if you want to come check out and and take a look Thursday if you want to run it so if you actually have an application that you're wanting to test there's a quick start on the main read me where you can actually run and try the test suite out if you already have a Kubernetes environment and utilize an example seeing off if you don't want to try to configure your own yet five steps you can test with it and then you can go check out the install guide and configuration guide for more info and the individual test you can go look at the usage guide if you want to read about those I'm going to bring up security ones here for example like privilege S escalation so this will be on just non-root as their capabilities to do escalation of your container or pod this is actually one that's utilizing the and CubeScape from Armo and you can go read more about this specific test we try to put reasons why it would be problems to allow privilege escalation not that you may not need it that's fine if you have an exception it should be written up but in general we're saying you shouldn't allow it for most components and most applications so we have tests around that there's a lot of other areas and we're trying to write up include documentation for each of the areas as well as remediation if you're trying to improve then we try to link out to different documentation to read up and do those improvements so if you're wanting more on the implementation side then getting involved in the test suite would be a good place this meets there's a contributor meeting that meets on Thursdays at 1415 UTC you can join there there's slacks for both the working group and the test suite channel so you can chat in those but either way it's you know you can get involved read up learn more about the area and happy to have more contributors than any of it including stuff is as simple or straightforward as grammar and spelling mistakes all contributions would be appreciated amazing thank you so much thank you you're welcome any other questions or comments before we end the call thanks everybody we'll see you again next week same zoom same time