Hello. Hi Anka, this is Jim. Hi Jim. We have a fire drill, fire alarm in our building. So I'll just be on mute and go to see what's happening. No worries. Okay, so I'll be on the call until I see smoke or fire. Okay. Yeah, hopefully you don't and it looks like. No, I think there are people moving in today and I think they hit something. Okay. All right. Yeah, looks like it's just us at the moment, not sure if Jaya or others are able to make it. Oh, Jaya is part of the office, so she will not be joining this session. Okay. All right. Yeah, and I know there were some questions and I think you responded from in a JS team also on GitHub. So I think, you know, and I took a quick look also at Oskal and some of the things around it. So, I mean, obviously, and from like your, like in your example too, it certainly seems possible to use Oskal to at least, you know, one section of it, right? Seems like the spec is fairly comprehensive, but the section that we were most interested in happens to be in the assessment results part, right? Yeah, we can start with that. I think the focus right now was on the results standardization. Correct. So that's why we presented only that. We are also working on the profile on the mapping for a product or service, the mapping from their components to the controls and dependencies, you know, inventory, you know, formatting as well. So all those are available. So I think when we discussed with Jaya and with the Red Hat management, the requirement was to come up with a phased approach. That's why we made the mistake in January with a different team to bring the whole framework and just run away in, you know, fear. You know, there's a lot over there for sure. And the other concern is, of course, you know, somebody's looking at this in Kubernetes, you know, obviously for consuming this in machines and tools, it's all possible, but for to output this in some, you know, format like a YAML, where the configurations or the report results are easy to read. I think that's something we'll have to, you know, look at more examples and see how that works. Oscar comes in all three formats. YAML, JSON and XML with the translations. So whatever we can get the others as well. Right. Yeah. So of course, yeah, if we have JSON, we should be able to output it as YAML. But what I mean is just in terms of the structure of the object model and things like that, right? So how does this, you know, like if somebody just is using a CLI tool and printing this out and trying to read through it? Is it understandable as to what, you know, what the results are? Some of the other things we had in our policy report, that structure that we were trying to define was things even like totals and, you know, kind of, just to, again, make it easy. Then there were things like categories and severity. So I don't know if we'll have to go through and see how all of that maps. So the severity right now is not included in that subset.  So this is what we, and the subject reference is to show the inventory evidence group. But if you go even more down, you will see that there is the threat and risk. So as part of risk, you have risk metrics. So that's where we put the, typically the score. But this is not part of the subset that I, risk is a, you know, yet another slice of the compliance. So I didn't want to, I try to remember if we edit the remediations or not to what I shared. So that's why we say it by piecemeal. So we can do observations with evidence without having risk and remediations. But if, you know, they are relevant and the team is mature to move into that direction and has already the logic to use that, yeah, they are part of the schema. So we can, that's the beauty, we can expand as needed. Right. So I think just to kind of, and maybe you've had a chance to look at some of these other samples, but like sort of what we were looking at before. Yeah, I looked at the, at the one with the summary. For us, the summary is a CLI that we do call, that we do on top of an assessment result. It's not part of the schema itself. Okay. Yeah. So this would be something, you know, it's just a very simple way of summarizing, you know, like what other results of some, some type of grouping of audits or policies. And then there's some details on each, right? But it's really just to indicate like a pass fail, you know, and, and then perhaps give links to others. So as long as we can, you know, if there's a way to map all of this and capture this, then of course, you know, I think going with something with a standard, which is already defined as a lot of value. So yeah, I think I see, you know, we discussed last time that having a summary is kind of difficult because it depends on the context. If I have a partial result, okay, you know, what does it mean that I have three pass and three fails and then I move to a, you know, more aggregated with others and I have different summary, but now actually I see how is used here because this is an example for one single policy. And I think this can be added because the observation is atomic. So we can get a summary to say, oh, this aggregated result for this control across whatever is in the observations, right, atomic with that control evaluation comes from eight pass to fails. And this is why, you know, zero warning, zero errors. And that's why it's a fail because it's eight passes and two fails. The 10 rules that I aggregate give me a fail because I have this eight pass and two fails. I think I can, I'll look how I can add this as a, as part of the properties or because that can be done. And that it's atomic is that observation is not something that is changing whether I aggregate this or not, that, that, that will remain the same, right, that grouping that, that generated for that. Correct. It makes sense. Correct. So this is like a capture of a point in time report for a particular set of policies on a particular set of resources. Like in Kubernetes, you're thinking of mostly of this as a namespace scope, right? So if I have a namespace and I'm applying, let's say, my pod security policies, I want to know a summary result for how many pass, how many fail. And then I have some details to go and, you know, figure out which rule fail, things like that. Okay. So if we are looking at the namespace, this means that our approach here is from the, right, what we call here subject resources, right, from an inventory point of view. These are my namespaces. What Oskal does, it approaches that from a compliance point of view.  So when I have the summary that I was talking about, that AC three fails, because I have this summary of eight passes and two fails, it would be at a three level. What you are looking is at the summary from an inventory point of view. So again, I think it depends who is the persona that the working group here for the result is targeting. If we target operators, of course, they cannot care less about the AC summary AC three, they are looking at namespace. So I think we maybe need to clarify what are the personas. Yes. So the two, the two personas we have talked about are, you know, the namespace. So typically it's an application owner that might be the namespace admin. And then there's the, there's the cluster admin, the operator, like you mentioned, right? So I think those are the two, somebody is looking at things cluster wide, but then there's also maybe like a sub admin or somebody who cares only about that namespace and they want a summary of okay, what are all the findings? What are the problems or issues I need to fix in my workload to be compliant? But will they be interested in looking from an operation?  Oh, okay. The alarm stopped. So which told me, tells me that it was okay. So maybe they're just checking. Yeah. Yeah. So what I was saying, oh yes, from a, from an operational point of view, I think we, we don't need OSCAL, right? We don't need the compliance approach if they are looking at what is failing in my environment, because it will not be only failures from the compliance controls point of view. It will be all their failures, right? There are other aspects then. So would it make sense then from a compliance, let's say compliance operator, to present the information from inventory and namespaces point of view, these are, because it will be misleading, right? Say, okay, this is what's failing in your namespace. Rather, I would like to have the operational operator to present those and here to really focus on the compliance aspects and, and focus from an, right, policy approach or control approach. Okay. So, so what you're, if I understood correctly what you're saying is with OSCAL, it's more you're going through each control or each, you know, policy and you're saying which, you know, workloads or which let's say, let's take pods as an example, right? So across my cluster, which pods are compliant, which may not be compliant. But is there, so then it's left up to some external management system to say, okay, if I want to narrow that down into a subset like a pods within a namespace, they have to kind of go filter through the results and figure that out or, or how would that be done? Exactly. So the, again, is a question of, you know, our goal and how I traverse this JSON to extract what I needed. By default, OSCAL organizes the result per regulation and per regulation controls, rather than per inventory and, right, namespaces or clusters or things like that. We have another, another schema, which is the system security plan, which is the one that includes the scope, the inventory, the subject references for which the assessment is done, right? So that can be the format for the inventory. And then we can extract from the assessment the summaries at that level. So there are different ways to slice and dice here, but the schema itself will provide natively the information per control posture. Hi, Gus. Thank you for joining. Hey, Gus. Hey, Gus. Sorry, I'm late. I am, I'm, if you, if you would like to have some introductions, my name is Anka Seiler, and I'm in IBM Research, and I have been introduced to this work group by Jaya. So I'm working with her on the standardization of the result for the ACM in Red Hat. So that's, you know, how we, I'm not sure if you've seen the recording last time, we introduced the recommendation of result standardization based on subset of OSCAL assessment result. Right. Yeah, that's a good intro. Yes, I work with Jaya. So You are in IBM as well? Or Red Hat? Red Hat. Okay. Red Hat. So yeah, I'm familiar with the sample a little bit. I took a quick look at it and saw it. It was, it was big. So it's big, but nothing mind-blowing. I mean, it's really, you know, pretty straightforward. Okay. Yeah, if you look at this in this format, I think it's difficult. But if you have a JSON editor, you would see there are four parts. There are the properties. There is the evidence. Yeah, exactly. Yes. Okay. Right. So findings are by control. So in each finding, I have one objective status. So then objective status, you see the control AC3 with its aggregated status. And then in the observations, I have all the rules, goals, CAS benchmarks, whatever this control depends on for its status. What are the rules that map to the description of AC3? What are the rules that implement the policies that implement that AC3? So in the observations, which is the last object in this item, you will see all the, because this is a result for the compliance operator, these are all, right, CAS Kubernetes benchmark provided via the OpenSCAP in XACDF format. And we present them here in the OSCAL format. So you see the observations and they have properties, evidence, subject references is inventory, meaning what is the VM, the cluster, the region that I'm getting this rule for. And the observation method is it's automatic or manual. So it's very simple structure. Okay. So this is the campus sample, you know, current format of the response that you get or the results for OSCAL, I guess. Yeah. Yeah. And prior to you joining, we're discussing with Jim that OSCAL, of course, allows for additional aspects, right, besides the evidence, these are the basics, right? You need to know what is my, what is my subject I applied this assessment to, what is the evidence that I got back, and what are the, you know, properties and annotations, what is the test ID or the, you know, time of the day, you know, whatever the XACDF may have their own properties. If we use some other assessment tools, they have other properties. And then we aggregate all this observation to generate per control, its aggregated status. But there are other aspects that we can add to that, like remediations. In our tools, for instance, we use remediations to provide what are the tickets that have been opened when, you know, this failure occurred, what are, what are the script's path in Git or other systems that would run, I need to run manually or automatically or, and the other aspect would be risk. So depending on the, with the score and, you know, so depending on the maturity of the tool, right, this can be adjusted to provide a result that is more or less complex. Yeah, yeah, that's, that's great. That's exactly the types of things that I think could be captured in the policy report. Yeah, I was pretty happy with that she's on board. This is why she brought me in this group to, so the recording from last meeting two weeks ago, it goes in one hour of details across the, all the fields and objects here. Yeah, so certainly this seems very comprehensive. And I think it can cover pretty much everything that we and sort of, if it's extensible to properties, etc, we can even model other fields. The one thing we were discussing, which is an interesting point is like who, you know, it's obviously a compliance report, you know, could be sliced and diced in many ways and consumed by different folks. I think where we started with the policy report was we wanted at least a namespace owner or like a workload owner and the cluster admin to easily sort of view the output of various policy engines, right? So the question is, does this become, you know, in YAML format, would this be overwhelming or would this be, you know, simple enough to understand? And secondly, would this be presented at a cluster wide scope? And then how do we, you know, if we want to present something for a namespace owner inside the cluster, like as a CR, is that something else? Is that a subset which takes from this information and creates a more, you know, simplified report for somebody running an application to say you are your, you know, compliance issues you need to fix in your workload with pod security and things like that, right? Because where we sort of were previously, you know, just going back and browsing at samples was something like this, which was, let's say, then this is if it's a CIS benchmark, we're saying there's two, you know, failures and we're just giving some summary information. But of course, as we kept working with this, there were more and more things that folks wanted to add, right? So I'm sure over time, over time, we would end up with something perhaps at the same level as what's in the OSCAL definition already. So it does make sense to adopt that as much as possible. But yeah, how do we kind of, how do we sort of ratify the two views, right? Are they can, I think what I was just discussing with Anka was like an OSCAL and I think what you clarified, Anka, was OSCAL is more on the, for the compliance admin or somebody looking at compliance, it's giving their view for each control and, you know, what happened for each resource in that cluster. Yeah, yeah, a compliance engineer or a compliance officer, I think more engineer because that's really down into the operational details than an operator, which would want to see really the aggregation only at the AC control level like AC3 here. I think what we can do is to use this model, this data model to generate and store. And then we can have additional functionality, right, CLIs that will represent the capabilities for the various other personas. So like what you said is, you know, give me the, Well, one name space, yeah. Status per name space or per cluster. And that would be a reshavelling of that, right, where the subject reference will be now the root and then the controls will become the leaf that are associated with their status under those. So once the data is in and, you know, being JSON, it can be reformatted as we need. That would be, for me, additional capabilities as we have other personas. Right. So kind of, so then you're saying like a CLI or whatever, some tool can take the raw data and format it and output it in whatever report format. It will be totally transparent because right as I use the CLI to, you know, get my assessment result per controls, get my assessment result per name spaces, get my assessment result. We don't know, you know, how this is stored behind the scenes. Yes. So is there like with any Oscar implementation or are there, well, so right now there's nothing for Kubernetes. By the way, I saw there was somebody who had done some implementation for Docker. Have you seen that before for the container engine? No, where? Meaning that they express the Docker CIS benchmarks using Oskal? Yes. I will not be sure. What they've done for OpenShift compliance operator, right, which is Kubernetes CIS benchmarking. Yeah. So I don't think Andrew is a bit Docker anymore, at least when I was checking online, but this was, and this is about two years old now, but there's some attempt at taking Docker output and converting it into Oskal, right? So, but yeah, I couldn't find, and there's also like a Go library, which I think also was developed by Andrew for managing Oskal formats. So could be, yeah, maybe, you know, so I'm not sure where, if Andrew's still at Docker or I didn't, you know, or if he's somewhere else, but it would be interesting to see if we have some touch points and if there's any other ongoing activity with this, right? We have a Git that is available for that. So to see if we are still active. So I saw this, and yeah, it's amazing. Nine months ago, okay. Right. So it wasn't, so I was calculating. Oh, three months ago. Okay. So it's, okay. So there is some CLI, but some conversion and other things it does. And I think this is all written in Golang, it seems like. Right. So, yeah, maybe we're following up and reaching out to see if there's any activity or Yeah, can we go into the CLI to see what would they, the second folder from the top, I think to convert, generate. Okay. So open controls is the original format for the compliance automation before we had OSCAL. So it's a subset of OSCAL. I would say it covers about maybe 10, 15% of OSCAL. So because the people were really looking into continuous compliance automation and generation of documentation for fire, call fire and PWC, they used open controls to automatically generate that. And now there are converters between open control. So he is into compliance schemas to the core from the very beginning with the open controls. Okay. Yeah. And I see this gentleman who has also committed to the repo is, it looks like he's from Red Hat. So maybe, so that was the one, yeah, the latest commit here. Right. So we had, indeed, in February, we had a major change to schema. We worked closely with David and in the OSCAL team in East, and we provided our feedback that is too much nesting, too much, you know, levels that were really not necessary and made our non-SQL kind of explode. And so they reduced many levels of nesting. So it was a major change in February. So I see they keep it up to date. So they updated their... Yeah, looks like, yeah, this person from Red Hat was the latest and probably the highest amount of commits recently, right? So is it possible to reach out and see if there's interest in, you know, somehow working with this or mapping this to Kubernetes and what we want to do? Gus, is the name telling you anything? It's not someone I'm familiar with. I can look around to see if I can find a way to contact them. Yeah, maybe good if they're open to coming into one of our meetings and just discussing what their thoughts were. Is this actively maintained? Can we leverage it to achieve some of what we want to do? And I'm assuming if we, what we're talking about is saying, is there a way in Kubernetes to generate or to at least create like a custom resource which would be compliant with the Oscall format, which different policy engines running inside Kubernetes could then create? Yeah, one question and a concern which had come up in the past is like, how much data would do we store inside the cluster versus, you know, so at least our thinking was that we would just store the current information inside the cluster, any history, et cetera, can be managed externally. But then it comes down to, okay, what can we do with the data and can we create, either we create other resources from this main report or we have other command line tools, et cetera, to output different formats? Storage is an important one. So this was CLIs, okay. So yes, the storage, depending also how it is stored, we store it with versioning. So we keep only the Delta, but still it can explode if there is a large cluster and so on. So the way that we manage is that we declare TTL in our component definition. It is the format that allows a vendor to describe how their product services map to controls with, you know, their properties. So one of the property that we leverage there is the TTL. And then we provide across, let's say, an inventory, what is the lowest TTL so that we make sure that we collect the data before it disappears from the, so we do not expect Kubernetes to, because we have regulations that require to keep the information five years, right? So the Kubernetes, this way we decouple, you know, the expectations or the requirements on the infrastructure itself and the regulations, expectations. So you can leave it on Kubernetes for as long as you want. And we expect that it's in component definition that is declared. It is there only 24 hours. And then we know that we have to harvest it, you know, daily. Right. Yeah, that makes sense. Because we wouldn't expect the cluster to, so if the cluster just has the current copy and some, you know, well-declared or well-defined TTL, like you're saying, then some upper level management system can do the rest. Right.  So we don't keep... Right. And just so again, what we're talking about here is that only from all of these definitions, et cetera, we're really talking about, and I can't find where it is right now, but somewhere in here there's the assessment results, right, is where that's what we would store inside the cluster. You cannot see it because you are at a lower level here. You need to go in the left side, you go above and you see assessment result layer. Oh, there it is. Okay. Above. This is just the assessment layer. The assessment layer is your, the tuning for what you expect. Yeah. So that's the... Let's see if we go up. So I thought there was a picture which showed all of the blocks, okay, root metadata, body. All right. You have to go down into the page. Yeah, this one. Yes. All right. So we see assessment. I see. So that's the only layer where the results is really what we're concerned with. At the moment, everything else could be is managed again externally or based on the policy engine or whatever tool is being used. All right. Because right now we are looking at a unified pane of glass to show the compliance posture. So then we expect that the assessment results are aligned. If we want to move into having the inventory presented in a unified format and consume from those various layers, their inventory discovery rather than discover it as the top level, then aligning the SSP in green will allow us to consume that. So again, it depends on the maturity of the framework that we implement. Right. Yeah. I think we are at least our current focus is on the assessment layer. And of course, Kubernetes has its own schema and ways of defining resources. So we don't need to necessarily re-represent all of that inside the cluster for sure. But yeah, if there's a way to, then the idea becomes, can we map this into a Kubernetes resource? So currently, when you're generating this for clusters, is it being mapped to a custom resource inside the cluster or is it just generating some JSON or XML which is consumed externally? Can you rephrase the question? So I think from the work you're doing at the moment and when you're applying this to Kubernetes clusters, has anyone on your team looked at creating a custom resource definition in Kubernetes? Oh yeah. So we have a team that is looking exactly at that and creating the custom resource where we generate the compliance operator model. We generate the assessment result in this format. Yes. So that's exactly the goal. Okay. But this is part of the offerings of IBM Cloud, ROX and IKS. It is not part of, we are looking now to converge with Jaias, ACM, and there is another lady there, Christine Newcomer, that is responsible for a customer, I know better, right? Christine is working with the compliance operator. So we want to align those efforts so that we have the same format, but definitely custom resources is part of the roadmap. Okay. So but that is not something that is open source or yet? Not yet. All right. So I think maybe what makes sense is, you know, just so that we frame our thoughts, what I'm thinking is we could, you know, and happy to outline this, but I think I'm going to try to interrupt. The compliance operator is already open source and it has custom resources for what it does, right? Just at the output that it has is not aligned with the OSCAL assessment result. So one effort is to align it with the assessment result. There are other efforts around custom resources to align also the inventory and other aspects to that as well. But the only CRs that we have today with respect to compliance are open source, but they are not OSCAL. So all this is roadmap. Okay. Yeah. So thinking of what, you know, we can do in this work. So right now we have this proposal for a policy report, which is a fairly simple, you know, kind of custom resource in Kubernetes. And like we talked about, the focus really was to try and, you know, this is for the cluster admin as well as the workload operators or the workload admin who are operating at a namespace level. So I think to kind of just clarify thoughts on how this, you know, how we can converge or how we can move forward, maybe it's worth just drafting a simple proposal or design proposal, right? And saying that, look, if we want to adopt this OSCAL assessment results layer, what would be the pros and cons and how it would work. And I think what I gathered from our conversation today, the way it would work is there would be one sort of OSCAL formatted output at the cluster level. And from that we could have like command line tools or other tools which can extract the information and report the information they want. So if a namespace admin wants to say, okay, give me the report for this namespace, they would have some way of, you know, generating that. Or maybe we have an operator or a controller running in Kubernetes which also generates some subset and stores it inside a namespace, right? So there'll be some duplication, but maybe, you know, that could still be done, right? Because then for access controls and security, a namespace owner doesn't have to, you know, be able to read the full report. They're just seeing some subset of it formatted in a simpler way. Can I ask a question? Yeah, of course. I want to make sure, because we talk about a lot about the summary and the status and so on, which is the control posture. Together with the schema here, we also have the evidence. So when we talk about policy result, is this team having in mind both aspects of posture and evidence, right? Keeping in mind what we discussed earlier that the evidence doesn't need to be stored there for five years, but it's, you know, or is the focus strictly on posture? So I, you know, I don't fully understand the difference between the two. So maybe... So the result, right? The posture is pass fail. Without the drill down on the evidence, right, on the, you know, messages that are associated with that and so on. So in the, if you look in the OSCAL format, you see I have evidence, what I have, sorry, I have the control status, right, which is pass fail, but then below I have the evidence group, which I give the details, right? So I wanted to make sure that we understand the difference, whether the Kubernetes team is looking for having both or not. So I think what we had discussed at one point is to try and again, and there was some concern about how much data we store, what we need. So every policy engine or every sort of scanner may have its own, you know, details, right? So the intent was to store more, I think, from the terminology, the way, you know, based on your explanation, more of the posture and then have some link to go and say, okay, if you need the evidence details, and that could link to some website or some other tool or some management system, which has more details. But really the problem we started out trying to solve is there's a growing number of policy engines and whether it's image scanners, configuration scanners, admission controllers, runtime security tools, and all of these are currently producing outputs in different formats, right? So for a cluster admin, it's like, okay, I have 80 different things to look at to understand what's going on. The intent of what we were trying to do is how do we standardize that format as the policy report? So even if we have some high-level summary to say, hey, on CIS benchmarks for Kubernetes, you got an A plus, but on pod security, you got a B minus and here's the namespace that's violating it, right? So something like that. And then, of course, you would have to dive into individual tools to get to more details. But starting with that summary is what we were trying to solve. Mm-hmm. So let's say my policy validation does not complete. So I do not have a pass or a failure, but I have an error, right, because I cannot connect. And I'll have a message associated with that, which will be part of the evidence, what I call. So you don't see this as part of my result, pass, fail, error, but should be a link to some other repo or, you know, must be. So we did have a message field, right? But the intent was this was not, this would be like a brief message with pointers to more details, right? But yeah, so, yes, it's a little bit fuzzy. So we did have in the, so the way the structure was is there's a policy report. And then there's a summary section, but just gives you a score. So you can convert that into a grade or some simple way of knowing. So a policy report could be at different scopes. The scope could be a namespace. The scope could be the entire cluster. The scope could be just one deployment. It's flexible, right? Yes. But then each result could be, you know, could also point to a rule. So this was the rule or control in the terminology, the Oscar terminology. And then it would have a message. And then status, which would be pass, fail, warn, error, skip, or the five, I think field, you know, and then whether it's scored or not. And then additional data, which is just some free form data. Yeah. What we call properties in Oscar. Right. So that was the result structure. And then you just have a list of these results. And that's, that's kind of where we were, right? So, yeah. So I think it, this, this introduces additional challenge, right? So now if we are, I understand for the, you know, storing local and using it local. Now, if, if I use that in an exchange, right, protocol with some other tools, whether they are, you know, governance tools or, you know, UI tools to display, you know, aggregators, the question is, now I have to manage the access not only to my environment, but also to that repo, where the evidence link in, in this format here is, is provided, right? So the more references we bring into that, right? It complicates the access. Yes, I think there is a challenge between being complete and being concise. Right. So how do you, yeah. And it's a good question what that balance or where that line should be. I'm wondering if it's not an advantage actually, because that evidence is the critical sensitive data. So I may need all together a different level of access than what I need to get the posture. Okay. Past fail. I can work with whatever credentials I need for my, you know, view my cluster, but then this separation will enforce a level of security on the evidence, which is my sensitive data. So maybe we turn that into an advantage and we make it more compliant. You see what I mean, Jim? This will force people to have a different access model to data that is more sensitive. Right. So if the evidence is, so is the evidence more like how the check was performed and details of what was scanned, things like that? No, the evidence is the actual message, the actual result, the actual API reply from the policy check or, right, it's the actual evidence. Evidence sometimes may even contain PI, right, depending on, you know, what is run there. I think I like very much your suggestion to have, to have the evidence by link. It doesn't change the structure of OSCAL, but it is just brings that my evidence would be, I'll use the href rather than having the whole information there. Right. So if I, but let's say if I'm, if I'm managing or if I deploy some workload, right, and that I have some pods which violate some security policies. So I'm seeing my results, it's telling me that, you know, but with the message here, then at least give me some information that this pod requires, let's say, run as non-root to be set to true. Would that be considered evidence? So the evidence would be, let's say that these are all CIS benchmarks, and that they are generated using compliance operator that is built on top of openscap. So the means by which I do the assessment is by running openscap, and I have the logic to check all those CIS benchmarks. So what I get back is that basic authentication file argument is, is not set, right. This is the message that I get back. And this is the evidence, while the, the status is pass fail, right. Now having pass fail, right, is, is one thing or error, right. And then the message is something else I wasn't able to reach or, you know, the, I don't have access or, you know, whatever, whatever it is. It can be that that message for some people is very sensitive. I don't want, you know, maybe this to be in a place where the operators can, can see that and make public that because this is maybe a breach that can be immediately leveraged to, to some damage in my environment. Yes, you're right. If somebody gets access to the cluster, you're telling them exactly what. Exactly. That's my point. So I think I like to pass it by link. So instead of the message here having this to say evidence is this in this age ref, and this is, you know, a g triple with a different level of access, so that only the, the people that I control can see that data will get access to. But if I want to, let's say, but again, like taking the persona of like a workload operator or user, I want to know what. So, so if I'm treating this as things I have to fix to be compliant, what is the easiest way to. So, and again, this could be combined through a CLI tool. So the CLI tool could go fetch that message and that information and or which is perfect. It means that if that person has to do remediation based on that, they will be approved to have that access. What I try to say that we bring into a picture, this, you know, this minimum level of access that is one of the, you know, controls that everybody wants to have. This will support implement that minimum level of access. If I'm an operator that I need to, maybe I don't need to have access, let's say I have 10 repos, one is for network, one is for DevSec, one is for IKS, one is for storage, and they will all have different levels of access. So I'm not going and poking on, you know, what are the failures on databases policies, right, because I'm only responsible for network. So I get access only to that. Okay. Yeah, and that would help sort of keep at least this portion, keep it more concise, right, because otherwise you're repeating the same message. And it keeps it more concise. So what it started as being an inconvenience, I think it's actually a good thing. Yeah. So I hear you are hesitating, Jim. So what is in your mind? Yeah, I'm just kind of thinking about the user experience and if there's some, you know, like a CLI tool or something, which can combine that and present it in a manner which is actionable, then it's fine.  So that's the trade off. I think we'd need to think through, but I definitely have some interesting pros and cons. I can see that CLI like, you know, get the assessment result and I get my assessment result and now I say get my evidence for this assessment result for these credentials and the CLI is intelligent enough now to apply my credentials across, you know, everything, but my evidence will come back in this assessment result only for the items I have access to. The other ones will say, you know, no access granted or something like that. So if I'm a network person, I'll see all the policies, evidence for network, but not the one for databases. Right. So this was your concern that we will need, right, definitely we'll need to have the capabilities to allow the operator to complete their job into remediation or exception, whatever they need to do, right, definitely. Right. But now it would be not in one pass, it would be in two passes, right. Sure. Yeah. Yeah, and certainly I think we could, if there's tools to combine that and if somebody wants, you know, to just output everything into one report that can be done and there is some, yeah, definitely the security benefits are interesting, right, and just a separation of concerns there. All right. So yeah, I'm still thinking maybe the best next step is to try and formalize some of these thoughts into perhaps, you know, kind of a document or some structure and then we can see, you know, if there are folks who are interested in working on various pieces. Do you have a template for this design proposal? Hi, Jay. I've seen you joined. Hey, Jay. My name is Anka Saylor and I'm in IBM. I'm working with Jaya in the Red Hat. So she invited me to share on the OSCAL result format here that we used. Oh, yeah, I just joined late, so I was just eavesdropping. Are you with the Red Hat as well? You know, I'm ex-Red Hat. It's weird that you asked that question. I worked on it for like three years when Kubernetes first came out, but now I'm VMware. Okay. Nice to meet you. Yeah. Quick question, which is SIG network related that might be a collaboration across us, but I don't want to interrupt this conversation. So maybe after it's over, I can ask my question. So maybe just to wrap up on that, what you were asking Anka, so I can share like the format we used before and there is a link somewhere in our repo for the policy. So it's very informal, right? There's no one standard format or anything, but it's just some typical sections that we have seen in most of these type of proposals. And happy to kind of, what we can do is maybe we can just at least capture some sections and, you know, try and just maybe from a thought process and point of view that will help us frame some thoughts and ideas and kind of be concrete about what we want to propose. Yeah. I will start with a draft based on everything we've discussed today, with the, you know, personas, CLIs, personas, storage, the different levels of access and so on, summary. So put everything there and we can refine it. Maybe offline, I guess. Okay. Good. Okay. So Jay, just looking at your question in chat, so from the DNS policies. So we have not discussed that before in this working group, but that is super interesting. I know that there was some work done with core DNS and OPA policies. So I had read something about that and we had discussed that also in the multi-tenancy working group. So what did you have in mind? Yeah. So, okay. So, yeah, we started the SIG network, network policy API group about, really, it was about six months ago unofficially and kind of more officially in the last couple of months.  And it turns out that most people want policies that are way higher level than that, right? And so we have all of these, like, user stories that we've, like, that people have given us over time, which are, I think kind of, I'll just, you know what, I can link you all to them, policy that are just a lot, a lot higher level than what, you know, the SIG network is really capable of supporting. And I was like, well, at some point, rather than just always bike shedding about whether or not we can do this or not and whether it should be in the API and whatnot, I feel like, you know, I'm like, well, I feel like we're kind of like, you know, we're kind of like beating around the bush instead of actually solving the actual problem, which is creating a more unified network policy, like lower case, you know what I mean, like a unified network policy model for Kubernetes clusters, like, you know, which a lot of the implementation details might be implemented by SIG network using our network policy API, but like there's a higher level layering for DNS being a great example, where people want to very simply say, I don't want people to access this site. And a lot of that could be built with controllers and operators, right? You could presumably envision a world where you could query core DNS, you could take information about, for example, services is another one, right? Look at Kubernetes services, create a network policy against the service. Say I don't want these pods to access this service. That's not supported by the network policy API. But again, that's a use case for an operator where you could look at pods behind a service and then create those more granular rules underneath. And so I just think there's a lot to, there's just a huge impact to be made there. And I wanted to make a little sales pitch around it. I mean, we have, I know a few people personally that would be interested in working on this, but I wouldn't want to go down this road alone if nobody, if everybody else only had passive interests. So what I'm looking for is active interest in this, in designing something like this, prototyping it and stuff. That's kind of where I'm at. So just planting the seed. I know it's the end of the meeting. I don't want to like dump decisions on you all, but that planting the seed and we'll see where we can go from there. No, that does sound interesting. And so, and maybe it's something that if you want to also share on the Slack channel, right, so folks, and we can update the meeting notes and we'll have the recording posted. So I think it'll be good perhaps even in our next meeting to sort of revisit this since we're almost, I guess we're over time right now. But yeah, that's some interesting ideas, things we can also think about. And I'm not sure if you're, you know, looking at more like constructs like custom resources or external policy engines and there's all sorts of interesting things to dive into. So yeah, any canonical solution will work. It doesn't have to be an API. If you want it to be an OPA thing or whatever, I don't care if we had some centralized place where we could build those higher level policies. It would just, yeah, it'd be really cool. Okay. So yeah. So next time we can talk more. Sounds good. Thank you for sharing. All right. So yeah, uncle, we can collaborate on the document maybe as an action item for the for next time. And then also we'll I'll put this topic on the agenda for our next session. Okay, excellent. Thanks everyone. Thank you. Bye. Thank you. Have a good day.


