 Hello, folks, we'll get started at about five after. Hey, Oliver. Welcome, Kusher. Good morning. Good morning. We'll get started about two minutes after. You can add your name and any agenda items to the meeting notes, which are posted into the zoom chat. Hello greetings, everyone. Let's see. We'll get started here in just a moment. You can add your name. And any agenda items, or if you have an agenda item, you can say it out loud. I'll just add that into the zoom chat. Welcome. Michelle and Ben. Hey, Frederick. And Ian. Hey. All right, Ian. All right, I'm just opening the agenda to give me a moment. No problem. And then I could. Help you, but I'll let you, I'll turn it over to you late. Good morning, everybody. I'm used to being fraction late. Let me try and share this, but it looks like I can't share today. I'm afraid. Right. So if it's not a problem for you. Taylor, could you do the sharing while I do? Yeah, I'll share the screen. Yeah, sorry. New laptop. It's forgotten all of its sharing permissions. Right. So. The first item is simply the upcoming events as usual. We've got KubeCon imminently. So yeah, KubeCon at the end of the week. That's the China version. So for those of you who are a little bit more in a civilized time zone and who have signed up to it, I hope you'll go to that. I don't know if anyone's got any. I don't know if anyone's got any specific sessions they want to raise while they're here. I see we have one listed in the minutes there if anyone's interested. Nope, fair enough. And then for a second round of everything happening in Asia, then it looks like we have the open source summit in Japan as well, which looks like it's going to be next week. Then beyond that, we've got a round of things coming up next year. You can read as well as I can. So you're good. Other than that, apparently we have zero agenda items. So what I'm going to do is have a look and see if we've got anything on the pull requests. Does anyone have anything that they just want to speak out loud and we can add. Well, got very quiet meeting today then. This is going to be very quick if we don't think of something soon. Is my audio coming through? Yes. All right. Yeah. So if anyone has any topic, just anything you want to talk about regarding CNS cloud native, we can just add that or look into something. If you had questions about something, we can put it on the agenda. Good morning. Yeah, I think I wanted to check with you on the proposal thing. I think we had a brief conversation over the email. Can you share more details about that? Is there any link or something that I can go through regarding contributions? I think there's a couple of topics though. Talk contributions to the working group or the blogging. I don't know. We had a couple of things going. Can you hear me? Yes. So what was the specific question or topic on that? And just add it in and we'll dive into it. Yeah, I wanted to basically know the topics for the proposal. Right. Yeah, let me add. Best practice ideas. Yeah. Just make sure we're covering the right. The right one. Okay. So just what is the, how would this. How do you do it? What's the process and what's involved? Is that, is that kind of the question how to do it? How to contribute best practice? Okay. Is that the question? How to contribute best practices. Yeah, so. Yeah, so best practice. Yeah. Yeah. So the topic. So what I am currently working on, right? I think I was discussing our previous meetings. I was basically. Working on. Integrating our. Into CNCF. And also we have a bunch of best practice. Policies. That that can, you know, be used to. You know, I think that's one way of contributing. I think. But maybe I can come up with a write up. You know, and share it with you. And then. You can decide on that. All right. So it might be good to, I guess, for folks on this call that haven't. Same. Give a little bit of background. So. Kyverno. Is a project that. Can it's a policy. I guess a policy agent for. Kubernetes. And you can set different policies. There's different. I guess projects out there like OPA and other things that can do it in a different way. And Kyverno is one of them. And there's been some interaction with Kyverno and the. The CNF test suite. Around testing. And checking things. So. With regards to the working group. I think what we'd be looking at is. Not the test specifically, but what, why are you testing something like, what is the best practice behind it? That. That we would want to. Capture and tell people that you should. Try to cover this, whether they. End up using Kyverno or. Directly. The idea would be if there's a practice like, this is the wrong one. All of that one's good too. There's a practice that. Recommended. That we all recommend. So this is. The one that's been published. We can point out. So. Non-root. So there could be many different ways to test. For the use of root users and containers. That a process is being. Run as root versus. A non-root user. Or potentially. A related thing would be users above. UID 1000. And there's many different ways that you could test this with different, there's different projects that try to test this, including. Cubescape, which we got been on the coffin. Okay. Falco does some testing around that. There's a lot of different ways. So the best practice, we're not recommending. In the working group, we're not recommending. The use of. Specific projects. That's up to implementation. It's the best practice in general. So we'll say, don't run. Not. Your processes. Well, user may say, we're using this project that does rootless containers. Or they say, oh, we've. Refactored and broken things up and we do it. We handle it in some other way. So whatever the best practices, someone could implement in multiple ways. And then, of course, we'd like to be able to test in different ways so that. We're catching all the different, maybe edge cases and different ways that something may. Be seen. But this is kind of be the goal. And I can stop there. We can kind of dive into process that. Many of us know, I guess, from the working group side. I think the least privilege, probably the session notes and that we worked on this. I've been giving this as a reference. For many people, I keep. Opening this wrong one. Get rid of that. Yeah, I mean, I'm just looking at the Kiverno website and list of policies that it's got, which effectively says, you know, these are things. You could be doing to a container as hard as it starts. And. The question would be the open question between those policies and what we're talking here would be, what is the need for doing that in the first place? What helps with that? And, you know, why does using one of those policies improve matters? Why would you want to make that decision? And, you know, why does using one of those policies improve matters? Why would you want to make it a default of the cluster? So you've kind of got to join the dots between, well, you know, we strongly recommend you do X. And the reason we recommend you do X is this reason. Can you give an example of a policy and we can take a look at it? I guess they have a best practice category. Why not that one? That is one example. We can take a look here is dropping all capabilities. Yeah, if you go down, I think there must be, yeah, drop all capabilities. All right. So this would be, I mean, it's literally labeled in your category best practices. So if we said this was a. A best practice that we think the CNF working group should promote. It's a recommendation for service providers to adopt and say, we want everyone that's creating these, and it's a best practice for people creating these network and applications to adopt when they're building them. So we're saying, we think you should drop all capabilities. Then what we're going to want to do is go through and communicate that. So this is kind of the quick summary, which would be related to what you're going for here. Capabilities right here. So all of these should be a drop. That's kind of the summary. And then you go in and talk about the motivation. Here's our goals. So how is this going to help? So we're wanting to communicate to the end user. Why do, why are we proposing that you drop all capabilities. And then you can kind of go in here and talk, talk about it. One of the important areas is going to be a user story or use case. So for the non root, there's a whole bunch of reasons to do it. We have a set of user stories. Under this area called supply chain attacks. So then this, these also could be applied to other best practices. But the non root is referencing them because we're saying, if you have a compromised update, you have some type of security bug in the, the application. Then if, if you're running non root, then it's going to have less effect. Probably just by thinking about this, these drop all capabilities would be able to also reference that same set of user stories. Cause if you have, if you've dropped all capabilities and you have a supply chain attack of some sort, then they're going to cause less damage. So potentially this whole section here on non root would be usable for a lot of people. So that would be a good practice of drop all capabilities. Yeah, I think the question that's coming up. The question that's coming up in my mind, if you were to use Falko, is what you're doing is effectively of changing defaults. Well, you're changing default behavior of Kubernetes in as much as a container that would run on a foot Kubernetes without Falko will not run in the way you expect. Sorry, not Falko. The question is how do we fold, fold kind of enforced policy information like this that would either modify or prevent a pod from running with an application. If a container requires capabilities, then you know, thinks it requires capabilities, expects capabilities, then Kivano will either prevent it from running or make it run in a way that it's not expecting. So the question is how do we follow fold. Is there an application that does not expect that to be working. Are we saying, for instance, that we insist that Kivano is installed with a set of policies on any pod that you use for network functions. Yeah, so this one. Yes. So basically, this policy that drop all. That's going to initially drop all the capabilities and only add the capabilities based on your application requirements. That way, you know, the way we are explicitly mentioning the capabilities that we only need but before that we need to drop all the capabilities. I mean another example of a similar thing that Kivano seems to want to offer is for instance, preventing anything from accessing the host name space, which to my mind is a very good idea. Because if I allow a pod to access the host name space, I'm basically giving it a power to destroy the cluster or alternatively escalate its privilege in the sense of, you know, find out what else is going on the cluster modify the cluster, change the cluster's behavior in a way that means that the infrastructure is not independent of that application. It might break because of this application. So policies like that potentially a good idea. And however, if you are going to say that you should use Kivano on every cluster to ensure this happens or even, you know, Kivano is an option to use on a cluster, then it comes with consequences because an application may, you know, there are three actors here. There's the people providing the infrastructure, the people providing the application and the operators. If the infrastructure prevents things that the application delivers did not expect, then, you know, the operator is going to find when they bring the two things together, the application doesn't work. So you might argue that another way of phrasing this would be to say, you shall not use this and then a best practice would be use Kivano to enforce that. So the Kivano part should be separated. So that there's, if you're, we can have a suggestion recommended, you should drop all capabilities. And then we were checking for that. And as far as someone that says, hey, we want to have as much as these as possible, then we could say, oh, you did great. And then for those who say, no, you must it's required. We will not let you similar to non root. So on some platforms, they don't allow root. SC Linux platforms, you can't run as root. So a service provider could say, no, we will not allow it. And we're going to have denied by default. And for those, they could require that. But I would say the requirement to drop all capabilities. It could be, it could be a completely separate like requirement from, I guess it's a, it's a, it's a different decision to say it's a must versus a recommended. And a different one again to basically modify the containers that think they're going to get privileges to enforce that they're not as well. You know, checking that they do drop privileges one thing, adding the drop command is a separate thing. So there's, there's also a, or reject them. You just don't allow it to deploy. There's also another thing to consider as well. So the drop all capabilities, even if you don't end up enforcing it and saying it's a must, you are able to say that if, if drop all capabilities fails, as in you decide that you don't want to run the drop all capabilities, but you still see that the test itself that determines whether capabilities are present fails, then that could trigger and not it. And that you con that gives you a, an inventory of everything that doesn't meet your, your best practice. And you may have exceptions as to why you don't end up dropping all capabilities. And some of those exceptions may never be resolved, but at the very minimum, it gives you an abley of where you're, of where some of your, your risk is at. So it's not just everything like, don't run it if it doesn't fail or if it doesn't pass, it could be just audited if it doesn't pass. Right. I think. So these, all these policies, right, they can be run in two modes, either enforce or audit mode. So you can, let's say you don't want to run it again. So workloads, you can basically run it in audit mode. That way it will just generate a policy report saying that, hey, this particular resource violated this policy and here are the details, but that workload will still be able to run it. So that should not really block you from running your applications. Hmm. Yeah. Can we, can we go back to maybe start building some potential ideas based on this? Like we, we put out best practices. Yeah. I think that we have to differentiate between best practices and what is enforced. These are two completely different things. And I asked, and I agree with the iron that in that, that, that there are, that we can break applications, but, and it's not a good idea. We have to, but as a best practice, it is the best practice to drop all capabilities. It is, it is, but it is the best thing to do, but you have application, which must have those capabilities. So with either. Yeah, I think all I would say is that. What we're doing here right now is probably rules which are defined by their exceptions. So the auditing possibility here that this is fishy and you need to understand why this is happening is probably more useful to us than you ain't going to do this. And we're going to stop you. I would love one day for there to be a platform where in fact you can't have capabilities. It's simply not possible, but the problem with a platform like that right now is given there aren't very many options for running CNFs, then I don't think you get a CNF to run on it because they're all going to want to privilege for some reason. So the auditing possibility seems like the more useful one. Yeah, the in general, when you model trust in this area, the entire goal for this type of an auditing path is to determine do I trust this thing and per and how do I trust it. And so generally you want to, we don't have enough information here to be able to tell what the context is, whether I'm given things should or should not have privileges. So instead we have to enable the operators to be able to tell whether to have the conversations as to whether they should trust something or not. The second part of on it is time based because things change over time. So how long do I want to trust? Do I want to trust something for? There's a there's a third aspect of trust, which is whether it's symmetrical or what stress is not symmetrical, but that's we'll leave that part out. So just based on the first two, what generally from an audit perspective, what we want to be able to say is this thing will run and we'll give it an exception for a period of time. It's best practice to re-review the, the capabilities on a regular basis. And you continue to understand your, your infrastructure. And you could also make different decisions where maybe there's an update and you don't need these privileges anymore than you can drop them. So, so I would add a time based component to any, to any audit in this particular path if, or to any exception to this path. Well, the other thing that I was thinking, and also regarding what Fred said, is where are the, well, Taylor mentioned about different implementations. So if those implementation can allow us to treat those exception as, as Fred mentioned, or they need to modify the way to handle those exceptions or. So I think that we have to be also connected with the current implementation. You talk about Q and no Falco. So can we do those things there? Or we have to request changes or. Where would the changes be? Well, I would just think. Are you saying in the projects? No, yeah, in the projects. Absolutely. I mean, if ideally we have a two way conversation going between. Or multi way. So between projects and the working group between projects and the test suite, which is trying to test those practices. We want to have a two way conversation and, and improve the projects. As well as improve the best practices and the test happening. And then of course we, we also want the same with people creating. C&S or consuming them, the service providers. It sounded like there was a proposal for a. For something around. Using having policies of some type and there's different policy engines. So having policies. And creating. And having them run and do checks on a regular basis. And I don't know exactly what we would say on that. Because you could say they run. Policy checks run on every deployment policy checks run. But you know, what happens is someone pulls in updates. And it doesn't end. Inline updates. So do you want to check every hour? Do you want to check every day. And have alerts or are you just running a report and sending a report once a week? So there's a lot of different ways to do it. But it seems like we could potentially write something up. I don't even know if this is would become a best practice. It might become like more of a. Just another document, a white paper document that we could. So we don't just have to create. We can create these best practices that we're doing. Like this. We have user stories that we're doing. And we could also have other documents where we talk about. You should do audits and regular checks and policy stuff. We could have a paper written up just about policies. Are there any other practices that we want to write out? And we can take them straight out of this or someone has some other ideas. Taylor, you remember I had to, I had. We discussed to shortly to ideas regarding the network. Best practices around the protection of the. Kubernetes control plane. I don't know if we should talk. Discuss this. Here or what are they? Let's just add them in. Yeah. So, um, There were, or you can put them in this. You can drop them right here in the. Yeah. So I will try to do it in parallel, but, but to, you know, to put you into the discussion. The idea was, well, we have two basic network. Protection concepts, wherever basic concepts around the, the control plane of Kubernetes. One is the API server protection. Making sure that the API servers only. I'm answering authenticated users. And the doesn't enable insecure port and stuff like that. What is the control? There is no. There is not one yet. I have to insecure. Wait a second. I have to look at it later. We'll go ahead. I'll just type it in. Whatever just the words, just use English words and we'll do it. Okay. So first of all, API server protection, making sure that. Authent only authenticated users get answers from the API server. This is one thing. Which, which also in which we all usually include also. The enforcement of our, our back. Which we can discuss whether it is really how deep it is related or not. But from what from our perspective, it is important to enforce that the greatest cluster uses our back. And anonymous user is that it doesn't have any access rights. And the second is actually is not is, is, you know, I'm using public internet text less from, from, from API server. So, you know, from the public internet, you cannot access. The API server itself. Which are with the same thing that this is our two bay very, very basic. The Kubernetes API server. Yeah. So, again, this is in the sense of telcos it isn't a, I think that it's less on issue. Okay. But still, I think that this is something as a best practice. It's something that, you know, should be there and should be clear to everyone. And also, okay, we, we, we suggested also to make sure that every one of us is, you know, where it is control playing components, like, you know, cubelets and, and scheduler and control manager and stuff like each talking to each other in TLS with, with bilateral authentication. Which authentication TLS with what? Mutual TLS. Oh. So that these are really the, the one on one of the network security around the Kubernetes components. And these should be enforced. I will, I will follow up and I will add, okay, the controls. We are adding right now also to make sure that these are covered in our test kit, but this is as again, this is the best practice. So, for example, a public access to, to cover this API server is not necessarily something okay that can be easily tested. Since, you know, how do you prove that you don't have public access. You cannot cover, cover this, you know, 100%. Yeah, these were the things which, which I thought would be, you know, good things to, to best for best practices. I actually think that some of those might be related to stuff that we had listed for lease privilege. Yeah. Select the API access. That's similar. It's not exact, but that's similar. So that's good. Continue on that. Security controls. Yeah. I feel like there was something about our back. I'm not seeing it now, but maybe it was in the actual notes. Yeah. Here we go. Look at this. So we have been, we have this whole section here in these working notes on our back roles and authentication and a pretty, pretty decent right up in several sections about this. So this would be content that could be pulled for something like around our back. We get, there's a lot of things on our back. So we can, the more specific we get on something, you know, potentially the easier it is, but whatever, whatever it is, I think we got a lot of content on our back. And likewise. So we have, I think on these like drop all capabilities. If I look up. These will number one, we have like exceptions and stuff, which Ian was talking about. Like when, what do we do with all the applications that need it right now? This no privilege or capabilities granted. So this is kind of related to that, what you're suggesting. It's pretty much the same, but it's definitely something we've thought would be good. And I think there's probably other content here besides the supply chain attacks. So if you can, you probably take this non-route as a good example. There's also. Like, literally like, here's, here's the template that anyone can use that explains what it's about. Actually, here's the template. And this says, what's the process? What do we want? But here's the template. And, and this. Yeah, I'm sorry. I was saying, if you could share that link for the template. Yeah, sure. I'll just drop these all in here. So. Example are creating. Creating a new best practice proposal. So example, non-route. So we have a template. Yeah, let me grab that. So probably. User story. Example. Supply chain attacks. The, all of these can be adjusted to. As needed when we created this, it was without before having an example. So. We have this section, user stories, use cases, it can be whatever makes sense. The, the main point here is. I'm not seeing it. There we go. To give context to the end user. Okay. Why is this relevant? This best practice relevancy. But if, if you are giving relevance in another way, that's okay. It's not relevant. It's not relevant. It's not relevant. It's not relevant. These are just. To help guide us, but it's not. Strictly required. There's some of the things that we've marked as required. And if you feel like it's not relevant, then come back. Same thing, Ben, on anything that you all come up with here. It's not relevant and then just come back. It's we're trying to, we're trying to give recommendations with enough content that it's not relevant. So let me adopt that. Across, across our company. We think it's a great idea. Yeah. All right. Is there any other ideas for potential practices that anyone wants to, and it doesn't have to be, or some of these are, I would say more security oriented. So we don't have to just do that. But any, any ideas, whether it's more security or other stuff. I think it's a really good one. For people. There was one more. Which, which requires read only root file system. I don't know if that's already part of the CNCF. Yes. We require that potentially. I don't know on the test suite side, there's a lot of different things there, but what is it if we're talking about it from a best practice standpoint? Yeah. This policy ensures that, you know, there is only, you only have a read only root file system. All right. Yeah, this is, I think there's agreement between many different projects. And it's probably a good indication that it's a best practice. Use read only root file systems. Right. The others as well, but. I think you'll have something about read only. FACA has read only there. So if we have, you know, a lot of different projects that are focused on Kubernetes and cloud native and everyone is saying you should have, you know, you know, you know, you should have read those as well, but. Let me pull those one second. So Taylor, can you go back to that? No. Website. In the best practice. Yeah. These are. Checking the deprecated API is one of them. Ben, would you. Add a link under this. Cubescape area to. Set. Yep. And you could put it right here and then people can go check those out. Sure. Okay. I will do. Thanks. So. Check for deprecated APIs. I know that there's several. Projects for this too. There's been. There's one project that's actually used. With the SIG testing for checking. Test coverage for all Kubernetes APIs. And it can tell you whether it's. Alpha beta or production. I'm not sure if it checks for. Deprecated APIs, but that's great that. Kaverna can do that. So check for deprecated APIs. I think that would definitely be one from an audit standpoint for service providers. They'd get noted if an application is using that. So that they'd be warned from an ops team perspective. Before they upgrade their platform. What applications are going to break. And what may have more bugs potentially, I guess. Yeah, so. So Taylor, I, I think one more thing was I was working on. Integrating those policies, right? I have made some progress on that. Especially, you know, formatting the output. I think with the help of a caution. Now it's more formatted. So I'll update my policies accordingly. And probably. Show like a demo sometime this Thursday. Okay. Does anyone have anything else. So even if you're dropping capabilities, it's still a good idea to, to not use root. There's other issues besides capabilities that come in. Yeah, that's all we're going to keep it separate best practice. Drop capabilities. Don't set your container privilege to true. Don't use root. We just keep piling them on. So the more you use the safer you're going to be. Perfect. And someone may decide to only use a sub set. That's fine. As long as we can tell. What are you, what are you doing? Any other best practices. That in the mention. In the fourth one, not just often only authenticated users, but also and, and services, because not every, not everything that connects to Kubernetes API is a user. So I guess we can map them to the user. So we may not make too much sense, but. One more word we basically restricting the image registries that you typically pull your images from. Sorry, can you say that again? The strict image registries. Let me bring you the link on second. That you can get this from, which is a perfectly good way of ensuring supply chain security. So, or assisting on it. Yeah, I just think in the chat. Yeah, the point is to limit from rich image registry. You can pull to the pods. Probably argue against this one. I want public and secure. But that has to do with signing and other stuff. Yeah, it depends on Taylor. It certainly depends on how you play this game. But on the other hand, if we put it forward though. Yeah. Yeah. Signing, signing may not be enough in some, in some use cases. Absolutely. And so, for example, I may, we may end up with a, with a signed. Root image or let's say like, you pick a database and I won't give a specific database name, but let's say you have like some database that you use and that database sort of be compromised and an image uploaded, then you start pulling from that specific one rather than the ones that you bet. So generally, what is it happening is that the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the additional scans that are put onto the private repo and the organization may want to ensure that those scans are performed before they deploy anything. So they won't want to pull from public for, for that specific reason, even if they're not modifying the images themselves. Yeah. I think it's questionable how well it's any more secure than basically signing things as trusted because you've done the scan. You've done the scan. You've done the scan. Having a trusted testing place that signs after testing, scanning and testing. But anyways, we're getting into how would you design all of this and restrict image registries is definitely a, a way of helping to secure. Different paths. So any others. That someone was put forward. And if you think of something later, you can feel free to come in and add it to the notes. Or go into another good place to add it later. Would be put a discussion item. If it's related to something here, feel free to add it or just create a new discussion area. And then we can talk about it, you know, a following week. If you really think this is a really good one, we definitely should do this. Then please go add an issue. So we have, we actually have one about privilege flag. The Ian added quite a while ago. Don't use privilege. So this is one that we could, the privilege flag specifically. So that, that capabilities one, the very first one. Might be something that we already agree. You should drop capabilities. So go ahead and create an issue that we should propose as a best practice. And then you can start iterating on it with a draft. That you can share and we can all work towards creating. And then we create a pull request. We'll be good to go. So with that, Ian, why don't you go ahead and open the pull request. We'll move on. We're nearly at the top tower. Open what pull request exactly. Oh, review the open pull request. Yes. Okay. Well, there is in fact, only one, which is the one that we've had open for a while to create air gap environments. Oh, well, sorry. The pull request is called create a cat environment. But yes, to, to discuss the best practice of using an air gap environment and the implications that it has. I don't think there's much worth discussing on this meeting. And in any case, I don't think in six minutes, we would get very far. But, and it looks like we've got a few open bits of commentary that haven't been addressed in the pull request at this point in time. But I think I would just simply suggest that people have a read of it if they didn't know it existed, or if they haven't looked already to get a sense of where it's going and just so that they can add their own comments on it. So this is user stories, which potentially could be referenced by any of the best practices that we've been talking about or other best practices later. Yeah, I mean, I think what Jeff, I'm not, I'm just skimming this, I have to admit, I'm a bit lax on this, I haven't done my own review, but I'm just skimming this. And I think his, his storytelling needs a bit of work. But the idea is that we know in many, if not all service providers that when they're doing network functions of whatever kind of software, they don't just pull it from the internet. And they certainly don't pull it on the internet from the end device. They basically distribute it within their network, which is a closed system that they only allow new software images to enter under limited circumstances. And that was the point that Jeff was trying to get across. But yes, anyway, this one's open. It's up for review as we speak. So anyone who's got the time to basically read through it and see whether it makes any sense to them, that would be useful. And we, again, are right at the top of the hour, give or take. So unless there's anything particularly urgent that people want to talk to, talk about for three minutes, then I think we might be done for the morning. Spelling, grammar, any type of updates are appreciated. If it makes it more readable, if you say a word that you think needs a definition, put it in, whatever, any of that will help. Yeah, absolutely. Don't feel that you can propose a change in GitHub. And I strongly suggest you do. If you are doing comments, then, you know, simply putting the change you would like to see is often for small changes a lot easier than basically telling someone else that they've got work to do. So, you know, do make sure you do that. Can you demonstrate, Taylor? Yeah, that's it. We'll do so. Yeah. So this little insert suggestion, and then I can say air gap places. And then if I put that as my suggestion, it shows up like this and then someone can click commit suggestions if they like it. It makes it really easy for folks to move along and quickly take stuff that's been put in there. We can have fast iterations of changes. So please use those. And if you're not using them in your own, then I suggest you do so with your pull request. And if you mess up, you can always delete and try again. Like I just did. All right. I think we're at the end. Unless anyone that's muted needs something has anything else. All right, and I think we did it. Okay. Thank you, everybody. And we will see you all next week. Okay, guys. Thanks everyone. See you. Take care.