 Hello, greetings. See about half of you may have been on the telco music group. Which just ended. This meeting CNF working group is being recorded. It's be published to YouTube. We'll get started in about three minutes at five after. You can add your name and any agenda items to the meeting notes, which I've posted in the zoom chat. If you have any agenda items, you can drop them in zoom chat if you're not able to read the access to Google Docs, which I know doesn't work for some people's work firewalls. All right. Let's go start. Let's see. Who's had your name and if you have any agenda items. Let me know right now. Does anyone have anything they'd like to add. As I can look at pull open pull request. Try to work through some of this. All right. It's very quiet. I'm going to presume my audio is working. It worked on the last call. We can hear you. No worries. Yes, it still does. If no one has anything else, then I'll jump into the pull request. I'm going to work top down. So I think this one came out of comments in the last call about best practices and the template we'd put together was based on the Kubernetes enhancement proposals or caps. And this was before we actually had best practice proposed and trying to see what would be most relevant and useful for us. The test plan, just the wording around that was throwing throwing off some of the view of what we needed to have in there. And it seemed like test objectives was an agreeable one. Let's see if I can give some context like this. There we go. So when you're giving a test plan. I mean, talking about is the best practice testable is the main thing so thanks some of the comments where we put a plan to how detailed do we need to get when we hand it over is it so specific that anybody could implement it. That agreement was we're overall saying test objectives and is the best practice testable and letting implementation of that be up to whoever is writing the test. But this one looks pretty straightforward. If we could get some plus ones on the call, unless there's objections. To be clear, we removed the wording for test plan and instead it's testing objectives. Correct. Remove test plan replace it with test objectives. That's great. I think that's very clear. Thanks. I would. Should I do it right now. Yes, please. Please. I'm going to bring this one up since it actually has more context. But does anyone else have a question or comment about that. Oh, okay. So, and this one right here, test plan application which follows the best practice will not have any containers with processes running as root. This best practice will be tested by the test suite. Some of the comments where this doesn't have enough information as a plan for someone to just implement what are the inputs and outputs and other things like that. So rather than saying test plan we'd say test objective and that example testing objectives so higher level. All right, I got one plus one. We get some more on this call. Maybe I'll are doing it and I'm not saying it calls. I will know that I appreciate a Jeffrey's idea here of calling it testing considerations. But I think testing objectives is fine. It's under that you can put considerations for those objectives right have to reach them. So it's it's all about the details. I agree. And I think that's a good idea to put considerations and their when it's relevant. If there's something or someone has experience trying to communicate that would be great. If you want to. Thanks, Ronnie. I'm going to count that as a plus one you can also click on for those who haven't done this. So if you have any files click review changes click prove do a plus one or LGTM. This one's pretty minor one. I think we haven't like specifically labeled but for bigger ones we wanted five I believe and if I go look at the merge. And how we're going to do that. We probably consider this one like a smaller update on wording. If there's no objections I'm going to go ahead and merge it. Okay, the next one at format version CBB. Ian is off. I'll try to speak to this. Let's see. Bill are you on the call. Is this just a formatting issue. Lenting. Okay. Sorry, I was on me. Yeah, it was just adding the space afterwards all the checks could pass. All right, sounds good. Okay, so going over here. This is a hidden HTML comment. And I won't click rich shift because I think it may yeah disappear. But having the whenever anyone copies the content over that the best practice that you have would have like the template version so if we're updating it will know hey we changed test plan to test objectives. Let's make sure and get all those updated. So that's really what this is about. So I'm, I think this is probably a minor one. I'm going to say just thumbs up for myself but if there's no objections I'm going to merge this one. Oops. I don't know what just happened. So the next one is this best practice that you and I put in but there's been a lot of comments I think. So no plus ones, we have things to respond to. Okay, so Jeffrey and Ian are both not here. This one was a wording change just trying to make the summary a little easier to understand. Let's see, and Jeffrey says yes so I'm going to update that one. So the summary would be containers have a list of their own users and a bit of the host system, one of which is you at zero or the root user containers should run processes as a user other than root, which makes it easier to run these images securely. I'm just going to accept that for Ian since he plus one day and going down Victor application bug. Okay, so this is around goals. So opinion application bugs and generic term which cover application bugs or bugs are a generic term which cover many aspects. As far as I understand yet as far as I understand the main idea is to reduce the attack surface of by limiting permission. So this update was, I think, removing the behavior of applications when bugs occurs and in seem to not agree. And I also, I guess, disagree with the change. Because the, you could have non security issues but if there's, if you have root in a container and just something, some bug or anything occurs, then the application could do more problems because it's less restricted without being malicious or causing like a potential access to something maybe it just doesn't behave properly or you have data corruption or whatever else is a result of that. Victor you got a thumbs up but if anyone victory you want to comment on this or I mean, it's okay to keep it up to these. All right. So I'm going to resolve it so that we can move forward. Unless my only comment is the British spelling of behavior. You like it. I, we haven't decided on the standard so I think so far we've been mixing English is, I think everybody will be fine with it. When that's decided we can go through and updated everywhere. All right. All right, so Jeffrey, I think talking about the way the goals section, it's I'm going to kind of scroll because you got to see the whole thing here. So the goals section, I think it was more of a formatting he verbalize this on the call and then added a comment as well. That it wasn't formatting way to see it as goals. I think was the main thing. And so I split it out. The where the reworded it. So this bottom line he's commented that's a goal avoid compromise up causing more damage so I took the way the Senate structure was improve the security and behavior of application when bugs occur. Added the defense in depth strategy against external compromises and then we have avoid compromised apps causing more damage. I think I'll have to delete a maybe this extra space so that they'll just be one after another. But that's the idea there. Can I ask a question. Yeah. In your sentence improve the security and behavior applications. Why is qualified to live and bug circle. Sorry, can you repeat the last why is what. So why qualify that same, you know that phrase by when bugs occur that phrase when bugs occur is not necessary. Okay. I think by itself we want to improve the security and behavior of applications. Yeah, that sounds good to me. Second thing is that this is replacing the root user. And that issue is still not addressed. You don't you want minimum or least you want to follow the privilege, these privilege principle right. And I think that should be captured. Because it says avoiding the root user in containers and you're replacing that with these two command or two principles but it's still not covers the root user. All right. I guess we were the summary captures not here. The goals. Yeah. Understood so the summary covers that motivation refers to the user. And I guess within, if you take the context of all of that and maybe the next sections on that like the proposal section. Then you get how are we going to do it so the whole best practices about don't use the right user. So it seemed like it may not be necessary to say, it's not the best practice is to avoid using the user, but the goal is to use the user. That's a way to get to the goals. Yeah. And you could also introduce one of the goals is use principle of least privilege. Okay, I got maybe let me. I'm going to adjust this one. And then, yeah, approve, improve the security favor when a box occur I agree with maybe improve the security behavior of applications. Okay, so that's okay. Sorry, go ahead. Yeah, this does read a little bit strange to me because these goals. They are so the general. And, and if we really do want to apply that principle I mean there are all these aspects that have well beyond root, you know, well if you're using another user have you given it full permissions to do anything at once it might as well be root are all your files set with attributes that allow any user to write them for example there's really narrowly focus here and but but the goals on the other hand are really really broad it sounds kind of strange. I tell I agree that we're going to have, maybe we could say duplication or overlap. However you want to see it between best practices and use cases. It's just known, and we may be able to share more as we go on and say here's some general information like the glossary. But we're not trying to get it perfect between them to get started. So if we have something general and then have another best practice based on least privilege, it may have some of the same goals. And right now I think we just recognize that and that's okay. If we have a specific goal though tell that you can think of or anyone else can think of that we can say oh if you do know root here's a very specific goal that's just applicable that that's great we can put it in. Well I kind of think your original wording was closest it wasn't written as a goal. But that captures it right it directly addresses roots. I think if we write goals that don't talk about roots, they just seem out of place to me. Yeah, but the no routine containers basically helps achieve the goals that are being listed. So improving security and behavior is a very good goal. And it, you know, no routine containers contributes to work. No routine containers also contributes to defense in depth if you will, as well as the least, least privilege. So what about using improvement the security and behavior applications by reducing the privilege of the container so something like that. Yeah, that works. So something like this, avoiding or in containers can help to improve the security and behavior of applications out of the fence and debt strategy against compromises avoid compromise apps causing more damage. How does it avoid compromised apps. I'm sorry. How does no routine containers avoid compromise apps. It helps to avoid compromise apps causing more damage so if you have an applicant, if you have an applicant. You, you understand. Yeah, I understand just that the promise missing avoid compromise the apps from causing more damage. Oh, all right. Let me go ahead and cancel. Yes. I think like that. Plus, I'm going to delete the extra line at a dash avoid compromise apps from outs from causing more damage. Yeah, that's what you're saying to say right. Yes. So just to underscore the point I was making I think this is the goal. This is the closest thing to what route provides. The other ones are just so general this this is what route does right route helps avoid compromise apps from causing more damage. And improves the security and behavior of applications right. Did you think that we have to specify where the damage is like in the host or like just in general. It shouldn't be the host otherwise there's something very wrong with your container technology. Or you're running in a privileged container which is another problem that we're not talking about here. But but we're assuming here that the container works and really containerizes. So it kind of things that route can do very much depend on what's running in the container so files, networking, anything, root can do anything it wants right. Normally, app uses a route to change IP tables and send information to the wrong place, something silly like that. Or of course change files. All right. So here's how it looks right now. Avoiding written containers can help to, and this is high level, then tell improve the security and behavior of applications so this will be what we could say a high level goal. Added a defense and depth strategy against external compromises. Again high level tied in with all the other work we can do, and then a specific avoid compromise apps from causing more damage. All right, if you have more suggestions please add it as a suggest commit. Let's see so the next is under the proposal comments looks like. I'll just read it for those who haven't seen it when building a container the container should be built to run its processes as an on route user set up s ID processes should not be required to do the work inside a container. This is the best practice. The root user is a container, the root user in a container has fewer rights and is distinct from the platforms route. The containerization process includes a user using a C group user C group which means the containers users are distinct from the platforms users and do not include the most dangerous elevated rights. So Victor you talked about this is the case for the mapping from the container from the platform, if it's actually enabled. And Ian was saying maybe we should talk about best practices that may be a platform type of best practice that you should do that and always enforce it. And I made a change here, Victor, and it looks like you did something an exception to that would be separation container runtime is not using username spaces, but it looks like you've made another change. Yeah, well, I was just trying to clarify the first thing which is talking about rights and units current capabilities. The first thing that you mentioned at the beginning. More like, yeah. So I guess it's more accurate I think. All right, so it sounds like you're doing just an alternative suggestion. So I tried to add it as an exception. And you just it looks like you're writing in a little different, but less words which includes two groups. So you dropped all the C group stuff. Yeah, because the group or my understanding is like controlling like restricting the amount of CPU or memory, which is not changing the users or a mapping. All right. And then, and it's confusing you're correct and once fixing its username space not see groups so we use the wrong word but namespaces some see groups do very similar things. Okay, so I don't think he oops, I scrolled way too far. Ian is disagreeing. He didn't explicitly give a thumbs up but he's saying the words wrong so I'm going to say that sounds like agreement. And I'm good with committing this. Ian and I like submitted this best practice together I'm good with just taking this one. grammar it should be fewer instead of less has Okay, I'm going to go ahead and unless Victor, Victor, do you want to modify it right here and right here and put fewer. The right user in a container has fewer. Okay, and then I'll commit that and resolve this issue to be clear should we just say containers root user has your Linux kernel capabilities. Let me say that. Sounds like you're wanting to reward the start to make it clear. And you could add it right in here to the, as a comment to Pankai. Let me add it as a comment. Victor, did you update with the fewer. I'm not seeing it. I'm going to refresh again. Yep, there it is. The containers root user has fewer. No problem. Has fewer. I'll just write like that containers root user has fewer than external permissions and maybe distinct from platforms root. If the container runtime enables us username spaces. Yeah. It just makes it one is consistent and it's basically is like platforms root containers root. I probably not even put this in parentheses vector we could say maybe when containers or user has fewer Linux kernel permissions and maybe distinct from the platforms root when the container runtime enables username space is remit feature. Pankai. Can you make a suggest edit. All right. All right. I'm going to go ahead and go on. I resolved it, but I'll. That's everybody okay with that. Well, you can put it down and then we can check it out. We're trying to get down to the point where we can actually get plus ones. Right now we have. Updates. Let's say if, yeah, only place updates. All right, so let's go on. We'll come back to yours in a moment Pankai. So under trade off constraints caveats and any notes that's a big section header. Okay, so just some comments about other best practices. Okay, and just where that could go. And that's it. So there's not really any thing to add there. That one could be resolved. I'm going to leave it open, but I don't think it blocks. And Victor you have a CVE that you think is relevant. Well, yeah. Container breakout all versions. All right. Vulnerability militia container with minimal user action over its host currency binary gains root level code, some other things. Yeah, that sounds good just add it in. So this section is, it's under the notes area, just so that people can look at more info and we have references so that if someone's wondering why we're suggesting this is a best practice. What benefits and everything else. This is references so you can go read what folks and industry are doing. And to add that if you'll do a suggested it vector. But we're in the references. Yeah, just add it to the, I would say yes to the references yes to adding the references. All right, alternatives. So, we just put a couple of things in here I don't know that these are alternatives. There are things you might do. You're allowing or what you could do. Talked about rootless Victor you put this forward we talked about this a bit and kept on that a new cap to address some rootless stuff. And I think the comments were saying that this may be a little different from this best practice. There's no hasn't been any updates. I guess we could mention it if you think alternatives when mentioning the rootless and user nets, then you could do a suggest edit as well Victor if you, you think there's something that's helpful. Then I would just added this is suggest that it. I'm a little confused about this alternative section. We're talking about alternatives to applying the best practice or caveats or ways to mitigate that there's a there's a huge discussion that can be had here. Yeah, this would be alternatives to using the best practice. So we have the caveats and you're in here's problems you're going to see or notes where you go. Whatever other comments when you're using the best practice. And this is alternative paths. And it may not be necessary on every best practice but and we're not going to list all of them either, by the way. So the assumption here is that somebody is not able to apply the best practices so okay if you if you absolutely have to use roots. Here's what here's what you can do that could be close to that is that what we're saying. So it's like compromises rather than alternatives, because they're not alternatives to there is no alternative to not using root. You either use it or do not. Maybe, maybe alternative slash compromises for this section might be good. So if we, they're probably our best practices where you could have the same outcome with two different best practices, and maybe this one doesn't we're just saying, you're either going to use root or you're not. And if you don't need compromise, then here's some other paths to deal with it. I guess what I'm looking for is something like considerations right okay why. Why do you absolutely need to use root and if you do what can you do about it something something like that that that to me is where it could become useful. Do not run the container in privilege mode I guess that's what it means. Well, I, is that an alternative. It's, it's, it's a different approach to and then achieve something else. So again, going back to the goals. You know, if these are our alternative ways to achieve the goals are goals, some of them are extremely general right so if, if you're looking for an alternative way to make your application more secure. There are lots of other things we can suggest. Sure, so if we don't have anything specific, like, then we just leave it, we don't want to block this but if there's something like Victor saying using. An alternative slash compromises whatever we're going to say on this, then maybe one of them would be, if you must use root, you could take a look at using cotton containers which give more isolation, and then a link over and we don't talk about it in depth that should go somewhere else which may be literally like the project, or we may eventually have using caught best practices for using cotton containers and we go go take a look at this best practice, or something, you know. But that would be if you have a concrete one towel, then add it in. If you can't think of something right now, we can always come back later and do a PR against the public best practice. I guess I think that what he is writing here is very beneficial I kind of think that everything else we had in the document so far is to me, reads as kind of trivial I know we're picking on low hanging fruit here because we want to get something out. But it's it's fairly obvious most of it. I think where we can make a contribution is exactly in this. Well, if you can't run route. Here, here's an in depth discussion of how workarounds you know, rather than alternatives maybe another way to think of it is workarounds right you absolutely must run route. Here are a bunch of suggestions we have for for how you can work in that situation. Then suddenly the document becomes useful. Probably 100% I think that's the gist of this work group to find these to come up with this recommendation I mean saying you don't have to run route you don't need this work group to say that. But we as a work group I think we are responsibility should be analyzing why do network functions need route like, for example, if you need to create a raw socket for your crazy protocol. How do you do that just saying don't run route. Okay, so I don't can't use my protocol. So we need to discuss here ways that maybe Kata containers is one thing, maybe others but I agree with 100%. This is what we're here for to help people with solution, not just saying, giving them the don'ts but giving them the dues as well. Alright, so that that I agree with y'all and the idea then is, let's get the trivial ones in place so that we have a baseline. And then we go okay so what is this use case. Someone put for use case where we have a application where we say we really think we need root here. It's going to be against this best practice so what are the best practices for having a container with root, and we can analyze that. So I think tall suggestion to call this work around, I think should be adopted. Instead of alternatives worker on is a much better word. It's not even work around that's exactly like that's the whole thing that we're trying to define here it's not a worker on it's like the solution so the problem is you cannot run route and here's the solutions solutions that we are proposing for you. I wouldn't call them even work around and I would call them by recommendations or solutions or whatever. It's a work around to getting around some of the problems of running route right. So, or you know just run route sometimes running route is the alternative. It is not the end of the world to run route. Yeah, you have to understand what the, what the trade off sir. The best practice. So what we're talking about here is the best practice, not the exceptions. So in the best practice you should do no root. And now we say, but what if we have another use case where we say we must have some type of privileges. Maybe that means that you say, well you should, you're going to need route, and you, we suggest you run it in cotton containers, or you're going to need root, and we suggest that you split it off and run it somewhere. I don't know whatever that is, that's fine. It wouldn't be in this best practice. So we're not giving the solutions in this particular one for running route. That will be an additional document which we can leak in here. So we close those up, and we do the work on it. We can put whatever we want to call this section alternatives, or best practice, we can have another section best practices for when you need root, and we will link out to that, which will be a different document. That makes sense to me so so I guess I'm just going back to what I said that calling the section alternatives is. I don't understand it, but still, I wonder if we still need it even and if we do add things in the future we could add those sections but I'm suggesting we just remove this section. And Taylor regarding this section is just related to Kubernetes or just CNN in general, or I mean, for example, user remap is not supported by Kubernetes by now, but it is supported by Docker so maybe using user namespace remap can also mitigate that problem. But definitely it's not going to be, it's not supported by Kubernetes yet. All right, like the user nets is it's coming related practices. It's trying to find a word towel that fits what we're talking about here. This section is to point people to and other places you've, you're saying we're going through this and some people may agree not agree with the root or whatever hopefully we convince them for the case that can but for your case towel. And Ranny, you get to a point where you go we understand this is a best practice, but we have to do it so what do we do. I think this section is supposed to kind of point people somewhere else. And right now it would be very limited because we don't have anything else other than we can kind of point some stuff out. Related practices. Alternatives related practices. Is there some wording that could fit for pointing people that using cota containers, or does everyone agree with just deleting this whole section. Sorry. I just wanted to say Taylor you said you know in the future we can have more PRs. Let's just not waste time on it right now, remove it. If in the future we want to add something maybe the name would be more apparent once we actually have content. I want to see what Victor you come up with. And if I don't. If we're right now we don't have any plus ones but I were, we still need the use case. So maybe next week, if we don't have anything useful in here, Victor if you add anything then we can take a look. And I'll think about it tell for just deleting or not on the wording, but add a comment here. If you can tell on your thoughts like about the section and stuff so we'll be able to come back to that. Yes, sorry for just being critical without having an alternative solution. I think putting myself in the right things just target audience like whoever reads that. I mean if we just say you cannot use root. That's it. Okay. How much value did we bring to the end you to the audience. I mean if we say, okay you cannot use root, but here's some further reading or some suggesting to marry where you might start I think that's more powerful than just saying you cannot use root period, go figure it out. There's alternatives. There's like something you're saying or anywhere it's this is like it's suggestions. Yeah, I would say it is like further reading or where to go next it's don't leave the audience and the audience hanging like. To solve all the cases I guess what you're saying, Randy, the so complex we end up getting at a point where we don't make any progress. So, the end goal would be all of these when you're reading a best practice, and it doesn't apply to you. It would be great to have links to alternatives. Probably what that's going to happen is iterative for this. Suggestions for you want something like this for when you must use root, something like that. Yeah, but we don't. We're not ready there yet but that's what we want. I'm going to delete that for now. If y'all have any like related alternatives that's what the section be about drop it in here. I'm going to move on. Okay, we said test objectives. This didn't get. Oh, that was from the other one. So just updating it here. I added my comment. So this section is. Let's see. Oh, sorry. Do not run the container and privilege mode. Okay, I'm going to grab that one. That one's pretty straightforward. Commit this Victor that CVE. I can resolve that. And okay, I'm going to leave that up until we read more, but it looks like all of them. I think all of them have been resolved at this point. Except for that one section. There has fewer privileges. And maybe to sync from platforms route if the container runtime. I'm good with this. I think it's just rewarding. So this is still showing as a draft. Because we haven't added the user story, which we've been working on, but it's not. A linked in or added in. So that would be holding it from moving forward. But if folks can take a look and see if there's anything else. Outdated outdated. All right. We have five minutes left. And the book is out, I think until next week. Is there been any progress on the glossary towel? I don't think so. Kind of left it where it was. The problem is I think there are just discussions there that haven't been. Resolved. We can revisit and talk again. I've resolved a few that seem to me, seem to me to be resolved. But for some of them, I'm not sure everybody is completely on board. So, um, yeah. We don't have to have agreement if we can have a. If we feel like everybody's been heard and we're. I don't think there's a point to accept it. I don't think there's a point at a point to accept it. Even if we disagree, or we had a point to accept it as is where we can update it. So this physical network function, PNF. Definition. There's been a lot of talk about it, but no suggest edits. And I don't think any. Right. Yeah. That's why I'm stuck. That's why I'm stuck a little bit. I feel like a lot of these conversations are just. Conversations. Yeah. Yeah. So this one, one where. Do we have, are there any objections to resolving it for now, as is to keep. And then we can go update the glossary later. If there's changes. If there's no objection, I'm going to resolve it. Also regarding the glossary. We have another discussion. For some networking terms for the glossary. And this hasn't moved for, for a while. There's no objections on the terms currently. So if you people can just review it a bit, and maybe we can create an extra PR for that. If everybody is on board with those terms, I have pasted the link to the, to the agenda. So, yeah. Right. That actually seems sensible to me to have the discussion discussions. And then maybe create a PR from that. I don't know. I mean, we can still, I'm not trying to push my PR through, but we can accept my PR and just treat it as a draft, you know, and continue, continue iterating. Yeah, I agree. I agree with that. I'm going to resolve this one, the PNF. And let's go ahead. Yes. For talking on the discussion board. That's what those are for. If there's someone's unhappy with something that's being merged, please continue on the discussion board or create a new PR. And Demetrius, if, if you have something specific that you want to add, ideally glossary terms, we want to add the minimal amount necessary at any given PR so that we can get it through sooner. But if you have one, then please put that in. I've gone ahead and resolve the. Physical network function. I'm going to work through some of these. Let's see what's next. The cloudified. Um, That was the most controversial, but the, the, the one problem with removing this cloudified network function term. Um, it, it, I, and the, and the KNF term, I refer to this. I use it as a classification and here I explain kind of why that is needed. I didn't have a real response to my response. So I, um, Anyway, I feel, I feel like it's still just unresolved. Um, and we, we are at the top of the hour. I can suggest maybe we can put this at the top of the agenda for next time and really just try to finally, finally close this. Sounds good. Let's do that. And, um, please. Check out the, try to, I guess, add any comments on ones that you fill or if you're good to go forward with any given one, then give it a plus one as the work in progress. And if anyone else has comments and please add them, and we'll continue with that one. Continue with glossary. I'll just say that I think that the biggest block right now is in fact, you Taylor, you, you had the biggest objection to the classification, clarified network function term and, uh, maybe we can just discuss privately and see if, if, if there's a, some compromise we can find. Sure. And I can add more comments myself to it. Yeah, that's, that's my worry that the comments just start getting very, very long, long speeches about, uh, the, the, the, the, the short term. So, uh, I feel like we're in a bit of an impasse there. So, um, But yeah, we could, we can discuss this next time. Sorry. I don't want to take more time. People have to go. Thanks everyone. See y'all next week. Same time. Thanks everyone.