 All right, it's about five pass just a final call if Brian Cantrell, John Bulls, Sam Lambert, or Quinton are here All right Alexis feel free to steer but fairly crisp agenda today with a presentation You there Alexis? Do we lose you? Are you mute? Is it only me or I can't hear Alexis? Okay, where did you go hit Chris? Yeah, he'll come back on All right, so If we go to Slide five and six kind of agenda is fairly brief today. We have a presentation community presentation from the Falco Project we have some discussions around the community backlog of upcoming project proposals And requested due diligence from the community and then we kind of have an open Q&A session So slide six Really an important call from community kind of review the upcoming Project proposals that we have as a reminder Open metrics and Harbor are both going to be entering the sandbox soon Cortex is looking for an additional TOC sponsor So if you're interested in sponsoring that project, please Reach out to them or want to provide them any due diligence go for it on that issue terms of backlog We have a variety of projects that will be presented to the TOC Soon so feel free to look and Go through any of those links of those projects interest you Slide seven up. Go ahead. Someone's gonna say something. Hey, I was just saying that I'm back now. Sorry I had to go and get my Cable for my machine. I apologize. Thanks for taking over Chris. Yeah, no worries I pretty much have dropped you off on the due diligence slide. So if there's any particular Calls to action you want to make go for it. I just want to mention Cortex, you know, we've got Ken is stepping out to sponsor. I think the delay there is that Brian Cantrell is talking to the Cortex community He wants to do some, you know, personal ED on on on what they think and do that's talking to fresh tracks Rafauna We've worked and electronic arts in particular and Hopefully that will lead to a good conclusion but if anyone else wants to Have a look. Please. Please get in touch with me or directly with Bob Carton from fresh tracks, please I'll put you in touch Okay, so Falco time, I believe Do we have Loris and Ducey on the call? Yep, we're both on. Yes Okay, this is the floor is yours. You've got about 15 minutes, please, but I'm assuming some questions afterwards Okay, sounds good. And we can do a demo if you want as well if we have enough time So let's go ahead and jump to slide number eight. So what is Falco? So Falco is an open source project It's been around since about 2016 It's basically what it's for is abnormal behavior detection for Linux based containers hosts and orchestration platforms The industry has kind of settled on a term called runtime security And we're seeing more and more Competitors and other projects using this term runtime security So it has a filter language and this filter language can easily detect events such as shells being spawned inside of a container Unexpected outbound connections Processing listening on ports that you shouldn't be listening on or it shouldn't be listening on or a particular container image listening on ports that it shouldn't be listening on files or binaries changing after container start and so forth And where we see the real value is in detecting these events But then having these automated actions that can be taken when abnormal events are detected So slide nine kind of frames up why you need it So the cloud native paradigm really gives you a lot of choice around packaging decisions being pushed to development teams kind of what the industry has settled on is Using image scanning to basically Make sure that whatever artifacts are being pulled into a container image that we know the provenance of those artifacts But then also are those artifacts have containing some known security vulnerability or something like that And the challenge with that while that's useful The challenge with it is is that it's point in time security So when the scan is done during the container build process, we blessed it. We know that it's a known good container But once that container starts running the runtime environment often isn't immutable so developers can have scripts that run that make changes Or for instance, you know kind of Even something that wouldn't be malicious all of a sudden a developer has a new api endpoint from a third party that it's calling out to That we didn't necessarily know that it would be making that outbound connection to it can connect It can catch, you know stuff like that as well Um, there's also resource isolation paradigms, uh, as well And we need to be able to detect those breakdowns in isolation Falco is kind of part of a multi layered approach to security that we're finding that to become more and more common In the container orchestrator cloud native world And we think that having multiple layers to detect these types of abnormal behaviors are really important Uh, as I said before we can connect. We can detect a variety of different things from container isolation being broken So a vulnerability in a container runtime or linux kernel allowing you to break isolation applications being exploited and running things like bitcoin miners or getting access into the broader environment as well and then orchestration systems being Exploited through things like exposed dashboards exposed api ports and so forth And what falco will allow you to do is is help you enforce these best practices But also will help you enforce compliance requirements around things like cis pcis socks our favorite now gdpr And also your organizational security best practices So on slide 10, uh, a little bit of how falco works Uh, so there's a kernel module. Uh, we're going to be releasing evpf support Very shortly. That's an alpha right now, but we hope to have it vetted By the end of august and have it released out And what this basically does is it taps into the system calls From the kernel and that stream of system calls basically goes up into processing libraries And that's where the filter engine or the expression engine picks up those events And will then route any suspicious Suspicious events over to the alerting engine And that alerting engine right now is pretty basic, but it can alert to a variety of different destinations such as syslog a normal file standard out or calling Programs via a shell One of the integrations that we did that i'll talk about here in a second is where we were actually integrating in with gnats and having the alerts sent over to a gnats messaging server and then Actors can subscribe to those messages and take take actions Based upon those events Uh a little bit of uh information about the projects the metrics around the project on slide 11 Uh, just wait for people to jump to slide 11. Uh, as I said, it was started in the spring of 2016 We've had about 34 uh 100 down or sorry 34 000 downloads of the rpms themselves Uh, and over 900 000 docker hub polls Uh, we're at about 831 github stars at least when I uh Took this snapshot of these numbers We have about three maintainers. They're all from sysdig right now, and we have about 16 contributors as well We have a fairly active slack channel and from a user-based perspective cloud.gov is probably Our our number one user right now that at least has talked about what they're doing with falco And there's a few links there in the presentation The interesting thing about cloud.gov is they're using cloud foundry And what they did is they basically have the ability to detect an application that's tainted In cloud foundry and then they wrote a little go program called gardener that goes and talks to garden The container runtime engine for cloud foundry and it will delete an application that's been deemed as tainted You can see a little bit about the growth as well and the number of monthly downloads We're seeing lots of good momentum as you can see over the last several months We've maintained about 2,700 downloads per month and the docker hub polls are are trending about 250 to 200 polls per hour. So that's anywhere from 30 000 to 40 000 a week That we're seeing as far as downloads are concerned for the falco docker image Uh, we integrate in with a number. So slide 12 We integrate in with a variety of different projects. So kubernetes rocket container d and point b Indian cncf space, uh, we also integrate in with tools like our own open source tool cystig mesos and marathon as well as cloud foundry as well We ship with 25 rules around container best practices out of the box And you can kind of see an example there and one of the blog posts were wrote around collecting security events from kubernetes and those pushing those back into an efk stack And allowing you to build kind of a sim dashboard that shows you where and your environment rules might be triggering and firing We also recently shipped a bunch of default rules for common applications as well. So things like engine x patchy Uh, etcd kubernetes gke and so forth, uh, as well and those are available of on our github repository So slide 13 Gives us a little bit of an example of what you can actually do with falco This is a little bit of a proof of concept that we created. Uh, this is where falco So when you deploy falco to kubernetes, you run it as a daemon set. So, uh, falco will run on all of your worker nodes And then it will detect any abnormal behavior not only inside of the containers, but also on the node itself as well So we see this is very valuable. So when falco detects one of these behaviors that is deemed as abnormal We'll publish into a gnats topic Then we have kubernetes, which will actually go and pick up those alerts or will be triggered By those messages being published to gnats And that gives us a lot of functionality as far as what we can do as far as actions are concerned So we can send notifications. We could log that Alert as well, but then we can also execute actions and some of the actions that we've shipped Which are available in the falco github repository are things like killing the offending pod Marketing node is tainted so that new workloads can't get scheduled on it But the node is still around so that you can do forensics on it Um, uh, doing things like network isolation, uh, as well And then we also have some generic notification ones that we pushed as well Kubless is just one of the ones that we, uh, decided to work with one of the functions as a service frameworks That we decided to work with. Uh, this would of course be applicable to any functions as a service Framework that you wanted to use Uh, slide 14, uh, I'll hand it over to loris Uh, yes, a little bit of, uh, landscape, uh, in which, uh, falco operates these lights As to columns one is, uh, open source comparable tools and the other one is proprietary As you can see, uh, in open source, I mean, uh, of course, you know, security, uh, is A big landscape with many pieces that, uh, typically work together. So, uh, here we list some Of the projects that, uh, are sort of, you know, complementary Or cover maybe other aspects of, uh, Cloud native security, uh, like anchor, claire, inspect, selium, notary, tough, spiffy, vault, and so on But in practice, as far as we know, um, What, uh, Dusksy before described as runtime security, we believe that falco at least, you know, in the In the cloud native environment is, is pretty unique as a tool In the other column, we have proprietary tools and they are, uh, we are listing some Of the commercial vendors, uh, that, uh, offer, uh, solutions, uh, for runtime security In particular, the first one is sysdig secure, which is, uh, a product by our company sysdig And, uh, which actually, uh, leverages, uh, the falco rules engine, uh, to offer, uh, its functionality So our approach there is, uh, just, you know, build, uh, a Layer on top of what we offer, uh, completers open source, uh, as falco and Potentially make it possible for other entities, uh, Open source projects and company to, to do the same, uh, other tools are aqua security, twist locks, Stack rocks, new vector, again, these are, uh, examples, there, there is more, but this, This should give a pretty good idea Slide 15 is a little bit of, uh, uh, forward-looking So, um, uh, Dusksy showed the, uh, architectural diagram of, uh, falco before These slides, uh, has, uh, a few blue, uh, boxes, which is, uh, what we want to add, first of all, In terms of, uh, collection, as we're saying, currently falco essentially consumes System call from, uh, our kernel module or, uh, in, in the near future ebpf, uh, Scripps, uh, we want, uh, to enrich the input for the tool, uh, and, uh, increase the data, The data that is fed to the, uh, expression engine and to the rules, so that, uh, there's More context, especially more context from, uh, again, uh, CNCF projects, maybe, or, or in any case, Projects in the ecosystem that can provide input to, to the rule engine. And in terms of output, We're constantly working on, uh, making, uh, falco more integrated in terms of output With, uh, any other tool, and in particular, two, uh, output integrations that we have, uh, In our roadmap, for example, our NATS and, and, uh, webbook, so that, again, other tool can consume, Uh, the output of our rule engine. Uh, slide 16 is a bit of a roadmap. This slide is pretty Dance. Of course, I won't have time to go through, uh, each of the entries in these slides, But, uh, let's say from the short term, uh, a bunch of work, uh, that, uh, will be done, Or has already been done, as you can see, there's quite a bit of shift, uh, in terms of, uh, Both, uh, deployment of falco, so making it, uh, uh, more seamless, uh, and better integrated With both, uh, let's say the operating system, uh, in this case Linux and, uh, the, uh, orchestrators That can run it as a container, uh, rules library, uh, again, a bunch of, uh, rules that, uh, We and all the community are working on, um, for example, you know, stuff like, uh, Applications like NGNX or HAProxy, but also CNCF projects, uh, like Kubernetes and Prometheus, And FluentD and so on. So the ability essentially to create profiles for these, uh, projects, So when, when you deploy falco, uh, as a component, for example, in Kubernetes, there's, uh, a bunch Of, uh, functionality and rules in falco that can harden, uh, out of the box, uh, Kubernetes and, and all of the components of the Kubernetes ecosystem. And also, A bunch of rules for CIS compliance. Longer term, uh, Kubernetes integration is definitely on our radar. For example, the first bullet in network policies is one, uh, that we think is particularly useful Because it will allow to evaluate Kubernetes network policies without necessarily, uh, Have at least at the initial point to enforce them. Uh, alert output, uh, I mentioned that in the previous slides, uh, more data, I mentioned it in previous slides and one that, uh, I'm personally pretty excited about is, uh, Baselining. So the ability for falco to do its detection and its enforcement, uh, automatically By learning essentially the environment versus, uh, having, uh, to, uh, be configured with manual rules. Slide 17, uh, is, uh, about licensing. So currently, uh, falco is GPL v2 mostly for historical reasons because, uh, uh, part of the stack is a kernel module, uh, which typically Requires to be, um, uh, released as a GPL v2. So as a consequence, we initially, uh, like for CIS, uh, released our stack as GPL v2. We understand that these, uh, can, uh, create Concerns. Our plan going forward would be, uh, moving, uh, keeping, uh, the kernel part as GPL, uh, v2 because, or at least with the dual license, because we cannot avoid it essentially if we Wanted to run in the Linux kernel, but, uh, move the open source part, uh, move, sorry, The user level part and the libraries and the engine, uh, to something that is, uh, uh, Compatible with the CNCF and in particular to the Apache license v2. Slide 18, I'm going to hand it back to Ducey. Thanks. Um, so what we're looking for, uh, is really in two different areas. So technical Collaboration, um, I think it's really important, uh, especially in the open source world that We start talking more about security. Uh, I know some people in the industry, uh, such as Just, uh, has done a lot of work in this area. Um, but I think we get more feedback, uh, from Other people of as to what we need to be building, uh, in this project would be very helpful. Uh, we do need help with the project governance process, which is something that we think That the CNCF can help with a lot. Uh, integrations for event consumption and Notifications. Uh, and of course we still need, uh, talk sponsors to enter the CNCF Sandbox, uh, as well. Uh, and then as well as some industry insights. So guidance on road map and Future integrations and guidance on the security paradigms that we can help solve, uh, as well. Uh, and I did notice that Brett from cloud.gov has joined, uh, as well. So if anyone has any Questions, uh, about actual usage, uh, Brett might be able to provide a little bit of perspective. Sorry, I'm late folks. I, uh, West coast. I, I overslept an alarm here. Hey, I'll, I'll say briefly if people don't have questions with cloud.gov. We have a Multi-Tent, um, cloud Foundry based installation that we use for the government, um, compliance As a service is sort of the main reason we exist. Um, a lot of the compliance and federal Government requires people to understand when their code is compromised and, um, and what they're going to do about it. And although it's a great platform in every other way, our customers are kind of, you know, they're running their stuff in containers. They don't have a lot of ability to monitor their own stuff. So we can say it's a customer responsibility to do this, but there's no real technical way for them to accomplish that. And as soon as we started looking at, at Falco, that became the avenue for us to provide this for our customers and everybody kind of read the big sigh of relief. So, uh, we try and be open source in everything we do and we were not finding a lot of other good solutions for doing this. This is the first one that we came across. We, um, give a presentation to Cloud Foundry Summit about what we did with it. Um, but it, it kind of was ready made for, for this use case of, uh, you know, multi tenant container based environment where our, our customers needed to have some sort of notion of integrity of the, of what was actually running in the container. You could do chain of custody on the code and the image and so on. But once it comes to, okay, what about after it's running? There wasn't a lot that they could do. Um, but as his platform operators, we had to handle the handle it and the only real thing that we found out there that was open source that we could use was Falco. So with that, I'll take any questions anybody has about it. How composable are the rule sets? Taking a look at the example that was linked from the slides, there was a big monolithic file that was 1600 lines long with rules for lots of different applications like Cassandra and ActiveMQ and Elasticsearch and MySQL. I would, that seems to significantly reduce the value of a container platform to be able to sort of run arbitrary applications anywhere. So I would think that we would need some sort of mechanism for composition that an application could bring its own rule set with it. Yeah. Is that possible today? Yeah. The first step that we, uh, have done to make that possible is just create a rules.d directory. And so any rules that are put in the rules.d directory will be loaded up in parts by Falco. And so that's definitely the first step to allow applications to kind of bring their own rules. We think that there could probably be better ways to do it, but this is one of the reasons why we're having the conversation, right? So that we can learn and understand what direction we need to take the project. Something like that would need to be a part of like the image specification though, because at that point you want to ship it with the container image itself. So like that should be something that should be pushed upstream towards OCI than being like its own kind of separate thing. I was actually thinking of something like a Grafius to attach additional metadata associated with the image. Yeah, exactly. Both ways would be great ways essentially. Exactly. I mean our ideal motion with Falco is as, you know, it really gets adopted for in time security at the point these hooking points are much better than the YAML file that we currently have and make it, of course, way more powerful because especially, yeah, something like a Grafius where you can do it in the more like, you know, organized and centralized way or the container image at the point empower the use of this in a much more distributed and automated way, right, as a base engine underneath essentially your running containers. Yeah, but like Grafius or whatever, like that's not a standard, like that's kind of like, it's, you know, Google's project. So what I was saying was like something like a rules for security needs to be a standard that's pushed upstream through OCI so that everyone can use it and not just people who are using like Grafius on Google Cloud or whatever. Yeah. I think a challenge with that is that the tool ecosystem is not going to just be one or two things. People need to be able to build new kinds of tools and have those get deployed. So we need some kind of mechanism for composition of new specifications and new tools that doesn't require just going through a centralized body. And maybe this specific thing might make sense, but then, you know, there will be 10 other things that don't make sense. Yeah, but Jess makes a good point about having it at the OCI layer because at that point, it's a little bit more controlled and out of the developer's whim, whether those rules get included or not. And it's a little bit more active enforcement than hoping that they've attached the right Grafius. Well, administrators could also have policies that says that no containers can run that don't include such rules. Yes, possibly. Yeah. And by the way, from this point of view, you're right, the YAML file, the currently YAML approach of Falco is not the best way to approach this, but at the same time, the engine and the language, these are just essentially a generic domain language that is based on system call and the pretty simple syntax. And from this point of view, of course, our goal from the beginning was just mostly offering something to describe based on the unit that we think is pretty close to what at the system level, a process or a container does, which is system calls, and is completely open and already used by other tools like Open Source Sysdig and by several other tools. And just being able to express essentially process and container behavior based on that. And at the point that can be used by people as a form of description that can also be orthogonal to our engine, could also be enforced in other ways. For example, I don't know, at the network layer through one of the network or firewall systems that are part of the CNC-effico system. Thanks. What other questions can we answer for you? Do we need to do a demo or...? I think there's a question on roles being based on things other than system calls. So kind of like we're adding the step in August and network policy potentially in the next couple of months, etc. Is the plan to extend the roles definition to have things that are not just system calls? Go ahead, Lord. Yeah, this was part of one of the slides. So the answer is yes, and it's already part of our roadmap. I was wondering if the network policy piece that you mentioned and all that was, okay, thank you. Exactly. Network policy is a very good example, but I don't know, other examples are for example Kubernetes events that can be used as a source for this and many other things that we have in mind. In a general way, again, this is a general approach and architecture is open to new sources of input and we're working on adding them. Yeah, and right now you can actually pull back Kubernetes metadata as well as Mesos and Marathon metadata as well to say apply rules to certain namespaces or pods or particular deployments inside of Kubernetes. So we do have that functionality to be able to talk to other APIs and pull back that metadata and enhance the rule set that way. And I have a more philosophical question, which is, do you plan to add more security-based things or general monitoring-based things going forward? Where do you see yourself fit in which category? So with FALCO specifically, our current use case is more like security and monitoring behaviors from the security point of view. This doesn't mean that FALCO potential is not useful for more like vanilla monitoring as well, but honestly, currently we are focusing more on the security use case with this tool. What other questions can we answer for anyone? How does FALCO compare to Open Policy Agent? Is that something that you've looked at or that you've thought about? Uh, it's not something that we've looked at. Uh, Loris might have. I know personally, I haven't. Loris, do you have anything? No, I'm not familiar. Okay. I suggest taking a look at OpenPolicyAgent.org. And one difference in the way it is supplied is that OPA, at least in in many cases, is invoked synchronously to do authorization checks effectively with pretty arbitrary policies, whereas FALCO looks like an asynchronous detection mechanism. So they seem complementary, but maybe some of the rules might be similar. Yeah, we definitely need to take a look. Yeah, Brian, I think that they are complementary. We, you know, OPA doesn't have a Linux kernel hooks, you know, to, you know, sit in line with syscalls. Sure. That aspect I get is unique, but as they talk about applying FALCO to other input sources, then that's where essentially there are some potentially some overlapping use cases. I guess events, Kubernetes events are another case where you wouldn't inject it into the authorizing whether the event exists or not. It would be a detection mechanism. But yeah, I was just thinking about whether the rules languages could end up looking similar, which would be convenient for operators who want to use both. Yeah. Right. I think we're done on questions. Are we at the point where any suitably credentialed TOC members would like to sponsor this into the Sandbox? Would you want to think about it? I'm only into sponsoring. I'll box this. Okay. So do we have a second for that? Yeah, I can do that. It's Quinton. Okay. Great. Chris? Yeah. Duly noted. Thank you. Very good presentation, Duce. Thank you very much also, Luris. Yep. Thanks for having us. Thank you. Thank you guys. Okay. Back to the slides. So this is my chance to ask for input. We have a governing board meeting next week. It's an offsite in San Francisco. And I will be present along with a couple of other TOC members, such as Ben Hindman. I really, really appreciate it if I felt that I was representing the TOC in practice as well as in theory in this particular case. So usually in these meetings, there's an opportunity to share concerns, ask questions of the GB, get direction, and generally sync up on things, level set. So please, please, this is an appeal for your input on things that you would like me to discuss on your behalf at the GB next week. Some of the things that are concerns for me are listed here. So I think that we have an ongoing and probably never-ending theme around making projects happy. We have done a good job of understanding the needs of our projects. The particular projects that I think we can help the most and should pay the closest attention to are the ones which are already quite well known and off some size, but not as humongous as given entities. And so I'm thinking if you're Envoy, Prometheus, and other projects of that sort of scale or heading in that direction, if you know the principles, please ask them. This is a chance to bring things up. Last year, we had a discussion about this talking about Envoy. As an example, and Matt provided some thoughts, do please contribute on this topic if you'd like to. The second area where I would really like to understand what we could do better, where we can ask the GB for help or money is around education and other things that are appealing to developers and other technical people in the industry as users, individual users. What can we do to help them feel more comfortable about Cloud Native? And we're talking here about potentially millions of people. I would be really, really delighted if CNCF were a foundation that could serve the needs of all developers, not a small subset like some other foundations have done. So what can we do to make Cloud Native easier, simpler, and better for people? Another area that's on my mind at the moment is now that we're starting to have end users in the CNCF, I think there's about 65 or 70 sponsoring end user members. What does the TOC want from end users? In the presentation, the SISTIG team specifically called that out as something that they would like to hear about, and I'm sure that's very important to many people. What are the right ways to interact? I mean, obviously, Sam comes in sometimes as the representative of the end users, but we could have a higher bandwidth level of communication, but it starts with identifying areas that we want to talk about. So that's important to me. And then finally, and I think perhaps most important, structure, there's a lot of projects coming into the CNCF, and I think it's time to start thinking about how do we have more shape to what could otherwise be a horizontal set of otherwise identical things? So should we think about grouping projects and having more focused missions around groups of projects, for example, security? Security is a very big theme this year. We've seen Stiffy, and Spire, and Opera, and today we talked about Falco, and there are other things in the security space. Should we be forming groups around security projects, whether they're graduated or incubated, or Sandbox doesn't matter, and having separate teams go out and get together and work on common questions around security, the same thing for observability, continuous delivery, and so on. Not just orchestration, of course. So these are just thoughts I've been having, and I'm also particularly concerned that now that Kubernetes seems to be adopted by a lot of different companies and maybe kind of the de facto orchestrator of choice going forward, are we going to see a proliferation of things that run on top of Kubernetes, and what are we going to do about those things? Are we going to have a thousand different projects that do machine learning, drone control, IoT, serverless, mesh, 15 of each of these things, what are we going to do about that? Because it's going to be quite a mess if we're not careful. So those are the things that are bothering me. I'm sure there are things that are bothering you too, including why doesn't this Alexis guy shut up? So I've created a document which is linked to here for people to put their own ideas down for the GB meeting. You can just click on the link and stick stuff in there, and we can talk about it on the call. We've got 20 minutes left today. If anyone wants to speak out on things that's really, really bothering you that you want to bring up with the GB. You know, one thing I would add to your point about do we need to have, you know, the idea of working groups towards project groups, and then you mentioned security becoming more and more of a topic. I think something that would be really, really helpful is to have a cloud native security landscape and being able to understand what are the stack of open source tools and what layer in the stack do they fit? Are they infrastructure security? Are they runtime security? Are they build security tools? And how how you go and build an open source security stack to make sure that your environment is safe and secure for your end users? Yeah, so you've had a bit of a stack. And that's something we assisted would be more than willing to help help build. Right. I mean, we're starting to see this almost as a pattern now emerging organically from the working groups. The serverless working group did a white paper and they did a landscape and they started working on a common definition of a cloud event, which a couple of people then implemented. And I think that that kind of pattern could be repeated with other areas, security being another. We have already a rich set of projects that cover observability, but we don't have a way of bringing them together. So, you know, it's just implied it's not stated. These are all areas where we could if we wanted to divert attention at work, which might or might not help users and customers and all of those good things. Yeah, I think that serverless serverless work group white paper, I think is a good idea in terms of defining some terminology and sort of specking out specking out the landscape. I think the landscape tool is also can potentially be a counterpart to that to actually, you know, as we create new categorizations to actually get those into the landscape tool so people can search for it. And then something else that probably would be needed is something like a reference architecture so that people can see how those things could all fit together in sort of a cohesive way because the surface area is super complex right now. So, you know, leaving it as an exercise to the readers. Definitely pretty challenging. Yeah. Brian, maybe you could put some bullets into the document. I'm just trying to keep up with what you're saying. Sure. I'll do that in a bit. I had some comments on the other part. But I can let Dan go if you had a point about this topic. Oh, just very briefly, I wanted to mention that we do have an active mailing list right now called cmcf-reference-architecture at list.cmcf.io and maybe Chris or someone could type that into the chat window. But Ken Owens has been orchestrating our efforts on making some revisions to the landscape. And so we'd love to have more folks come in and assist us on looking at the projects we're aware of right now in the security and compliance space and whether a different organization would make more sense or whether there's enough of them that will need to eventually break it out into its own sub-landscape. That's all. Thanks, Dan. Back to you, Brian. Yeah. So speaking, I guess, of different flavors of reference architecture, something that I think would be very helpful from end users would be for them to describe their applications and how, you know, at some level of detail what they actually need functionality-wise and what the topologies actually look like and how they map on to our existing cloud-native projects and where gaps might potentially be. Certainly, that's something I always find very useful when I talk to users is really understanding how they're using what we build. And sometimes it's surprising. And I think that's where end users can provide a lot of value. It's actually, you know, say, well, we're building all this technology. How does it actually get used? Is it actually usable? Are we actually meeting all their needs? Yeah. Good. Thank you. I put that into the slide, but I'm going to put it into the document as well. And then with respect to structure, this has come up in a number of the discussions about potential sandbox projects as well. But figuring out how to organize, you know, we have, Kubernetes obviously has a big and growing ecosystem. And some of the other projects, like Prometheus and Envoy, are starting to grow their own ecosystems as well. It might make sense to just make that explicit and obvious to folks and kind of have, I don't know, solar systems of projects and the things that orbit them as some kind of explicit subgroups within the CNCF. Right. Yeah. I mean, I think the discussion around Cortex highlighted this. You know, the Prometheus team don't have their own sandbox and, you know, Cortex is simultaneously a Kubernetes and a Prometheus sandbox project. So obviously, it can take advantage of the CNCF sandbox, but, you know, we can do that with a few more projects. And then all of a sudden, we'll have further confusion because we won't be able to see the shape of things. So I think your idea is a good one, Brian, on that front. Affiliation. Yeah. It could also encourage our projects to think of themselves more as platforms, which I think would be good in terms of growing, growing a set of composable functionality for users to consume. Yeah. Good. Anyone else want to comment on this? So your silence implies, because of what I said earlier, that you're all happy. Well, I'm going to look at the dock. I'm just walking around right now. So hard to do a good comment. The dock was empty at the start of this discussion. In terms of the app tools, I think that's worthy of a longer discussion. I don't know that there's a way to necessarily, that it's necessarily a problem for lots of different competing solutions to develop. And I'm not sure that it's preventable. If we look at what happens in JavaScript frameworks, for example, there always seems to be yet another new one. I don't know how developers feel about that. I have seen some blog posts about the constant churn of frameworks, but I think there are reasons why that happens. I don't know. You know, I'll say this. So this is Matt Farina here. In Kubernetes SIG apps, we've been talking about app tools lately. And there are a lot of gaps, whether we're talking about debugging things, like how do you debug something while it's running inside of a container, right? And there are a couple of ways. But there's a lot of tools like, how do I test something offline if I'm dealing with serverless, right? If it's functions as a service, how do I test it when it's entirely offline in my own development environment? What is it like to have a local thing like mini cube plus a bunch of things so I can locally develop versus developing out in a cloud development environment? Because sometimes I can't run everything locally. It just takes up too much memory and resources. How do I deal with this? And there's a lot of space for app tools here. And I would argue that the space is pretty mature right now. I'm not exactly sure what to do with it, but... Yeah, look, I think you're right. I was hoping to be on the call because I wanted to ask you what happened to the working group working group. This is the thing where we were going to try and figure out what should working groups do, what should their minimum criteria be, and their exit criteria, which I think you were involved with. I think that's part of this discussion because we're essentially saying, let's bring this together with the themes that such as what Brian said. Just on the app tools, I would personally want to separate two different pieces out. One being the whole dev to cluster story, which I see more as part of pipelines, and the other being the story about application frameworks. For me, those are things like, for example, cube flow, which should be an orthogonal concern, but it may not be. Yeah, when it comes to... So the discoverability of tools can kind of be a problem right now. So getting more app dev tools into the landscape and categorized would probably be useful for everybody who's searching for things. On the whole working group, working group front, I think Chris was the one who was handling that, and there's an open poll request with a whole bunch of stuff in it that still needs to be worked through on that. I think that's actually what's holding up the safe working group, which is kind of a subset of the whole security picture from going through. Chris, you might have more to say. Yeah, that's exactly it. We just have to get through that poll request and get some of the comments that were made. It's all my to-do list. Yeah, I agree with Matt about the discovery of tools. Most of the tools have less than 100 GitHub stars. So they fly by in a blog post and a tweet, and if you weren't watching when it happened, there's no way to find them. And that's actually created the problem of you might have three or four tools that do the exact same thing because people didn't know about each other working on the tool. Yeah, no, they're very similar to JavaScript web frameworks at the moment. It's basically a feral jungle environment. Okay, anyone else? Last call for comments. Don't forget, the document will stay up and I'll look at it periodically. Do you please put some ideas there? I'll try and bring up the main points next week at the GB meeting. Thanks very much, everybody. I think we're done for today. Cool. Take care all. Thank you.