 Hey folks, it's Jim. Hi Jim, how are you? Good, how are you doing, Robert? Doing well, doing well. Calling up the notes here. Yeah, I was just updating myself. A few items we can discuss. So by the way, Robert, did you get the email on the, the SIG membership? I think Christoph mentioned that you probably received an email you have to accept. And that was the last step. So many inboxes and a ton of SIG stuff. Yeah, so this would be from, I guess, I guess it would be from GitHub to join the group. Anyway, carry on, I'll keep looking here. Okay. Hey Jim, can you hear me? This is Jaya. Hey Jaya, how are you? Good. I actually had one agenda topic I wanted to bring up today. Okay. Do you have access to the doc to add it or? Yeah, let me do that. Okay. Okay, I added it. All right. Jim, can you send the post the link of the doc, the chat please. Sure, it should be in the meeting invite, but let me add it on the Slack as well. Yeah, and I guess our first topic we can talk about is this actually related to that and just the organization of the group, etc. So maybe let's kick things off. I think we're almost at five past and we have, you know, quite a few people on already so. Hi everyone, this is Jim. And let's get started with our work group meeting. So one of the first topics I want to discuss this is something Robert and I were also discussing offline and trying to figure out what's the best way to coordinate things. So the, you know, we have been of course working, you know, with this group with organizers like Erica and Harvard in the past, but seems like they have, you know, moved on to other responsibilities or are not very active with the group at least at this point. So, you know, I reached out to get some help from our TOC liaison, you know, and to see what can be done. So they're going to also find out and reach out and, you know, see if there's a way we can get access to the videos. So apparently each work group should have their own kind of video channel, which helps us with the calendaring and things like that. And even then updating meeting invites, etc. would be a lot easier for us, right. So, in the next few weeks we'll get some of those things sorted out so that way we just have the path moving forward. And, you know, also, like, I guess it's too late for GoodCon EU, but maybe in the GoodCon US, you know, we should plan on doing a session update, talk about some of the projects we're doing in terms of the policy report CRD, as well as like other projects we might start or initiate, you know, by then there's a lot going on, of course, with, you know, pod security policies being marked for deprecation, with, you know, this discussions around policy engines, and other policy tools in general. So I think there's a lot of good things we can say and, you know, talk about and also get feedback from the community. So that's the, you know, idea, and let me know if there's any thoughts, you know, other things we want to do. We can also use this as an opportunity to solicit interest from other states and kind of revamp a little bit of the agenda for the working group and what we see we want to do in the next 12 to 18 months in terms of things to accomplish. I agree. I agree. So I guess one foundational question, because I think Howard had started this as the Kubernetes policy, and then we kind of overlap we were are currently housed under the CNCF security as a subgroup of some sort. So even I'm unclear as to where are we, what hierarchy, where do we want to be, where are we, where should we be. And I think we can, yeah, get feedback and it's, you know, we can propose what we feel makes the most sense, right. But it's a good question. As a quick straw man, do you folks are folks here coming because it's a Kubernetes specific group, or are we coming because it's CNCF all inclusive and it could span, you know, everything from, you know, Istio to cloud custodian to OPA to outside of just Kubernetes. Yeah, I think, Jay, this is your talking and I think from my perspective, I think, you know, I'm passionate about policy based governance across the stack right so given it is this definitely one piece of the puzzle but I think we need to apply this throughout. But, so I would say my primary interest is Kubernetes but it goes beyond that. That's helpful. I would, I would echo that this is Raj's echo that very similar. I come at this more from a compliance perspective, but primarily in Kubernetes and other systems. Thank you, Raj. Yeah, and I totally agree I think you know obviously Kubernetes is not the end all place. Although having said that I think for projects. It seems like the natural place to start and then kind of widen the scope right so, but we do want to make sure we cover other systems like service meshes. And in fact, you know I'm sure most of you have seen or read or heard of the cloud native security white paper. We can use that as a framework to some degree to organize also. You know, our policies impact different parts of the cloud native stack. The other thing I also wanted to highlight is I know this group is under the six security. From my perspective right policies or security policies obviously are very important, but policies are also relevant for Sicilian see and other software engineering aspects right so I think at least that's the way you know we are approaching it right because when you talk about standards right, I think it's a when the customer wants to run, run their cloud to meet standards they're looking standards across the board right, but you know I'm not. I'm not particular on where actually this all fits in, I don't think it's, you know as long as the work gets done right. I'm not going to insist it has to be in one log versus the other log I think security is fine because most customers I think security is the first one they would apply this to anyway so. Right. Yeah and one interesting thing which wasn't and so the Kubernetes security is fairly new and this I didn't even realize there were two securities until you know I saw the Kubernetes security and then there was a CNCF security. Robert in the past you were always mentioning security, referring to the CNCF one and I could never find it on the Kubernetes slack right and so I think that was confusing for me in the beginning but I understand of course there's two different charters now and of what they're doing and they collaborate with each other so that all makes sense but yeah we can decide either based on a. So from certainly from the working group perspective seems like a broader charter makes sense from a per project point of view, we can decide, you know whether we start with the Kubernetes scope, and then add on other tooling and other support. Or, you know, just start with the broader scope in some cases. And we don't have to get the weeds but maybe we can have it to take it on the slack but I think from a governance perspective I guess it seems like we're using the Kubernetes GitHub and repo. Right, but we're somehow in the CNCF governance framework so I guess I'm just, I'm confused as to like, who are we right. Who are we supposed to report status to who are we ultimately. Yeah, but I mean, we can take that offline. That's why I was consensus that the scope needs to be bigger than upon Kubernetes but rooted in Kubernetes as a practical matter, so I think we're all on the same same page. Yep, makes sense. I believe this in our, at least the initial charter when Harvard and team started the group, you know they had listed all of these six stakeholders. So architecture of multi cluster network node scheduling and storage. So I'm assuming there was some discussion with all of these six. I'm assuming the security is not listed here. Which, you know, obviously we've been working closely with sick, say God and sick security. So yeah, so anyways we can we can revisit this, you know what guidance from so Christoph is our, you know, steering committee liaison and help us get some of these things sorted out. You know, this is anecdotal, but in discussions with folks like custodian, you know, they primarily don't see themselves as compliance tool. So they would, they would be more policy in terms of managing resources, right, maybe that's cost, maybe that's just visibility. So, yeah, I think, you know, security is just a part of it. Right. Early on we did talk about things about resource policies and things like that. That said, from a practical perspective. If you, I think the audience that's used to dealing with security policies the audience that gets it first, if you will, right. All right, so more to more to come and more to happen and I think you know if we can drum up some interest from other groups on some of these projects and at some point we'll have you know, maybe we just need to have some. I don't know the full process but Christoph will again tell us that I think there's a way to have like elections or votes for new organizers based on and we should, you know, reach out I think there's other folks interested in the Oscar work and the white paper works if we advertise the projects. Based on that we'll get to know. So I think for each project we want somebody to lead that and then we won't organize this for the group who can do the overall. So we'll have to get that sort of roster in place at the right time. Okay, so we'll continue working on that and I'll update you know everyone as we find out more and just feel free to reach out if there's any other ideas etc. The next item here is on the CRD so there we are is, you know, right now there's a few PR spending and we were stuck because we had nobody to be able to review and merge these PRs but now Robert has access. And so I took all of the work that you did and you know resubmitted that on the goal line types. So that's in this PR. I did have a few questions but we can discuss those on Slack or if we can come back to that if we have more times like like I posted some in in the GitHub issue itself so maybe if you can take a look at that and add in your thoughts. But the if we can get this PR merged I think then we have all of the you know the work that you did to for aligning this with Oscar. Yeah, this would be merged. Yeah, I realized we miss one thing so yes we've done the mapping. I have all also to check against the schema. If we have all the required data. So if we use the data to generate something and if we do not have all the required data, we will fail the validation and right we cannot use the, the Oscar object so I will have I have that to do as well to make sure that we don't need to add anything on your side to have a complete validating. Okay. All right. So yeah just take a look at the in the changes here see if there's anything else or any other updates we need and then we can go ahead and get this merged and regenerate the HTML file for the schema. So the PRs that are pending we need to decide so there were some comments on the on the document about adding like time fields and adding other fields for. I believe it was like resolution and things like that. So we need to decide if we need those or we don't. I think time of course like when something was reported. So often it occurs when it was last seen that is required but these others. I'm not sure if they're required and how we would use but those are the other two PRs that are pending which we have to decide if we accept them or not and what we want in the CRD versus what can go into the unstructured data. So for the last scene, the latest discussion and I didn't get a chance to go and look where it took off from. We agreed with the person that was on that task that we need. The second is like a you know a first degree type of information and we need a second degree right because I can have something that oscillates and the actual last scene is not helpful because I'm just oscillating and so to move to move more in terms of you know. I think that's another measure that would be more helpful right to reflect the long term information because I think the idea of last scene is to help with that trend with that you know inform the user this is happening for a while and to make sure we don't lose it. Right. Yeah so with the combination of first scene last scene and occurrences be enough to capture that or do we need something more and what would that be is something we need to decide right. So if I have something that oscillates right I'll have a first scene last scene and occurrences 111111 right so yeah so so. So this would be a timestamp for scene last scene would be dates like or epic times. And this would be the number of occurrences that would increment. I think we're just saying just have a timestamp on. I guess the question is, do we just want the last timestamp. It would be important to know when it was first seen as well and then. So first scene timestamp last seen time spam and how many times in that you know has it been seen is the three things right that was suggested. The other way is of course of doing it as like, I guess, start and end is also first and last or. I think about that we don't have to decide now but we need some time information and each of the result entries right and these three to me it they seem to capture. What would be required it's you know and then other systems can periodically scrape this and add trending and things like that right. Yeah I think when we have something that oscillates right let's say that it changes within the hour and comes back and forth. And if I'm doing this over one week. My last scene first scene will be from the last hour because that's when it actually changed to the new value right so I lose that the fact that this I have an issue there for a week now because the first scene will not mutate that would be the first time it was reported. That's the intent that that condition whenever the first time it occurred. The first scene would be from the hour. So last hour but the first scene would be a week ago and the occurrences would be how many times that happened in that. So I have control a, and it switches between false and true false and true right and, and you are saying that the first time it becomes false. I'll have that would be my first date. Right, and within the next hour is change it changes to true. You can see what you mean. So it's flipped now to true. So that's why the first scene was clear. Yeah, yeah. Okay. So I think maybe I'm not sure you know I have seen a type of KPIs like within the 14 days right we can we can take and say, you know how many times that awkward within the 14 days. So but that would be if an external system were, you know, pulling and putting this data like through Prometheus or something. Again, like the intention would be to capture the current but then let the history be, you know, stored in some external system in a histogram or other metric like you're suggesting that work. And that's what I try to, I think we try to achieve here we do not have historical data when I suggest the result we don't keep historical data historical data would be kept on some logging tool right monitoring tool. And how much do I want to capture within a given sample right that that's that's the question. Right. So of course, if this period is not granular enough then yes it some history could be lost if it flips too quickly. But you know, typically you're we're talking about minutes not like milliseconds or anything like that so yeah. What I like as a as a as an admin is is to have this in the summary so when I have the summary, or, you know, or maybe even that that occurrence right that it tells me that that falls around how many times it happened. Right. In the past 14 days, not since the last occurrence because if things flip, I lose that that that was the right but then then on pre merging in the history again and you know is it is 14 days enough it should be 30 days should be one year. Yeah, I think 14 days is more than enough right because you are looking at the spectrum to be able to fix something maybe even maybe 48 hours is enough, or you know one week. 14 is kind of a magic number for many things that's why I'm coming up with that. And if I really want to look for a year. I'm not going to look at the current sample I really go back to my logging system to whatever, you know, from issues and look for the, you know, evolution of that, of that control value over the year I'm not expecting this is one sample of data. Hi Jim and Anka. I do have to drop in five minutes but I wanted to see right one agenda item I added I don't think we'll get to it today. One of the things I want to kind of focus on is, you know, we have all these various policy engines right so we have gatekeeper opa and then we have given no. And I wanted to see how we can at least create some positioning or you know how to bring these together right so because from our perspective within red hat we are. We have picked up gatekeeper opa and we are, we have incorporated it into our offering and we want to we are going to support it, etc. Right. And then I Jim you took us through the Q&A right so now I'm kind of saying you know, how does that relate to this right so and also I wanted to share how our policy framework which we are open sourcing is integrating with all these different engines and by the way we have created a policy for Q&A now. So, so I think, I think. Maybe that up as one of the topics, maybe in the next call. Sure. Yeah, definitely we can, you know, discuss it earlier if you even want to have a, and then maybe there's a natural sort of segue into this. One of the things that was proposed was having like a white paper with some positioning document policy reporting and policy tools. Yeah, maybe that's this might belong in that yeah. So in the historical context, Jim I think you may recall this but when we first started talking about the policy report. It was actually a compromised position from starting this conversation that we absolutely didn't want to boil the ocean and try to spec what a policy engine interface or specification should look like without a little more community involvement and we decided the first way to do that was to kind of define the output. And then we could maybe circle back around and look at the, you know, the input, if you will. Right, but I like this, this white paper right so maybe the white paper can, we can specify the overall building blocks of the policy architecture and the policy report becomes one of the right. And then, I think I think I'd love to contribute to that one. Okay, cool. Maybe we can do this up in the next colleges in a couple of weeks. Okay, if you're interested, I know you've got to drop it. I'd be happy to take that off as kind of we could do that as a slack. I think there's probably some momentum that we can build over the next couple of weeks. So, yeah, so definitely, you know, let's, you know, go through what I started capturing in the white paper and we could even collaborate. This is just more intended to be a working document at this point to see what do we want what is the scope of the white paper because again if we make it too large it'll just take longer. How do we dovetail into the cloud native security white paper, and we can use they've actually come up with a really nice process and other things to do this so we it would be good to read up on it and decide what we want to do. And then we can go back to the six securities both of them and you know share the proposal, get some more feedback and then start working on the sections. And really the first question is like the audience and the scope of the white paper itself. Yeah, yeah. Okay, I'll definitely take a look at the white paper and like Robert you said, I will go in and put my thoughts down there also. I'll be great. I think maybe we make use of the every other week to do a slack session that we can do more of a working session. Sounds sounds great. Thank you very much. Thanks, yeah. Yeah so and I can kind of discuss this more offline to my only concern but you know again adding in any form of history is, you know, we have in the past tried to keep the report just your current information. So certainly, if there's an in cluster Prometheus etc that could be looking at this every 10 seconds every minute, picking up these values and then showing any historical occurrences. But, you know, my preference would be to keep that out of the policy report CRD and just because the report itself is only talking about current current, you know violations and current results. It doesn't keep any other history today right. But so I guess Mike, why do we need any of these fields if we just have a timestamp for the for when it was reported. That's fair too. Yeah, so then we can just keep a timestamp for when it was reported. The only thing if, if there's a monitoring system that's periodically collecting. You have you know the number of occurrences in in its collection interval. Right so that that was the thinking and it's this is very typical in monitoring systems you have like a first seen last seen in the number. So let's say the monitoring system is collecting every five minutes. You're just saying that I, yeah I saw it, you know in that. When it was seen when it was last seen and occurrences but I'm fine with just keeping a single timestamp and starting with that. Yeah, you assume that we have the current the last report and I override that last report but I can still use the information from the last report. So I copy the first scene I, I update last scene and I increase increment occurrences because that's that's the idea here right there so I don't don't have any other support, other than that. Yes, so if a policy engine is producing this report. That's exactly what it would do yes. Okay. But yeah we could just start with it as a single timestamp to say last seen and I think that one we all, you know, it's definitely going to be need and then we can add more if, if required. I think, yeah, I think it makes sense we keep it simple and typically the monitoring system will have alerts associated with that so we'll need to have more in depth analytics so if that type of flip that I mentioned occurs will not be detected you know at at the policy location, it will be detected at the. Right. Okay. You know that makes sense. I'm just typing a comment. So, so we just want last seen then that's, I mean it's the timestamp of this report. This report. I would keep first seen because last seen is my timestamp right my current time of capturing that right so. Last seen, if I would be to, I would only store first seen right last seen will be replaced with my current time last seen is equivalent to the current time isn't it. So maybe we don't call it last seen or first seen just call it timestamp or. So timestamp is, we don't have timestamp today at all. So timestamp is is the okay so then we have to have the timestamp right so this is what happens now. And, of course, we can keep logic for last seen and and occurrences that would be additional properties of the of the evidence that's not there's not a problem. Yeah, so we don't have any notion of time in the results right that's the. That's, I think it was one of the gaps that you are they were identified you're right here. So just, I wanted to go over all the, all the required fields in in Oscar to make sure we don't miss anything else timestamp is definitely required. Okay. All right so let's just call it timestamp or something else. Yeah, yeah we can we can call it timestamp. I don't know what we have in Oscar. Okay. All right, so if you look in the comments there you will find because I put it in the comment what it's called today. I'm Sam collected expired with. Time stamp time stamp is the value. All right, perfect. Let's go with that then. And then yeah and the other PR like that's you know we can decide if we want something else. Like in terms of the resolution or other fields right so we can add those later but okay. And Robert yeah maybe once this is done we can set you as the approver again for the PR and let's see if you can get this. You know you'll have to add like the standard LGTM and approved labels, and then that should allow it to get merged. All right. So one other quick update so we have, you know, I enrolled in the Linux Foundation mentorship program. This gets us, you know, and a mentee or an intern to work with us for three months. And the project that I had proposed was, you know, taking good bench and writing an adapter to capture the results and produce the CRD. So we'll get started on that project starting next week. And you know if we get good bench done we'll do Falco next and then we can also discuss other tools as needed. Yeah, so I had a conversation with Kapil. They're kind of off busy doing more collectives and not particularly engaged in doing but that said, I'm happy to propose a PR for them. As I dug in, it seems like a story and they'd be more of a consumer rather than a producer of the policy report. Because they're, like I say their policies are less about evaluating, you know, any kind of current activity and more about just imposing a set of requirements on resources. And in particular, their Kubernetes support is pretty minimal. So I think it for their Kubernetes specifically I think they would generally just consume reports. So I don't know that they're going to be a good producer, but that's okay. We need more consumers too. Yeah, absolutely. If they can leverage the CRD in any manner right then that it's a good use case. So and not, not knowing prior today that we were going to have Q Bench. So Q Bench is obviously another consumer. So I would assume that that's going to be a very similar approach. No, Q Bench would actually produce the policy report right so the idea would be that we would have a job which periodically runs Q Bench for CIS compliance on both the control plane and the worker nodes. Oh, sorry. Right. Okay, so I was. I was thinking of coupon. Yeah, so Q Bench and Falco would both produce reports periodically is the idea. And it should be pretty interesting because that will bring get CIS compliance, you know, into all of those would be now available as reporters, which we can then any upstream system like whether it's, you know, cloud custodian or other systems can pick up and process. And I think this dovetails to the white paper, you know, having a good example of so maybe that's the end to end flows is showing how CIS benchmark, you know, a policy engine like a burnout and then something like a custodian consumer. Right. And so yeah, the other and that's maybe, you know, if you go to the what I started drafting for the policy management. And if you recall, we had one discussion with Liz, who was at that time with with Aqua and she Aqua security and she had mentioned, you know, what they were doing for one of their projects like they had also mentioned. Covering like image image scanners configuration checkers like you know they were using Polaris I believe, and then you know runtime of course security like I've listed Falco year but there could be others. And I put, you know, control plane security and worker node security with CIS benchmarks and could bench as the tool there. So there's some interesting set of things and of course now with supply chain security concerns as image signing is becoming more and more hot topic of discussion so we might want to look at what's going on with notary notary we to and see if there's any interesting things there. What is in total for the second of a combination of scanner and signing. I don't know what that is. What does it do. I think it's kind of comprehensive supply chain. Okay. I'm not sure what it does for a map it. Okay. All right. But yeah let's let's talk maybe then briefly unless there's anything else on the on the CRD we can switch to the white paper and I have one. I have one one comment on the on the CRD. I'll mark it right now in red. We discussed last time about the, you know that hashing and source and you know to make sure that the policy that I use is the valid policy. So I added as part of the, the policy parameters. We have category we have severity and so on. I audit source and and that can be the version in it. So we are able to relate to that. So that will give me we don't need to update anything in the metadata because once I have to get I have the whole history who updated it who is the contact. So we don't need anything else besides that version. So now when we generate that I'm not sure if the, the policy, the check will have that visibility in the in the policy version I'm not sure if the policy comes already with that information to use it in result. So now you know better how to track that. But I think if we just keep the version that that should be enough my, my to say. So generally, you know, and I know there was a brief discussion on also on slack about this. The question is, you know, yes, get would be a best practice and certainly it makes sense to treat policy as code but does that match the reality of what we see in a lot of enterprises and, you know, so for the policy report I think it is good to have that option to, to have some fields where this could be added. The question is, do we want to, you know, can we make the assumption that it's always going to be good versus something else and how do we, you know, how, how much of a standard do we make it versus a freeform field because the report is extensible you could put things in the data field. I agree Jim but to be practical, if you look at, you know, opa and Keverno, they both fit the model of, you know, policies code in git and will give us that what would be other examples where the policy will not be present that way and is that prevalent at all in our in this context. Yeah, so even with open Keverno, I mean, certainly yes you can store those in git but do you have to versus are you consuming them, you know, those libraries from like directly from like say for example, I don't know for sure but I believe like there are also, you know, cells like subscriptions and they can release libraries right. So the source may not necessarily be a git repo that an enterprise is managing. I see what you mean. It could be a vendor, right. Yes, we can have the source. So Oscar today allows the source to be an href of that particular. Right. So not necessarily that but what I think the point is that we need to have some kind of version to to associate the validity of the policy that we the result of the of the of the check right with the validity of the policy itself. Maybe a URI resource. Yeah. Yeah, and everything because I can express even that in that fashion. And there's two fields we have already in each result right so the results can have a reference to a rule and to a policy. And they're free form right there just tax so if you want to put a git hash in there you can if you want to put a URL in there you can. If you just want to identify names, you can do that right so we're not really mandating what goes in there because different engines may have different ways of managing it. But we have in the result, like a policy and rule. And, you know, that's right. I think the point, the point Jim is that if I need that in the result. I need that to be part of my policy input. So this means that it would be a requirement on the policy creation part to have that field. So the field is not present there I cannot use it at the result. So but we're not, you know, again we don't control the policy creation year right or we have the policies even declared or manage we're not trying to mandate that or standardized on that right so I don't know how we would, other than just having fields where a policy engine like here we say policy. So we could instead of saying name we could just say is a name or ID of the policy right just to year we have assumed names but we can clarify that in the text to say this could be a hyperlink could get commit. However, they want to reference the policy and rule. This is a practical example so we're talking about Q bench how does Q bench define the CS. Good question right so it would be this policy perhaps would be the CIS document number the rule would be the, you know, the, like the one whatever 12 something right. You have the xcdf your eye. Yeah. So maybe we just, you know, add some examples in the description and broaden this description to say it doesn't have to be a name could be some way of uniquely identifying the rule and the version. And, and I guess the assumption here is policies are organized as a set of rules but we can even change that if you want right and combine the two or keep two separate fields. Wouldn't it be helpful to have this as a nested structure. Um, you mean the policy the rule inside the policy or. So if. Yes, meaning. If you have. If you specify the policy and the rule as a construct, they can simply have a pointer to them right so that they can have any levels of nesting. So if you want to basically simplify this at a very high level and say here is the policy and here is the rule I think this would perfectly work. Right. But if you want to go down levels of complexity, like for example how you typically see things like PC ideas as laid out or missed laid out, right. There is a hierarchy. And they are not policies their controls I'm not sort of saying the same policies can be represented along the same lines as well. Right. So we have, we have the garage we have here a category. So I think that provides I think the, the one level of nesting right so in if I'm looking at a cube, right I have the five sections. So I have the control plane the worker node. So those would be the categories and then we seen those right I have the various rules. To be honest, I don't fully understand this right and I think I love to be on I have not spent enough time on this as well. Oh, I see. No, so we captured the possibility to group them through category right to reflect what's there. But now I see we have both policy and rule. Jim, why do we need both. Yeah, this is marked as optional I think some prior discussion we felt that rule was also recommended but we could, we could change this to, you know, either a single field or we could even actually thinking about it maybe control. So did you in the maybe in the PR we do have control now. It's a different level. Right, it's a different level. So, if you think of the cube bench, right, I have the rules, right, the CS benchmarks are rules, and then they are mapped to the CS controls so the controls and another level of detail and the CS controls and we decided that the policies themselves do not carry our control agnostic. I just checked them and there is another entity that will have the knowledge of what maps to what. That's right. Okay. All right, so yeah let's let's decide on that and you know we can streamline if you want to combine into one field that may be good to. Yeah, but I don't see. I don't think we changed anything there it's still policy and rule from the in the latest commit. But if we want to we can, you know again, combine these two and have expand on the text to, you know, detail that there there's you know other options you could add over here. One more question. So, as Oscar evolves and becomes more and more, we do not have a requirement here to align with Fedrum, right or or anything we we stay generic. Okay. Yeah, there's no requirement on that. Okay, so maybe what we should do, you know, on kind of Robert if you want we can, you know, set up a separate working section just to finish up on the CRD. And, you know, like if you do that either later this week or early next week, I think it'd be good to complete this and get it merged in. This is just a few things pending. And we probably just need a 30 minutes or hour focus time on this. Okay, so let me propose meeting as one place. Sure. Okay. All right, so let's do that and you know I'll propose sometimes and we can get that done and then so the next thing. You know I do want to be up just 10 minutes left but just to kind of introduce. You know so in our last meeting we talked about potentially you know doing this white paper and we were just discussing that earlier too. I did send out a draft and I think I immediately got stuck on okay what is the, so it's not a draft for a white paper it's a draft for the proposal to a white paper and it's more about okay like us defining who's the audience. You know my main question was as a practitioner like a Kubernetes admin or is it a, you know, higher level stakeholder like a CIO or CXO because those were very different papers. And I just based it what they did in the cloud native security white paper and they've kept it very broad. And then you know like the next scope and this goes to your question earlier Robert. Do we want to start with Kubernetes or do we want to go immediately for the whole cloud native ecosystem right. And then the only other thing I did so far was I tried to categorize some of the known tools and areas right so the policy concerns would be like these would be the different categories. In those like we have these standards like or some reference like here we have CIS benchmarks and the tool is good bench for container images as a bunch of image scanners like Claire and trivia and others. And then for commit signing. Yeah, we'll have to research this more. And then for configuration management there's opa gatekeeper Kibirno Polaris which seems to do only scans not not admission control. So we can kind of decide on that and then runtime Falco and there's probably a few other tools emerging in that area. Anyways, we need to decide in real life. If you're the question is do we want to, you know, even talk about specific tools because you know there would be the challenge of we don't want to give preference to one tool versus another but it's nice to know what's available and what fits where. So there is value for users right but we don't want to kind of seem biased in any official publication. So I think those are concerns to address and think about. So I would strongly recommend if if you haven't please take a look at the cloud native security white paper. Look at the process that they followed. And we need to decide on what we do year. The first question is who's this paper for and what should we cover. Jim, I think just my two cents, I think making it generic cloud native may make it difficult for people to understand right again when I say people because for example, there is a there is a working group in cloud security Alliance that focuses on let's say continuous audit metrics, which is a very similar charter to what we are talking about here. Right, but they look at it much more that their previous very very different right I mean they look at this much more holistically at a cloud solutions provider and based on their star certification. So I think it would be very helpful to sort of talk about this at the Kubernetes level first before you start expanding it out, because it's a vast area by itself right and you don't want to get lost that that would be my two cents. The question I want to ask you is that so the process today is that if there are multiple of these providers who can, who can provide these policy statements right that you're going to aggregate and we're going to present this part of the policy CRD. Is there, do they have to register, how do they, for example, how do you differentiate between a policy statement that is produced by Cube Bench versus Coverno versus notary versus trivy. There are a bunch of things anchor clar right so on and so forth right, there could be hundreds of them. So how do we, what role do we play is that do they have to simply register to say that we are going to produce these policy reports and is there a mechanism to do that. No, so there's no central registry or anything like that they would just have to incorporate the policy report as part of their tool chain and either through an adapter or native support of report so it's all of these tools are reporting in some format today. The question is if they're running in Kubernetes do they want to adopt this reporting structure or come up with their own and a lot of tools today have their own independent structure right. So this produces Jason can produce text reports, things like that. What we're saying is if it's running in Kubernetes it makes a lot of sense to produce CR custom resource, which can be then looked at through other Kubernetes tools. Yeah, so it would be up to each tool to, you know, either adapt or adopt somehow. That's that's kind of why I saw the white paper as position paper or whatever we want to call it as kind of taking a step back from the how and more looking at kind of top down like why. And then what am I trying to accomplish with all this right because otherwise it's easy to get lost in the in the details of exactly how we hook up all the technology parts. But I thought this was kind of a good chance to come up for air and explain it to kind of like, you know someone. So maybe the audience isn't the CXO but maybe it's the person writing the report for the CXO. So how should we do any of this, right, right, having them see a cross cut of how all this works together to deliver some value and what is that value, monetary security, whatever we define value to be. Just understanding how the, how all the parts of work and what the use cases are and what, what I get at the end of it. I bother to read all this documentation, install these tools. And then the very narrow scope of policy enforcement. And I think, I think we can all assume for now, security policy enforcement, or compliance policy enforcement, we want to expand a little bit. Okay. Yeah, and Roger agree with your point on the scope I was thinking along much the same lines to say okay what could be something tangible and like let's say if we were to say we want to get something published in three months. Right, taking on CNCF just seems like a fairly ambitious endeavor in three months or in a quarter. But if we focus on Kubernetes and describe, you know what is Kubernetes policies like we can start with some list of categories, give sample tools based on certain date and time and say this is what we know of in the landscape. But then also talk about where the report fits how policy engines can leverage it we can we can go into more details around that if we just focus on Kubernetes. And Robert Duncan, do you agree. I think it has to be rooted in Kubernetes I mean as a substrate for how policy. I mean we're implementing this for Kubernetes. That said I think you know the IBM tools, you know cloud to study and all these have a more right holistic view of the enterprise so I mean, I think it's an, I think we can be clear that this the Kubernetes is a concrete instantiation of everything we're talking about, but that the design pattern should hold no matter, no matter what. Okay. All right, so let's, you know we'll start next in two weeks time we'll just start the session by discussing so add your comments add thoughts to the to this document and we can just use it as a working document to capture what we want to do and then come up with a new proposal. You know that we can, I guess, advertise with various things, and start, you know, assigning folks to different sections of the write up them. I do include the Oscar part as well Jim I did not get the chance to look at all the document. I can take care of the Oscar section. We can certainly when we talk about the policy report and how it fits how it could be used it will be nice to show that you know the report is today targeted to be generic but with the intent of being able to map it to Oscar. So we can show that upper level mapping tool, like perhaps you know the open compliance agent and other things that we've talked about. Okay. Yes, but in the implementation itself we plan to expose the API for Oscar as well right. What do you mean like the implementation of what. So we will have, we will have a library that will translate that into, let's say that will store the Oscar file on config map right. Do we plan also to expose an API. So that would be so we would publish the CRD right and then tools would write, or we would you know kind of sponsor writing adapters for various tools within CNCF. But then the mapping we have not committed to saying that we would you know write some implementation to map that to Oscar. That would be up to like the, you know, other operators or other tools to do that, we could probably have another, you know if you want to document some more details on that mapping weekend but that's not something. And so that's why I say like, okay, I think custodian could be a good first example, because as a consumer of the policy report, and then a producer of general compliance output. So exporting that as Oscar is a is a meaningful thing. So, we will have logic for for compliance as well needs to keep on so on. But today it doesn't. And I think that that's a problem is it doesn't have any definition of mapping it to any particular framework. Okay, well my goal. My goal was to expose natively the Oscar right so the we have right now the that I don't know it's Jason or right in in with the fields that we have available and you know to have the similar observation right in the format of Oscar, right to have to to available. So I kind of a thought that the goal is to align the Jason with compatibility with Oscar so that a downstream or upstream I don't know where in the stream somewhere in the stream someone could consume the policy report. And that's where the code would be to produce the Oscar, and I'm just saying that that to me the house for that seems to be like custodian as one example. Consume the output from the policy report. And then in its code generate Oscar Jason XML YAML. How does the user fetch today the result via the CRD API. You use kubectl or other native tools right and kubectl. But you would use like pipe for example like because custodian is Python, you would use the Kubernetes I forget the exact package name but the Python wrapper for the Kubernetes API. There's a custom resource get custom resource list custom resource forget the exact name but I would call Python to get custom resource and pass in the name of the policy CRD. And then get all those fields from that Python API. Okay, it's going to call what I think I'm good point I think the point here is that and this need not be part of the CRD and I think that's what we're discussing. It has to be an helper function right that map somebody has to be able to visualize the output of the policy CRD to something tangible. And I think what I'm hearing is that what she's saying is something tangible is the Oscar format. I would not agree with that because I think it's tangible depends on who's consuming it right because tangible for a Kubernetes admin would be you know what they do through kubectl and they can see that. I think that's tangible for. Sorry. Yeah I just because what what kind of gave me some clarity. I'll have to leave I lead the call at 12 I'm sorry guys. No problem. Yeah, give me clarity Rogers I was looking at exactly this like how do I get access the reality is by being the custom resource and exposing that to Kubernetes as a customer resource you already get all the benefits of a concrete data element. You don't have access via the Kubernetes API you don't have to write anything special because like when I first went in this was like okay what do I have to write to you know do I have to write a controller do I have to implement something to get this fancy new custom resource. The answer is no because that's that's the benefit of inheriting all of that from Kubernetes itself. I'm not all I need to do is consume via the API, and then do something with that data. Right, and that would be some other tool can you know it could be an operator like the, you know IBM open compliance operator could be cloud custodian any other tool that wants to use the Kubernetes API and produce that mapping they're free to do that. That's right. And I wouldn't write a library that, you know, natively spits out Oscar, because there are libraries that other people have written most namely miss to manages Oscar. I want to be very clear that's not what I said, I'm not saying that the output should be in an Oscar format that's not at all what I'm saying. I think what I heard was that I think which is what Jim was saying is that maybe we should sponsor some helper functions right for people. I think the core of what we are discussing in terms of the CRD scope is perfectly fine. I don't think there's any disagreement. I think the question is once you have the CRD output, should we take the extra step of writing a showing a helper function on how it maps to Oscar or not. I think that was the, at least the way that I interpreted on this question. I kind of, I mean, the proof is in the pudding. Let's, I'll, I'll take a first stab at the, the code to do that. And let's see if there's enough there. I'm just assuming that that's like, you know, I mean, I guess not to trivialize it too much but that's like, you know, 10 lines of code. So maybe that's a helper function. If someone wants to abstract that into something. You know, more generic like an SDK, but I just kind of seems like I'm taking one form of JSON and stuffing it into a different form of JSON. So it's kind of just like, it's almost like rewriting JQ. I'm, you know, writing a JQ query and, you know, rearranging JSON formats. That's, so maybe, I mean, as a helper function there, sure, but I don't know that it's specific to this policy report. The same could be said for any custom resource. But yeah, the proof is in the pudding. Let me show some code. And then I think maybe that'll motivate. Right. Okay. All right, folks, I know we're over time. Thank you. Take care. Thanks.