 Good morning Jim. Hey folks it's Jim. Good morning Jim. Good morning. A small group today huh? Yeah, so far. Folks usually jump on a little late I think. Yep, we can wait a few more minutes and see if anyone else is joining and get started maybe at five past. Hey Jim, Robert, Kristen, good morning. Good morning. Hey Raj. We'll give folks a couple more minutes and get started at five past. Right. Should we get rolling? Yes, we should. All right. So it looks like the only item we have on the agenda today is to go through the. Policy white paper outline. So we've discussed this in a few prior meetings and. I think the intent was to get to a point where we have an outline and then. We'll transfer the outline into. Or a folder in our get repo where we can kind of collaborate and pick on different sections. So here's what some of us, you know, worked on. We had a breakout session also last week. And came up with in terms of the second of went and cleaned up a few of the things moved. And then we did a lot of work on that. And then we did a bunch of the notes and other kind of place holders into the details section, but then we can revisit. But what the outline looks like at this point. You know, something like this. I think there's about three main sections. And maybe there needs to be one more, which we can talk about. I'll mention what I was thinking of there. It seems like the main sections would be the. So we talked about the cluster components. Container images. Resources resource configurations. The runtime of the cluster components itself. And then we had a place holder for multi cluster, right? To see if there's anything that needs to be called out there. And so that's in the policy. I just titled that scope for policy scope. We can sort of change these and get more feedback. Then there was an architecture or a how it works sort of details type of section, right? Which I think Jaya has mostly kind of filled in the major components, which we would be looking at. So there's a definition language, the authoring point, like where are these policies managed and stored. Like upstream get ops repo or some other management play. Or I guess there's a authoring point and a management point. So those are called out separately. There's the enforcement points, which could be, there could be multiple like the CI CD pipeline, as well as admission control and then run time. And then the policy reporting, which we can talk about it for the CRD. And then we have a section on mappings, integrations. And I think I'd seen use cases. Yeah. Use cases is also here. So we can kind of figure out what to put in this and. But maybe before we go to those sections, I think those need to be refined a little bit more. Let's does this general structure and these major areas. Does that seem relatively good to everyone? Any thoughts, feedback? Hello, this is right now. I just joined. Sorry. I was late. I do think we need to expand this mappings and integration section. Detection is important, right? When a policy violation happens. So a subsection under the mappings and integration or a separate chapter on detection of policy violations or changes that are happening. Can be detected from a cyber perspective. I agree. I was wondering, do we need looking at the outline level, Jim? Do we need kind of like a policy life cycle, which would include like the detection of policy violations or policy enforcement? I'm just wondering, is there, is there. Maybe there's an overview. Maybe it's just a sentence. Maybe it's just a, a diagram, but do we kind of need to like enumerate the phases? So, you know, policy definition, policy deployment, policy enforcement, policy violation detection, policy, not violation detection. I went the right word. Success cases. Yeah. Yeah. I mean the policy is. I believe in forest, you know, so monitoring, I guess, is probably a better word. Sorry. So there was some aspect of a life cycle. Dressed maybe. Right. Yeah. So there was some aspect of a life cycle in these, you know, components, but maybe we could, in the architecture, perhaps there's a component section and then there's a life cycle, you know, to show. Both. And then some mappings and integration. Yeah, I'm not sure what exactly the intent of that was. And I don't know to your point, I'm not sure if detection would fit in there or if it should be in the chapter. Right. You lost Jim. Okay. The idea of mapping and integration that we had was that I think when you talk about the life cycle where we entered this section was around, you know, how do you author policies? How do you manage policies, enforce policies all the way to report them? And the question is what do you do after that? Right. And that was the idea behind the mappings and integration. So my recollection was this was more it started about as we were talking about from operational to compliance to what other teams, you know, outside of the Kubernetes domain would want to see. And yeah, that was what we would put in there. Integration is still there as well, right? Every Kubernetes might have some Kubernetes implementations will have Istio mesh, right? Service mesh. And if we don't want to call Istio, that's fine. But some integration of policies because you don't want to have conflicting policies at different layers. So I think mappings and integrations we should specify which all integrations are we focusing on? I mean, from a cyber perspective, these things make sense definitely, but which all integrations are we addressing? Yeah, maybe we need to, we might need to separate those, right? We say mappings to saying, okay, you have the operational policies of the Kubernetes layer. Perhaps you have some Istio policies, other policy objects. What comes above it, right? How do I translate this into compliance and regulatory into that domain? Right. So yeah, maybe we could call out integration separately. We can talk about, you know, things like service mesh. So integrations should be before the mapping stand, right? In terms of hierarchy because detection and saw compliance that should be on the integrated system rather than just the Kubernetes at that point. I don't know. That's my opinion. Yeah, I think the, can you guys hear me? Yes, we can. Yeah. Hi, this is Jaya. I think the mapping and integrations was more focused on things external like Jim was saying to Kubernetes, right? So if you have a customer who is, who has existing tools that they use to manage, you know, compliance or other processes, right, that they have, how do you integrate this architecture into that, right? So, so that was the focus. There is something like service mesh. Yeah, you cut out. We can't hear you anymore. Into the table that you had in the previous document. Yeah, you cut out for a bit. If you could repeat the last sentence, please. We heard something like service mesh and then nothing for a bit. Maybe she can. Right. Okay. Yeah, no, that makes sense. So we just need to understand what, what we want to cover in each section. I think here really the, the goal was, okay, now that we have these policies, we have the reports, the violations, who's going to care about them? And how do we, you know, kind of use them? Right. All right. The fit of detection here. And I think that's, I brought this up. So policy can be a preventative policy, a detective policy or a corrective policy, right? Why specifically just call out detection here? What is the idea? Detection for me is if somebody, something malicious is going on, right? Somebody's maliciously changing a policy, then somebody in the cybersecurity team would want to know, right? My focus is cybersecurity. That's what I'm thinking from that perspective. Okay. Right. I think the, the, the, well, a lot, I mean, you're absolutely right. Most cybersecurity today is. Detective and remediation based, you know, and vulnerability based in particular in a lot of cases, but. Yeah, I think there is an evolution towards. Especially in Kubernetes, you're, you're a state based system, right? You're a declarative system. So if you. If you declare your policy correctly, and that's enforced by the infrastructure as code, then you're, you, you in a sense shouldn't have any. Vulnerability is you shouldn't have any violations. I still want to have controls that are reporting compliance. That are reporting policy enforcement, right? Does that make sense? No, I'm not against that. I'm not questioning that. What I'm saying is that the point I'm trying to make is that I see that orthogonal, right? What I mean is irrespective of what policies we have in the life cycle, we talked about from a policy perspective, right? Whether you author it, you enforce it, you can do this, enforce this through three mechanisms, right? You can put that ahead. I mean, we're talking about the CI CD pipeline and that as a use case. For example, that is a preventative type of mechanism, right? At least in most cases, then you can have detective. We have not talked about corrective at all, right? Sort of the GitOps based remediation workflows might. So my question is, should we expand this to our other points to cover these other things? Because if you just call out detection, I'm just trying to understand what does that mean, right? What does that mean for preventative sort of policies and corrective sort of policies? Even a preventative policy could be maliciously changed by an attacker. And that's what we want to detect on as well. So maybe detection of changes to policies, whether they're preventative or detective in runtime, as well as in the. Yes. Yeah, I agree. And I, that's what I meant earlier by drift. I'll clarify that. Yes. Malicious or unintended changes to the policies themselves. I agree. I think that is a concern. Just circle back, Raj. I agree though I myself, how do we express a preventative or corrective policy in the frameworks that we currently have? Like we have admission control. Yeah. But where else, where else can we, I mean, the common set of policies, right? Most things that we have in CIS run as non root are all preventative policies. Right. You can't execute though, you can't execute those containers until unless you have, you adhere to those policies. A detective policy is more typically happens in the action access control, right? Post facto. Maybe we are using different terms here. I'm just, right? I just wanted to call up because when, when you typically read the policy papers on Nest, right? The way that they categorize is along those four buckets. These are the terms they use. And that's why I'm calling them out. You know, I absolutely agree with the terms. I'm literally trying to wrap my brain around like at the Kubernetes level. Because I mean, you know, the goal of this white paper is to kind of get a little bit under the details and drill down into how do you actually implement this? You know, not prescriptively. Here's the code, but, you know, taking it. Would you give an example of a detective policy? A detective policy typically an access control. A termination control is a very classic example of detective policy, right? You have turned the user, the user continues to have role bindings, right? Or super admin access, right? Into a cluster. And you want, you are trying to evaluate if those access are valid. That's an example. The second thing could be, for example, that you have a cluster and you do not have logging enabled on the cluster, right? You don't have stack drivers. You don't have Azure log analytics. So things like this, right? Which is post factor. You're observing this out of band is what do you typically call detective? Yeah, detective policies are more oriented toward runtime, right? Meaning after the already deployed and running and everything, you know, how do you monitor, right? On a non-going basis, right? That is preventive or more like admission control. Exactly. Both are fine. And one comment I have there, Jaya and Raj, is that a great, if we have those detective policies, then we should have, we should identify how those detections are remediated. Is there automation being built around that as well? So I think detection and maybe detective policies can be a subset of the detection itself, right? They're kind of correlated. And then for those detective policies, we can further expand as to what kind of auto remediation can take place in certain cases. I think Jim has done a good job of sort of putting those bullets there as well. Yeah. I'm not disagreeing with what you're saying. I'm just pointing it out. And I think he has sort of added those line items there. Yeah. So one thing I would add to that though is what we're seeing is that really every policy, even a policy which is intended to be enforced, needs detection, because there's always use cases where you want to do the additional runtime scan, right? So I don't think it's such a, you know, concrete categorization in that sense, because as you're rolling out and this goes back to what Robert was saying with versioning and drift. So let's say there's a new CV, now you want to roll out a policy, there's existing workloads. In most cases, you're not going to bring down those existing workloads, but you're going to detect if those violate the new policy, and you're going to take some remediation action which could spend some time. So I think both, it's what we're seeing at least with Toronto policies is you are going to run every policy, even if it's configured to block. It still has a component where it will detect workloads which violate that policy for any reason. Maybe you have bypassed the admission web book, maybe there was an upgrade going on, or maybe it's just a new policy like I described, right? So it seems to me that their detection is always required for every policy. Yeah, yeah, I agree completely. I think also, you know, there may be resources that were created before a policy was put in place. Exactly. That's why you have the gatekeeper, for example, has both admission as well as audit. Correct. New cases, right? So, yeah, that makes sense. And I agree with our other on the remediation aspect, right? I think they're never possible. Obviously, you know, not every policy can auto-remediate, but if there's a way to do it, that's an option that we need to think about. Yeah. And that remediation could also be in a separate system. So maybe this is just, you know, it's detected, you remediate and you're good or upstream repo and you push changes, but there needs to be some, you know, kind of guidance on remediation for, once violations are reported, things like that. Yep. Okay. So, you know, it looks good. I think maybe perhaps we can combine these two sections. I'm not sure if, you know, they, or we can move life cycle before architecture or, I don't know how we'll have to see how this plays out, but I think these, this covers all the right points. I think so. Okay. So integrations we briefly mentioned things like service mesh. Are those just part of Kubernetes workloads or should be, I mean, I understand it's not an application. It's more of a infrastructure component, but it is in some ways it's a bunch of CRDs, right? So is, do we need to give that special treatment or do we just say, say it's a Kubernetes resource that's covered as part of any resource policy? Like when we're doing configuration security configuration checks. So in addition to config, I mean, so, and apologies, maybe you already have this covered, but when it comes to any of the network things, right, there's the config and then there's what's actually happening and observability. And so, so policy, yep, I might have a config policy. How are you going to assess if there's a violation of that policy or is that not part of this? No, so that we were thinking would be covered in the runtime. Like perfect. Yep. Makes sense. So yeah, you're very right. Like, how do I know if my CNI is even working, right? Cause I may have all the network policies configured, but if my CNI has an issue, yeah, I don't know. Right. So I, yeah, and that, that is slightly more difficult. Those type of things are harder to audit, right? Cause you wouldn't actually need something like Sonaboy or another runtime tool, which is doing behavioral tests to make sure that things are working as expected. Okay. So let's take another quick look at the overall outline. So yeah, I guess the question still is, I mean, we can leave this integrations for now and see if anything comes up, but otherwise we can. Yeah, otherwise we'll see if it collapses into some other section on the use cases. I added configuration security, operational compliance, regulatory compliance and supply chain. Do those seem appropriate or as we're saying, these are use cases for Kubernetes policies. We think we just said run, well, I guess runtime is under operation. And supply chain obviously is very wide, but I think there is a component there. That has to be done in cluster or admission control. So that would be interesting to call out. It would be helpful to at least my mind Jim to be very specific on the use case. So if we are talking about supply chain and the question is, for example, how something like a Solari gate, right? This policy project will help. Or if you're talking about regulatory or maybe not regulatory compliance, if you're talking about a sort of industry compliance, right? Security compliance, something like PC, ADSS or high trust, I think it would be, and then we can obviously expand that to others, right? But I think the more specific we are, the better it is. Right. Yeah. So you're, I think we can, you know, maybe replace this with something like image provenance or whatever is the right component, but ultimately the use case, I guess the higher level use case that we'll be mapping into is supply chain security. Right. I think the goal is to outline here and then we'll volunteers will fill in the specific use case. Right. And then on the mappings, we had incident management, compliance mappings, Oscar and then I think last time we were just started talking about security operation center or SOC and what users there would require. Any other upper upstream mappings that come to mind? Yeah. I think vulnerability management tends to be separate from those items. It may feed into a SOC, but there's often a different team for vulnerability management as well. And SOC is an interesting subject when it comes to container platforms. True. I don't know. The jury is still out. I've had a number of conversations in the industry about SOC for, you know, Kubernetes platforms. SOC teams are at a loss as to what they are supposed to do. So it'll be good if we can address something here. But yeah, I think I've heard similar and isn't it, it's basically they're just using this umbrella term of, oh, that's now DevOps. So they don't know what that means, but they know it means not SOC. Ooh, but that brings up a really good point, right? Because is there a DevSecOps dashboard? You know, it may be a DevOps dashboard and in fact, so where does that live and what does that look like? I think there would be both. So there'd be the DevOps and I'm just going to arbitrarily draw the line like DevOps is getting my stuff into the cluster and it's running. And then from that point, DevSecOps is, you know, maintaining the client's vulnerability. I'm going to strongly disagree because DevOps is supposed to always include security in the pipeline. And the reason people, you know, started using the DevSecOps term is because it keeps getting forgotten. So, so a DevOps pipeline should include security scanners and it should include a security dashboard for managing the results. So it's, if you're doing security only on the ops side of DevOps, you're missing. I completely agree. I'm just recording from the field. Yeah. And I think we need to help change that thinking. And actually most DevOps pipelines I know of include at least vulnerability scanning. Right. Yeah. So I guess the question, and I think we've had this conversation in several forums is, is it the DevOps team that's transforming into a DevSecOps team? Or is it more the central security team that's learning about Kubernetes? And I think we can't. Yeah. And we can't prescribe that. But I think what we can say is that policy information should be part of, you know, policy should be part of DevOps. It should inform DevOps and policy and security. And at least this would be my opinion. It should be included as an external, you know, place we'd want to send, you know, information should be available. Well, I mean, I think that, I mean, to your point, Kirsten, this is our chance to put a line in the sand and say here, recommendations. I will say from, from the government world that I interact with. They're just trying to figure it out. So I don't know that they have, I think they would read this and, you know, and many other white papers, but they would, they would use this, our guidance as what is the best practice. And, you know, the DoD published, you know, the DevSecOps reference architecture not that long ago. So there's continuing push. Granted it's hard for organizations to make the shift. And so, you know, I think we just want to include it as, as part of where do we think this information should be, should be provided or support those teams that are actually doing DevSecOps. So we have called that out as our primary audience. So from, you know, from the mappings point of view, I think the way of at least I was thinking of it is everything we're saying is targeted to the DevSecOps team. But then they have to realize that there's these other mappings, including perhaps central security, which needs, you know, periodic reports or some visibility into what's going on in the Kubernetes world, right? At least that seems like the view we have taken here, like we're going from the practitioners out. And when we say, so, so again, so I'm thinking, I guess I'm thinking from the tools angle because that seems to be what the mappings is about. Where is, is the rest of this paper indicate that this information is going to show up in some sort of DevSecOps dashboard? It's, yeah, there's no one single thing you're calling out here. Right. So we're saying because I don't think there are reports, right? Because there isn't really a single DevSecOps dashboard in existence yet, right? Okay. Yeah. So we're talking about reporting. We're talking about metrics somewhere. I believe we had metrics, but maybe that fell off. Would it, would it simplify things if we said reporting, you know, reporting and information should show up in pipelines? Or is that applied above or stated? Yeah. Right. So in the enforcement points and in the life cycle, we do want to call out that of course you can. So policies can be applied in the CI CD pipeline. So that's what we were talking about. We were talking about your out of cluster admission controls. And then runtime is the three enforcement points. So each one could produce reports. Okay. Maybe leave it for now because there isn't right now, but, but so, so the other thing we see right there are security dashboards in AWS. And let me see if I can find an example of one. Okay. Let's, let's leave it for now. Yeah. Yeah, that would be good to call out and see like, you know, give it. So we, we had a discussion on, I think what we decided is we. Could potentially reference projects. Especially CNCF projects, but ideally we'll just stay away from company. Right. Any, any product or even perhaps projects, because things change and once the paper's out, we don't want to kind of look like there's any favorites or anything like that. Right. Yeah. Yeah. Well, and yeah, we could certainly normalize it. But yeah, so, so yeah, let's leave it alone for now. Give it some more thought. Sounds good. Okay. Any, any other ideas or thoughts or things we should cover, which, which is not in this outline so far. I think the outline looks great to me. I'm just excited that we are working going to work on this white paper. And so wondering what the next steps are. Yes. So what we can do is we will, you know, we can formalize this outline or just at least create the sections in a get repo. And we, like we'll just use markdown for authoring. The other thing we could also do is, I don't know. And Robert and I read now, I think both of you. Also, you know, work with six security. So would it, is it too early to kind of get feedback on this outline or should we. We also have a leads meeting on Friday. So I will share this there as well because I give updates on this policy working group. And we can share in the next Wednesday's meeting today. It's kind of too soon to put it on the agenda. But we can start working on this while that is happening. Right. Nothing is stopping us from making progress here. Right. Yeah. And I joined the coup six security meetings. Periodically too. And I'm, there's, there's work on a white paper planned there that's more, you know, more directly security focused. So I think, I think this is a good time to share. Yeah. I don't know if that, I had proposed that, you know, security policies was the white paper that you were going to work on. Okay. Does it make sense to do a separate security policy document or you can. You know what security and this is out, right? I'd have to go back and take a look at the, the outline that was proposed in the coup security. So I think it's a good idea to, to, to, to talk about the security side. My sense was it was fairly different from this, but, and, and I could see there being a need for differences. So, but it's, so all the more reason to share, right? I would. It sounds like we're, we all drift in and out of those same, same meetings. Like the, the, the RBAC, the admission control. Configuration of the cluster, managing certs. I mean, yeah, kind of a lower level, I think, than, than what's here. But, but obviously if you have a different recollection. Yeah. Yeah. A, a, you know, either, either way, if we share the outline, it'll generate a good conversation. Right. Yeah. And it may be good to get if there's somebody from each, and I know like a lot of folks on this call are also in those forums. So as long as we make sure there's coordination, I think that that would be great. So I will take the action to review this and this security next week and then bring any feedback from there on. But if we want to start making progress, I'm good with that. Yeah. Let me know which sections I can work on. Okay. Sounds good. Yeah. So we can, the next thing I can do is I'll set up the good structure and at least, you know, we'll have the, the various directories for the, the, and the markdown files. And then we can figure out who wants to work on what. And just to kind of clarify, so there's, I think, Kirsten, you were talking about the sick security. I know you're talking about the CNCF. Sick security, right? Right. I'm talking. I was going to ask that. Okay. That's why I put coob in front of mine. Yeah. So the coob sick security team was looking at a white paper. And I'm less aware of the CNCF security. Yeah. In my mind, I mean, this isn't like the defined admission. But I kind of think of the, the CNCF sick security is kind of like the overarching, like all things cloud native. Right. We're kind of at the middle ground of, you know, policy applied to Kubernetes and related stuff. And then the coob security is super focused on, you know, almost at the API layer. That's at least how I organize it in my brain. So when I go to the various meetings, I kind of know where my, the context is. Okay. Yeah, no, it makes sense. I think that matches at least my way of thinking too. And I think there's certainly each one is a very large area. All right. I didn't have anything else on the agenda. And unless someone else has any other topics to discuss, we can break early then for today and I'll, you know, set this up and get and send out something on Slack. I think that's great. Thank you very much. Thank you. Thanks everyone. Bye. Bye. Thanks.