 Hi, it's Jim. Hey, hello. How are you? I'm good. Looks like we're the only ones here today. Yes, I thought Erica had scheduled somebody on the agenda. Let me just quickly check. I seen the meeting notes that there was one item and then the person wrote that he's unable to attend so. Okay. And I don't have anything. All right. Yeah. So I think we can just reschedule then and wait on the, I didn't have anything to report either just for quick introductions. I don't know if you have met before in this meeting or in other forums. I'm Jim Baguardia from Nermata. Cool. I'm a Itai Shokuri. I work for Racco Security in the open source team. I actually have been listening to the policy walking group meetings for a while now. Okay. And I like ask some of my teammates, Liz and Daniel to join and I know that they have also presented here before. Yes. I'm following your work. I like it. And I just wanted to keep an eye on the progress. Got it. Okay. Yeah, so I think, you know, Liz and Daniel had presented a while back. I think on, was it Star Star Starboard? Okay, right. And we had talked about, you know, potentially leveraging the policy report as part of that. We're also very interested in, you know, there is some activity on taking, you know, output from like different scanners like Kubbench, etc. Perhaps even trivia and, you know, kind of converting it to policy reports. So it would be interesting to discuss that in more detail and see what would be the best approach, whether it's through Starboard or whether it's through some other adapter or other approach that we write. Yeah. So I think that right now the policy, this working group is working on just the spec for how the reports can look like, right? It's not any tooling related to the scanning itself, right? Am I getting it right? Exactly right. It's just a spec for the output. And the report is meant to be almost in some, a summary of all, you know, and that could be of course multiple instances of reports at different scopes but the idea is to have a summary for the cluster admin or the operators to see outputs from different tools. Yeah, so I think that maybe in the context of Starboard, maybe Starboard can offer, right now Starboard outputs the report in its own format that is more tailored to the actual tool that is being scanned. So for example, for a trivia report we look different from a Polaris report. But I mean I think that the policy spec that you're working on is very interesting. So maybe we can add another option. And by the way, I'm not speaking on behalf of Aqua or anything, I'm just brainstorming here on cloud. We can maybe add another option that people can choose to get the report as a, is there a name for the spec? I don't know. It's just policy report. Yeah, as this thing. And this is one option. The other one is going through an adapter, I don't know. I think we can, it's a good idea, we can consider it. This is why I'm trying to join these calls to see when is a good point to start looking at that seriously. Okay, sounds good. I see Jaya is on to, hi Jaya, how are you? I think Jaya is on mute. Hi Jim. I don't know if you're picturing your name. Is it Itte? It's Itte, yeah. Itte, Itte. Yeah, Itte is from Aqua Security. He works with Liz and Daniel who had presented before. So we were just chatting a little bit about, you know, the integration with tools like Kubbench, Trivi and maybe Starboard. Yeah, in fact that that would be a good question, right, which is, is this the first time you're looking at the policy report proposal and is this something that will get integrated with Kubbench? It's not the first time, but I am looking for the right opportunity to look at it. I don't know, like, what's the plan to make this proposal something more official or is there anything, any milestone that we should be looking forward to? Yeah, so there is, you know, I think we have to try it out and it kind of, it's interesting, right, because I don't think there's any formal process to make it official. The idea would be if we show adoption and if we show how this is used in different tools, then we can go back to maybe Six Security and say, God, present this to them and see if we can get this promoted to its own repo out of this prototype's repo, right. So that would be kind of, I guess it's not really any official graduation. So this is not going to be, there's no formal way to make this part of Kubernetes per se, right, because it's a custom resource and we wanted it to be a custom resource. So, but what we can do is if this goes under in the Six, and if there's adoption of it, we can propose it either as a CNCF Sandbox project, which again, I don't know if it makes sense to do that, or just move it at least into its own repository with its own name space, where we maintain it, right, to say this is a policy report everybody can use. So I think that would be it right there's no other, there's no other sort of milestone or anything we're looking for and even of course from the in the current repo it's completely usable. So we have started using this for Kiverno, which is a policy engine project that I'm involved with from Nirmata. We also are using this for, you know, in the multi-tenancy working group for multi-tenancy reporting. So there's a, there's a tool called multi-tenancy benchmarks, which can scan a namespace and, you know, kind of recommend best practices for multi-tenancy. So we're using the same report format for that. So those are two examples and I know JS team is also, you know, kind of looking at integrating into a few things that Red Hat in Rackam and that product, right, Jay? Yes. Good to know. I think we're definitely, it's definitely interesting and we are going to look at it, how we are going to integrate with it. I can say if it's like right now or maybe next month or something, but definitely something that on our radar. Okay. Yeah, that makes sense. And I think we should kind of, you know, the idea, the reason why we went down this path, is we are looking for what's the, you know, almost like the simplest thing we could standardize across policy tools, right? And I think there are more, there are other ideas we had discussed, but we decided to focus on this as the first, you know, kind of building block. And then we can go back and, so by the way, I don't know if all of you have been following like OPA is graduating or they've submitted a proposal for graduation. So there's some good discussions also over there on that thread for, you know, the pros and cons and the tradeoffs of using something like OPA and Rego versus other policy tools. And I think, you know, I'll follow up with those few folks who commented and invite them to come to our group and discuss, you know, other ideas for standardization, right? Because I think it's clear there'll be several tools doing different functions. So I think we probably, one of the things we can do is even, and I know Starboard has some classification of tools already, right? So perhaps we can use that framework or we can extend that or refine that as needed to say, hey, here are the types of different tools, whether it's image scanning to admission controls and configuration scanning or runtime, you know, runtime kind of security type of tools. So those are the categories and then these are some examples of tools which fall into each. And of course CICD like so out of cluster tools, right? So tools which can scan and manage YAMLs and report outside of a cluster itself. Yeah. Makes sense. So maybe go ahead, Jay. Yeah. So one thing is I wanted to just say here that RACM is integrated with the Gatekeeper OPA, right? So we are working on that. And the other thing is I posted a link in the chat for Oskal. One of the things I'm also trying to understand is how, what would be the integration between what Oskal, the work NIST is doing with the Pulse Report proposal? I don't know that you guys are, have you looked into Oskal? I have not. I'm not familiar with this. Yeah. Hi, this is Robert. I was able to join late, apologies. Hey Robert. Yeah. So I have looked at Oskal and I'm helping a couple of projects look at it. So I think the answer to your question is, you know, certainly that, I mean, Oskal is a definition of controls. So if you look at policy, policy is either a statement of controls or itself a control, as I see it, and kind of the conceptual model. So I think, and I'm not an Oskal expert. So if I misstate the model, please feel free to jump in and correct, but I think that there are definitions within the Oskal model for policy. There would be a component of, you know, some system, but it would, you know, doesn't, a component doesn't have to be software. It doesn't have to be hardware. It could be a policy artifact. And so I guess the goal would be to map policy as we think of it in this workgroup as, you know, executable policy, machine executable policy. Policy would be itself an asset in Oskal, a component in Oskal, and the findings in the CR API, for example, would map to some control definition, both the originating policy and then also the contextual goal of that control, if that makes sense. So a control mapping to policy, a policy mapping to control. So that's how I would envision the interaction between policy and the CR output versus Oskal. Yeah, I think that makes sense, Robert. And what I was thinking was if the policy report schema includes at least some of the elements of Oskal, then management tool that is consuming the various policy reports can provide a view from a particular standard perspective, right, whether it is in the state in 153 or some of the other standards, is where I see the linkage between the two. Yeah, essentially there's two use cases. I mean, I'm sure there's many others, but kind of the two primary use cases, you know, one is kind of the DevOps perspective. Someone hands me down, you know, this link to, you know, FedRAMP or NIST 853 and says, you know, implement this, and I have to be able to demonstrate that my policies cover certain controls. So by kind of top down mapping my policy implementation all the way down to my policy report output to a particular control, I can demonstrate, yes, I have accomplished that. I've mapped these policies and these outputs to a compliance statement tagged with these controls in Oskal. From the other direction, if you're an auditor, you want to, you know, you're going to collect evidence, so you're going to say, can I query the system for NIST 853 AC-3 query all the policy report outputs that are relevant to that control so that I can gather that into my evidence locker. The top down and bottom up use case. So that's why I think a bi-directional mapping is highly necessary. In terms of, I guess the other, the user, I don't know, maybe it overlaps these use cases, the first one maybe. If I'm an actual FedRAMP authorizing official, and I get someone drops an Oskal implemented FedRAMP package on my desk, and it's supposed to be machine verifiable that I meet FedRAMP, then there needs to be a detail, a tracing down to, you know, an actual policy artifact and machine readable code that says, yep, it's implementing this control by via this executable means and the data it's generating is going to map to this control, you know, policy report output. So how that would work, and I'm not, I don't know how the mechanics of that would actually work and how the validation tooling that FedRAMP folks actually have ready, but I think that's the grand vision. Yeah. Yeah, I think I wonder whether Jim, we should include in the, in the policy report the, at least a position set on how we would integrate, right? Yeah, I think that would make sense. Is there, you know, I know Robert, you seem to know this, but is there somebody we also perhaps want to invite from, you know, might be working on Oskal to do a deeper dive and sort of give a presentation in one of our working group meetings with that? Yeah, I can, I can certainly reach out. I don't have a special relationship with any of the folks and we're all monitoring the same Git repos and commenting on PRs and whatnot. Right. Let me reach out to them and see whether they would be interested in doing that. Okay. That'd be great. Yeah, we can do that. But I'm happy to, I'm happy to be the grunt worker to kind of put together some sort of an outline or just a strong man proposal. Yeah, that'll be great. That'll be great Robert. Yeah, we can start thinking about it. And then I will reach out to my next contacts and see whether they can come here. I have done a number of presentations, and then other peripheral groups, industry and federal groups have done this Oskal webinar. So I can, I probably can collect a bunch of links and drop it into the Google Doc sometime. It's not today, later this week. So if folks are interested in kind of the overview of what Oskal is. Yeah, I'll give some background material. Yeah, I'll be great. I think that's good. All right. Yeah, the other thing Robert we were just discussing and just thinking out loud and in terms of potential things we could produce in addition to the policy report and of course continuing to, you know, grow the adoption of that and maybe one thing that we could do I was thinking on that is that maybe once we have a few examples of these reports we can even create like a CNCF blog post or something to advertise that this report's available and, you know, see, just promote interest in it. So the other, you know, other potential deliverable or something we could, you know, output from the group, it would could be, you know, starting to, you know, have some classification of the different policy tools that are in scope right that we're talking about and you know, the Starboard has a good, you know, sort of grouping of these already and we had discussed some of that with Liz and Daniel, and it also from Aqua sec was just discussing that so perhaps that could be also a document or a Google doc we could publish somewhere to say, and of course that can will change and evolve over time as things change but at least right now we know that there's image scanners there's admission controllers there's configuration scanners and and runtime security type of tools that we're and those examples of each of these categories right. Yeah, that I make sense I know Howard and Erica are always putting together slides for for various cube gone presentation so and they're they're more dialed into that process but I would imagine that whatever we can produce as a white paper or more guidance here kind of bump it up to the we could present it to the higher SIG group on the on the later 10am calls 10am Pacific and then if that you know based on that reception I would imagine that Erica would would be happy to put a cube con presentation around that. Okay. All right. Yeah, I'll bring that up with her and let's let's see what we can do. There's a white paper that SIG security is offering at the moment I don't know if you've considered to Well actually yeah that I and when I unfortunately I put on the calendar item today the discussion about Oscar but then took it off because I have this unexpected conflict but now that I'm on there was a lot of back and forth chatter in that white paper review about compliance. It wasn't necessarily in the context of policy, but I think I think certainly everyone here on this call kind of sees that there's a nexus between compliance and policy. So I had said that yeah we would we would kind of champion that is a discussion point for this group. I think I still think now that we've had a little intro. I think it's probably beneficial to put that on the next meeting. I'll like I say right up a little bit of a summary of Oscar how that integrates with the CR and incorporate some of that chatter from the white paper review. But yeah you're right it I think the gist of the back and forth on the compliance section of that white paper was that it was kind of you know open ended would be nice if there was more substance to that that component. At least that was the takeaway that I had. I don't know if you had a different perspective that you take. No, it's fine just want to bring the topic for discussion. Don't have any opinions about it yet. I mean, I guess my trying to gather data versus project a particular solution. I guess the only bias I would have is that if the goal of the cloud native security white paper is to define compliance within a cloud native infrastructure and conceptual framework. I would think that that greatly overlaps with the notion of you know policy definition policy output definition and all within kind of the shift left you know infrastructures code policies code policy compliance as code metaphor. So that that's kind of where my brain is is anchored. Makes sense to me. Yep. Okay. Yeah, so maybe Robert is that something you want to do you said you could write up a summary but then should we put that on the agenda for next our next meeting or what do you propose. Yeah, that's that's what I'm suggesting is that I'll just expand on the agenda place that I had for two weeks from today. I'll add details around Oscar and. Okay. I other other resources that you would like me to explicitly review is part of how that connects to any of the projects you're involved. I'm happy to take a look at those. Yeah, I'm actually talking to some folks in the IBM research team later today about this very topic. So let me see you know whether they have published anything externally and I'm also planning to bring them in into this work group as well right because they're also looking at this this topic. So let me let me try and do that. So that's one and then like I said I have some contacts in this that I've been collaborating with also from a redhead point of view so I will bring them as well. And so we can bring them into the same forum right so we can talk about that here. Okay. Yeah, and I'll try to get you an advanced draft of again it's not going to be anything extravagant just a simple outline one page or. But if you if you want to circulate that around to this group in advance of that call then maybe we'll get some some good feedback on the next on the next session. That sounds awesome. Yeah. So you can just put a link into this into the into this work groups agenda meeting notes talk right. Correct, correct. I'll expand the place over that I have there. Okay. Sounds good. Thank you. All right, I don't think we had anything else on the agenda for today so unless anyone else has something to discuss we can, I guess, wrap up early today. Yep. Okay. Thanks everyone. Thanks. Take care. Bye bye.