I'm going to be talking about employment-oriented social protection, and in particular the National Employment Guarantee Scheme in India, and the targeting the ultra-poor programme in Pakistan. Now there is a very sound rationale for focusing on employment orientation, because of the fact that we are in a part of the world which has had quite strong rates of growth, but it has been described as jobless growth. It simply has not generated the level of decent jobs that would help to pull large sections of the poor out of poverty. But it isn't just the deficit in jobs that is a problem in South Asia. It is also the problem of intersecting inequalities of location, caste, gender, ethnicity and so on, and the ways in which these trap people in chronic poverty over generations. And because of the scale of the problem, we have to remember that only about a maximum of 10% of people are in formal employment in South Asia. The scale of the problem means that we cannot talk only in terms of social assistance. So the language of protection and promotion is one that has originated from work in South Asia, and it refers to finding forms of protection that contain the potential for helping people to climb out of poverty, what are called opportunity ladders. Both these programmes are relatively new, as part of the emerging, but interestingly both of them have their roots in other programmes that go back many years. So one of the first points I think I'd like to make is that policy continuity is really quite important in the field of social protection. Partly because you need to institutionalise social protection and introduce a bit of predictability in the lives of people who are living very insecure lives, but also policy commitment allows for learning from experience. And both the programmes I'm talking about are the products of quite a lot of experience. So the NREGS has its origins in the Maharashtra Employment Guarantee Scheme that was put in place in the state of Maharashtra in 1978 after some major droughts. And that introduced the idea that the government had a legal obligation to provide employment on demand if a minimum of 15 people within a locale demanded it. The employment had to be provided within eight kilometres of that locality and within 15 days or the government could be taken to court and an unemployment benefit could be paid. It required equal wages for men and women, on-site drinking water, childcare and first aid. India has had many other employment public works programmes, but it was not until 2005 when the United Progressive Platform came in that the idea was that the government could be taken to court and an unemployment benefit could be paid. It was until 2005 when the United Progressive Platform came in that the idea of an employment guarantee was revived, this time at a national level. So the National Employment Guarantee Act built on the Maharashtra Scheme but added a few features which were lessons learnt. One is that it limited the guarantee of employment to just a hundred days rather than indefinite. It required state minimum wages to be paid. It banned private contractors in implementation and put the locally elected officials in charge. And it had, because of the process deficits that have been documented, it had a number of accountability provisions such as the right to information about documents, the public payment of wages and social audits. Later provision was made for wages to be paid into a bank account and according to the website wage employment in 2013-14 was for over 73 lakhs, a lakh is 100,000 individuals of whom 48% were women, so much higher than the quota. Bangladesh has also had public employment programmes and in fact in the food crisis of 2008 the government hurriedly introduced something called the 100 days employment. But it was very hurriedly implemented and it is to another programme, the rural maintenance programme, that we might look to see how lessons are learnt over time. The rural employment programme was the product of a pilot in 1983. Bangladesh is a country where women are not supposed to work in the public domain. And the existing food for work programme, many women were turned away because officials didn't approve of them, others didn't even come forward. So they experimented and then built a rural maintenance programme which was meant only for what we call destitute women. Either women without husbands or alien husbands, women who are primary breadwinners. And these are about maintaining rural, urban works all year round and they provide work to tend astute women per union. And because demand outstrips supply, the women are chosen by lottery. There is a mandatory savings provision, about a fifth of their wages is put into a bank account, which they can't touch for the four years that they are on that programme. And regular training was added over time, first of course in road maintenance, then in health, social awareness and then in business and financial skills. So around 42,000 women were provided employment each year and in 2006 the government took it over. It was managed by Care International till then. Targeting the Outrepoor also has its origins. This time in a vulnerable group feeding programme that was put in place in 1975 after a major famine which evolved into vulnerable group development. Brach and World Food programme got together to add an income generating component to the vulnerable group development programme which had provision for giving women access to loans, microfinance, training and so on. But it was found by the end of the 1990s that the extreme poor amongst these groups were simply not benefiting. They were dropping out, they were not taking advantage of loans and so on. And so in 2002 we got the targeting the Outrepoor programme, which I think is a very good example, a paradigmatic example of a programme designed to overcome the multiple and overlapping constraints that make up the gendered nature of extreme poverty in Bangladesh. So it has a mixed methodology to identify people, it has a transfer of productive assets plus a cash stipend so that women can focus on their enterprises rather than having to do wage work, health support, mandatory savings, training and mentoring, intensive mentoring. I persuaded the brag officials not to call it handholding because that sounds a little patronising. So we call it intensive mentoring and elite support and by 2011 it had reached 400,000 women. Now when we talk about sustainability, when we talk about sustainability obviously the financial aspect is very important. Because I think this new generation of evaluations which point to the wider impacts of social protection are very important in justifying these programmes. And what we find with the NREGS is that because it's been scaled up to the national level, very mixed outcomes, however while we see evidence that there is some rationing of jobs because demand outstrips supply, it is reaching the poorest groups and it is very effective in reaching the tribal and Dalit, the lowest caste groups. And as we saw women make up far more of the 30%, it has had significant poverty reducing effects particularly for the poorest, changes in people's lives and sending children to school and so on. However one of the more negative depending on which side of the debate you are aspects of it is that it seems to be driving up agricultural wages. Particularly female wages which is not so good for farmers, small farmers, but it's very good for agricultural workers who are amongst the poorest paid in the Indian economy. But it's not clear if the wages are being driven up by market forces as someone has suggested or by actual active bargaining. Certainly the Maharashtra Employment Guarantee scheme documents many examples of workers being empowered by the scheme to bargain for their higher wages. There's been the decline in the stress migration in West Bengal and these are the state level findings. And also interestingly given what we've been hearing from the others, participation in the NREGS results in better educational outcomes for children, particularly girls. Over and above the income effect and it seems to be related to the increase in bargaining power, decision making power within the household. While far this participation is associated with negative educational outcomes, particularly in poorer households. Of course the process deficits continue, we have 40 muster rolls, long delay in payments, corruption and leakages and so on. But as one of the less positive evaluations concluded, despite this what we need is an overhaul of the governance of the programme. But that sense of entitlement that it has instilled in very poor workers is one that needs to be valued and built. Development potential of public works, there was a very interesting study a long time ago about the local economy effects of the Food for Work programme. Wage employment increasing, self-employment declining, agricultural production increasing and so on. Nothing of this scale has been done more recently, but the care evaluations of the road building projects show overall increases in commercial freight and passenger volumes. And that while men continue to make more use of the roads that are built, the rate of increases is much higher for women. And in particular women's access and children's access to school, health clinics and NGOs have been improved by the building of infrastructure. The other evaluations of the rural maintenance programme show what it does for individual women, that many of them continue to earn what they were earning on the programme after they've left and are able to provide means for their families. And a recent study by If Free says that both the IGVGD, BRAC's and the RMP resulted in longer term improvement in the income of participants which lasted 18 months for the IGVGD and 25 months for RMP. They also found, and this is interesting, that the two public works programmes they evaluated, road maintenance and food for assets led to far more positive outcomes in terms of women's empowerment and that we're talking about decision making, mobility and so on than the IGVGD which was promoting enterprise and self-employment. Looking at the development potential of TUP it has also benefited from randomized control trials built into the programme from the outset. So anybody who's anybody I think in the RCT field have come in to evaluate the TUP so we've got people and the pilots. So we're finding very positive outcomes, the first round of studies three or four years after the programme was put in place and the programme is supposed to graduate women out of poverty in two years through this combination of supports. Found higher incomes and greater livelihood asset ownership. The second round found that, which was actually carried out by the IGC at LSE, found that women were moving out of poorly paid wage employment into more regular forms of self-employment and that total earnings rose by 38% two years after they had graduated out of the programme and savings were also increasing. There was some evidence of a rise in wages for unskilled wage labour, female wage labour. However a much more recent study finds that the impact of women's ownership and role in decision making does not extend beyond the assets transferred by the programme. All other assets and all other forms of decision making are under male control. And it appears in fact to have had a negative impact on women's control over income savings and expenditure decisions. Although the qualitative data on TUP shows something more positive and that is women appreciate having work within the home because of the hostility of the external environment to women. In terms of the questions that we were asked, I think the fact that we have public works programmes across the world more or less successful suggests that they are scalable and transferable. Provided of course the administrative and logistical requirements are met but the issue is how transferable and scalable is the employment guarantee and that really is a very different kettle of fish. The move from the Maharashtra scheme to the national scheme is an example of both transferring to other states in India and scaling up but it has met as we know with problems and very uneven performance across the states. An employment guarantee needs a responsive state and active citizens and these do not always exist. But I think the question we might ask is could it act as a catalyst to building more responsive bureaucrats and active citizens. And I say this because the Maharashtra employment guarantee scheme has many examples of wage workers becoming more active, of civil society organising poor people to demand wages, of putting pressure on local officials and so on. So going back to Corshik's talk yesterday about the focal point, which I don't like that word very much, it means something else to me. But anyway this business of creating a legal obligation can it generate the kind of impacts or the kind of outcomes that we want to see in terms of states and civil society. I think there is a very interesting comparison that McMore makes between the Maharashtra employment guarantee scheme and the employment assurance scheme in India which is just like the Maharashtra one but without the guarantee. And you find no evidence of mobilisation around the employment assurance scheme but you did find a great deal of mobilisation around the Maharashtra one. And you do find it around the NRAGS. Transformity scalability, we're looking into TUP, there are pilots being carried out, ten pilots in eight countries across the world. And I said, as I said, there's Esther Duflo, Brigitte Balergy, Dean Carlin, all the people who have been leading on the RCT field are involved in these pilots, in evaluating these pilots. And the results are coming in, they can help us a little bit with the transferability question, not scalability because these pilots are very small. But as a recent conference in Paris reported on the BRAC website, four out of the five RCTs showed increased food security, increased as well as more diverse incomes, increased assets, all in all, we are setting the stage for further explorations of scalability. However, some caution is needed. The four out of five were positive, the one that wasn't was in Andra. And it found that the income that women made through being involved in the TUP programme was offset by the income they lost through withdrawing from wage employment. And this of course is at a time when wages for agricultural labourers were rising partly because of the NRAGS and women's wages were rising. So, as Modoc says, you really do have to look at the larger opportunity structure in order to decide whether providing women with these opportunities is the most feasible way of helping them. And certainly in Sydney, where we did an evaluation of TUP, we found that there was no wage labour for women, but also that women's earning capacity and mobility capacity were so restricted that all they did was basket wheeling and embroidery. In that context, it was women who had husbands who could make use of TUP support that were able to benefit from the programme. And then a very recent study of the Bangladesh TUP finds that six years, so by the era the LSE studies were four years after, this is six years, that 54% of TUP households had experienced a decline in asset stock and income. And of course the SINTH and other studies from I think Haiti tell us that those who have some kind of initial advantage are much more likely to benefit. So there is uneven impact even within, across countries and amongst participants. And then my final point I think would be that some aspects of TUP are easier to transfer than others. The intensive mentoring, how easy is that to transfer? The fact that the West Bengal study that we did was carried out by an organisation that was very responsive to the needs of the poor, had worked with extremely poor women and self-help groups for a long time, made them manage and negotiate the TUP programme much better than the SINTH one where it was being managed by a microfinance programme whose only experience was with male entrepreneurs. So to that extent I think that the skills and the human element of the programme must be taught through before you think of transferring. So my conclusion then would be, my reading of this literature echoes a debate that took place in the Indian literature around the time of the integrated rural development project etc. And that is to say at that time credit interventions seemed to work best for those who had the complementary resources you need to make use of credit. Those who were asset less were most likely to benefit from wage employment. Today we're looking at self-employment enterprise development for extremely poor women. And the literature on enterprise is always looking for the entrepreneurial personality, the person who has the traits to be an entrepreneur. And the key trait is the ability to take risks. And I don't see how you can expect extremely poor women to take the kind of risks that are necessary to make success of their enterprises without the kind of support that say a self-help group could do. So the other thing of course that troubles me is the empowerment studies. And this is very much in line with the study that we've done at IDS, which found that in Ghana, Bangladesh, Egypt, where the three countries we did a survey, that regular wage employment and employment outside the house had far stronger association with empowerment indicators than work within the home, particularly unpaid work with the home. That's not dramatically surprising, but it seems to be mirrored now in the empowerment evaluations of wage employment in Andhra Pradesh and in Bangladesh and self-employment for very poor women. Thank you.