 Okay, I think we'll get this party started. Congratulations. Are we good? All right, well congratulations. You made it to the policy work group update. If you, I say congratulations if you are here to learn more about Kubernetes policy and compliance, it means that you probably have achieved elite status in your career where you can tell people what to do and if they don't listen, you can write code that forces them to do it. So welcome. I guess we'll do a quick round of introductions. My name is Robert Ficalia. I'm CTO of Sunstone Secure and we specialize in Kubernetes security and compliance. I'll pass it on to Jim. I'm Jim Baguadia, co-founder and CEO at Nirmata. We are in the Kubernetes policy and governance space. Hi everyone, thanks for coming to our session. I am JR Amanathan. I'm a Distinguished Engineer at Red Hat. I've been working in the security compliance and governance space for many, many years now. So excited to share the direction we want to take. Thank you. Good morning everybody. Happy Thursday. My name is Anka Seiler. I'm from IBM and I'm in research leading the governance risk and compliance field. So what do we do in the policy work group? So our charter initially was to help define the architecture, the designs, the nomenclature, if you will, for policy and Kubernetes and of course supporting the ecosystem and CNCF. And I think it's Martin Fowler who once pointed out that there are really only two hard problems in software naming things and something to do with caching. The jokes don't get better. But we have been busy trying to define a common output for policy reports. We've defined a white paper that lays out policy architecture that we'll be speaking to shortly. And we're hoping to invite the community in the vendor community, the projects, the sub-projects to discuss how policy framework can fit together and support the different services in a way that meets compliance, regulatory requirements, but also in general, knowing how your system is gonna run in a declared state and making sure that declared state matches the actual state. One of our efforts to date has been to align this with other industry groups so that the policy, construction, policy enforcement can be reused in many different industries. And one of those efforts is a project sponsored by NIST in the US called OSCAL. And we'll talk a little bit more how our efforts have aligned with that OSCAL schema and how it helps enforce policy and distribute the results of those policies across systems. So with that, I'll hand it over to Jim. All right, thank you, Robert. Yeah, so just one quick thing I wanna add, like within the CNCF, there's various types of organizations, right? So you have technical advisory groups that span multiple projects. You have special interest groups or SIGs that are focused on particular areas within a project like Kubernetes. And then you have working groups that are also cross-functional and report into multiple SIGs, right? So from that landscape perspective, like Robert explained, our charter is to figure out for Kubernetes policy and governance, what exactly does that mean? What is needed? How do we align across all different concerns within Kubernetes? So one of the things we did about a year or so ago is we wanted to publish a paper that talks about what Kubernetes policy management is. And we use reference architectures from the industry, from authorization. There's the exact mill architecture that we leverage. And to define the terminology here, within Kubernetes or within a cloud-native system itself, you have multiple policy enforcement points. And of course, all of us are running, if you're running Kubernetes, you have multiple clusters. So that's where you would enforce policies. In Kubernetes, you have extensible admission controllers, which lets policy engines like Kiverno and OPA gatekeeper function and add customizable policies there. So given these policy enforcement points, and keep in mind, you might wanna enforce policies in your CI CD pipeline, also at runtime, as well as at admission controls, then you need a policy administration point, which is managing policies across your fleets of clusters, or just different environments like staging, DevTest, QA, et cetera. And finally, you wanna enrich policies with information. This could be from within the cluster, like through the API server. Could be from external data, because policy decisions have to be made very fast, typically in a couple of seconds, at admission controls. So you need to bring in the right data to policies. Anyway, so the paper's available, this is a live document, it's managed in our GitHub repo. So please do give it a read, post your feedback. We are looking at evolving the paper, and we will publish a V2 fairly soon, with some learnings, and as Kubernetes evolves as well. Another aspect I wanna quickly touch on, and this is a project we completed, and it's ongoing as well, is to define a custom resource definition. So as most of you probably know, Kubernetes is designed to be extensible. It allows you to, using open API V3 schema, define custom resources. And those resources act like native constructs, like pods and worker nodes, et cetera, which can be managed through the Kubernetes API. So we added a custom resource definition to collect policy results, and format them into reports, which could be extracted through the Kubernetes APIs. The benefit here was to standardize the way Kubernetes policy results are retrieved, because if you look at Kubernetes security, there's a broader set of concerns, right? You have runtime security at one end of the spectrum, you have configuration security, which can be applied again at admission controls in your CI CD pipelines. You have things like you wanna verify signatures and attestations for software supply chain security. You have other things like you might wanna do vulnerability management, and periodically check if each image has an up-to-date vulnerability report. Software build of materials is also becoming very important. So all of these concerns have to come together, and typically what we saw previously is every policy engine had a different way of reporting results. So standardizing this allowed any operator to retrieve these reports through the Kubernetes APIs itself in a very standard format. So this again is something that we're maintaining within the working group. We've also sponsored several adapters. So as you see, Kibirno, which is a Kubernetes policy engine. Kubbench, which does CIS benchmarks. There's Trivi, which does vulnerability management, Falco, and Kube Armor for runtime security. So covering all those different aspects we talked about. And then there's reporting and translation tools that build on the standard. So the reporting is done by Policy Reporter, which is a sub-project of Kibirno. And the translation is a contribution from an IBM team which takes the standard report in the policy for a CRD format and converts it into OSCAL. So lots of interesting things coming up and that's the benefit we see of standardizing here, which allows other layers of tools to be built in this chain. So those are two of the projects that we have completed. Next, Jaya is gonna talk about some of the upcoming projects and we'll look at some details there. Thank you, Jim. Yeah, so as Jim and Robert outlined, the focus of the work group so far has been to define overall architecture for policy management and kind of also standards of how the various policy engines can report the results because we can all agree that there's not gonna be a single policy language out on the planet, right? There are gonna be multiple and we have to deal with that. So then what we are focusing on right now is why do customers do policy management? They do it because it is a means to an end. And so what is the end goal, right? So the various end goals. One could be maintaining continuous security readiness and audit readiness. Another goal is to comply to regulatory compliance standards. A third goal is to reduce the operational cost of operating the environment, right? Because as people know, right? What teams, application teams just want to deploy their workloads and get the applications going. So security compliance becomes like an afterthought and so the more we can make it easy for them to accomplish that by minimizing the operational cost, I think that's important. So that's where governance comes into play. So the two focus areas that we are focusing on next are one is to produce a draft paper on Kubernetes governance. Because the term governance is used in so many different contexts. So we want to kind of highlight what do we mean by that and how policy management can help you achieve that goal. And the second one is to bridge the Kubernetes policy management concepts to compliance management. Because NISTAS has standards such as Oskal related to compliance and we want to bridge the two and kind of articulate how you can automate compliance by applying the policy management approach. So those are the two areas. So let me talk a little bit about Kubernetes governance. So if you think about a cloud platform and customers or cloud providers managing the cloud platform, they have to comply to various standards, both internal standards as well as external regulatory compliance standards. And these standards could pertain to security, resiliency, software engineering. And what they really want to do is to get that done by minimizing the cost to do it. And then also minimizing the risk and also be ready for audits and so on. So that's really what they're trying to do. And what that means is, if you think about an enterprise, there are so many different personas who are interested in this topic, right? You have the site reliability engineers or administrators who are actually managing the platform. You have the secops people who are focused on security aspects. You have compliance engineers who have to produce evidence for audits. And you have the CSO who is setting the enterprise standards, security standards and so on. So you have all these different personas and they all come into play. And then if you look at how things are done today, it's almost like they are kind of operating in some island and they all kind of come together when they have to get ready for an audit, everybody is crumbling, right? So what we really are trying to do is to use the GitOps and those kind of methodologies to ensure that those kind of personas can actually collaborate on a day-to-day basis. And so that this whole thing becomes like a more autonomous governance approach so that we can always be security ready and audit ready. And even if we can achieve that goal for a subset of the controls, I think that's still a big win because you're now reducing the operational cost at least for those set of controls. So that's really what we are looking at. And the how is we want to represent the best practices as policies and we want the policies to be managed as source code in Git just like any other source code. And then you have tools available so that all these different personas can be involved in how those policies are defined. And then they get deployed using GitOps and then you have a regular monitoring on the posture with respect to the various policies. You detect violations, you remedy the violations automatically whenever possible or in some cases, if you have to follow an ID process, fine, you can open service now tickets or to get that automation rolled out. And also you can do some analytics to fine-tune the policies. So I think that's the overall approach. And the benefit of doing all this is, as I said, you result in day-to-day collaboration between all the stakeholders and personas who need to be involved. You reduce the operational cost by automating things and you also have the SMEs who are knowledgeable about the various aspects, actually authoring the policies because you can't expect an SRE to be an expert in all aspects of security and resiliency and so on, right? So there are various people who have that expertise and you want to bring them through the GitOps methodology so they actually are doing this. And we also want to do this in a more open fashion. So we have a project called Open Cluster Management which is a CNC of Sandbox project and we want to kind of use that as a way to kind of define these policies and collaborate and a community approach. So a call for all of you here, I'm really glad to see this crowd. So the call and request is, come and participate and help us progress this because I think by collaborating we can all contribute and tackle this difficult problem. Thank you. With that I'll turn it over to Anka. Thank you, Jaa. Jaa just mentioned that we try to align with standards and with the open community for collaboration. So the standard that we are looking in here is the NIST standard for compliance as code. It's called OSCAL. It stands for Open Security Control Assessment Language and has two major parts. One is the machine readable language itself. It provides about seven or eight schemas that correspond to the various compliance artifacts that the various personas in compliance will manage. You see down in the figure the catalog, the profile. You may know this also as a baseline. Component definition that carries the mapping between the high level regulatory controls and the technical controls. The assessment plan, assessment results and plan of action and milestones. So hopefully there the English name is clear enough. The second part is the framework with support for automated traceability. Meaning that at the end of the day when I get the result or I'm talking about fixing a control in a plan of action and milestones we are not talking about a label in some spreadsheet somewhere. It is all traced back to the catalog that we originally started with. So if you are really NIST, you may know that NIST 853 has its own GitHub, government GitHub and the ID that you have in your results will be traced back to the controls there. So in terms of the artifacts, so let's give an example, right? So all those catalogs and what we talked about. What exactly is that about? So if we start with the top layer, we have examples. I hope you recognize some of them, regulatory compliance. They can also be organizational policies. I make a differentiation here between capital P policy and small P policy because this term is overloaded. And when we are talking about things like NIST or HIPAA or the organizational big body of requirements, right? We talk about capital P policies. And in industry they are typically found out there as PDF or spreadsheet format. And they are very difficult to be used in programmatic interfaces or exchanges. So what OSCAL does, it takes that and allows to represent those as code as follows, right? So the bread and butter of regulation is its controls. So the controls are represented in OSCAL, in the OSCAL catalog or the OSCAL profile. OSCAL profile is a subset of the full catalog with resolved parameter values. So I'm selecting as a CISO, I'm selecting this particular baseline. I select the values and I represent that as a profile in OSCAL. Now we are moving from the realm of regulation in the realm of technical area. So we are talking in the technology about rules, about technical controls, in terms of a particular technology. So we know that Istio, right, has to be this or that way, that the pod has these or those restrictions. So we are talking about those policy rules. Again, this is small P policy. And in OSCAL, we use the compliance as called OSCAL component definition to allow a vendor or a service provider to represent the mapping between the controls in the capital P policy to the rules, the technical controls, for a particular product. Those are the technical controls, the items that we can validate. They are implemented, they may have APIs, they may have a young configuration that we can check and validate. The results from that are represented in OSCAL in the OSCAL assessment result. The bottom line is about the, in the case of Kubernetes, we have a lot of declarative code to express those policies. And we have an example here. So for SC28, which was minus control, we map to the unsure sensitive resources, which is the technical control within the Kubernetes pods. And then we have the representation of the descriptive declarative code down there. So to link it back to what we have today, in the working group, in the policy result working group, we have this report that is done at the policy as code level. So right when we go into the policy code, we get out of the compliance as code realm and we move into the policy as code. So when Jaya was mentioning Robert about bridging, right the two, we are looking at having this linkage done across the stack so we are able to support automation. So what we do in the working group, we have a result that is harvested from the policy as code report and we translate it in the assessment result format. So Jaya mentioned about the different personas. I know this is a lot, hopefully when this is getting recorded, you can look at them individually, but you see how the OSCAL artifacts are mapped to those individual persona, allowing them to manage and to author those artifacts without working on each other toes. So the regulators are going to use the catalogs and predefined profiles. The control providers will author those component definitions with the mapping, system owners create the environment. They subscribe to the services deployed, the clusters define various scopes and associated various profiles, PCI, HIPAA, whatever is needed. CISO will define the baselines, right, and the parameters that are needed to be associated with those baselines. And at the end of the day, if you do FedRAMP, you need a system security plan and the goal to use those artifacts to generate the system security plan as much as possible in an automatic fashion. So now if we go from this realm of the compliance down into the PEPs, right, we'll have the assessments, the policy enforcement tools, like Iverno, the OPA gatekeeper, Falco, that will be the source of those results. So what we have today in the working group, you see in the continuous pink here, we support like the obviously the system owner, are creating those environments. We are able to collect the assessment results and next we are looking to be able to support the specification of different profiles in order to help bridge into the next level in the OSCAL framework. So here is an example of how the NIST, how they are working with the policy result, YAML is translated to the OSCAL, right, so you have the format of YAML on the left and the OSCAL on the right. So to summarize, right, so these are the major points that we have today in the working group, and I think we are now ready to open for questions, right? Yeah, I think we are at the end. So I just want to invite everyone to attend our work group sessions. We meet every second Wednesday at 8 a.m. Pacific, so in almost two weeks we'll have our next session and of course you can find our content on YouTube. We have a Slack channel and look forward to, so I'd like to open up the two questions from the audience and we have the project perspective, we have the enterprise perspective, we have the developer perspective and my perspective comes from the audit and compliance world, so any questions that the audience might have? Otherwise we might have a little back and forth here on the stage. One night I started off, maybe open up some of the questions, so I think it would be important to discuss what the challenge is for managing policy at scale and I think probably all of you here have some perspective on that, so whoever wants to start, what is the main challenge you see when you're really in the weeds trying to manage policy across clusters? Yeah, I can give a quick perspective from what we're seeing and you know, so Nirmata, my company, we also have a policy engine, Kivirno, which is one of the alternatives in terms of enforcing policies and then we provide governance and management tools around it, so what we typically end up seeing is, first of all, keeping policies consistent across all clusters requires best practices like GitOps, et cetera, right? So you have to fall into that cloud native way of doing things, but typically within an enterprise, it's not just a matter of setting policies and then you're done and everybody's gonna be compliant, you need to manage policy exceptions in a flexible manner, so we have ongoing projects and things going on with that to be able to have enterprise-type workflows around that. So the right team and the big problem is how do you do that in a cloud native declarative manner as well? So those are some of the challenges we see and there are solutions emerging around that to manage at scale and certainly like some of the things we're doing in the working group as well to allow that flexibility and make policies as well as the exception management declarative and manage everything as code. I could add to that that I think the problem that Robert arises is one of the most difficult because it's a multi-dimensional problem. The scalability, right, is in a multi-dimensional domain and besides the policies themselves, we are looking at the way that those policies expose themselves in terms of being configurable or in terms of providing the results. So being able as a security and compliance provider to manage across such a variety of native interfaces is another dimension of this scalability. So this is where OSCAL comes into the place and I realize now I miss to discuss during the presentation so that we have time for questions. Our open source compliance project, Tresol, where those personas get a collaborative platform to offer their compliance artifacts via the interfaces of their choice. This is another problem, another dimension of this scalability compared to the operation team or the DevSecOps, where the type of skills are kind of uniform. When you go into the compliance, you go from the compliance officer down to the developer, you have all the skills from working only with spreadsheets or working only with text or working only with code. So what Tresol allows those personas to manage the artifacts through the interface of their choice. So it supports spreadsheet translation, markdown translations, the type of translation that you have seen here from YAML to the JSON for OSCAL. And the key point is that they are all maintained as the unified common denominator, the OSCAL format. So any change is done in any of those format, we maintain the common denominator in OSCAL. So just to give you the feeling of the complexity of the problem that Robert raised, many dimensions of this scalability. Yeah, I can add a few things which is, so in my experience, one of the things that I've found is that you can define policies and you can have rules by which the policies get deployed to manage clusters. But sometimes you have to customize, because a given managed cluster may have one parameter that may be different. And you don't want to have to define it another policy for it. Then you're gonna have so many policies out there. So having the ability to templatize policies so that you can just define a policy and then include the template, include some parameter that says, okay, use the secret from the managed cluster or use this cluster plane or even a configuration. I think that that capability is important. And I think that also helps with edge kind of use cases to scale. The second thing I found is, as I mentioned earlier, there's not gonna be a single policy language out there. There's gonna be multiple. Gatekeeper, OPA was getting a lot of traction and then Q and O is now getting traction, right? So we already have two. And then there are all these security tools that are out there that are already supporting some of these capabilities. They have their own built-in rules and so on. So you need a framework that allows you to integrate all these multiple policy engines. So I think that is another critical piece as well because you can tell customers to just, okay, you need to adopt this, right? Because they may already be have adopted other things. So we need to be able to cater to that. And the other thing is, when you have all these different policy engines and they have their own policy files or YAML files, how do you quickly incorporate those? So having a generator capability that takes those existing Kubernetes configuration and policy files and then adds to it the OSCAL kind of component definition and profiles so that you can then have the end policy which is and refers to it as small P policies deployed to the managed clusters. Having tooling to support that, those that is important as well. So all these capabilities exist today in the open cluster management project which is a sandbox CNCF project. And it's also available in one of the red hat product offerings Advanced Cluster Management for Kubernetes. So we want to kind of bridge the, one of the things I'm also finding is a couple of days ago there was a talk at and that I found that the six security is actually focusing on mapping some of their security best practices into NIST 8553 and those kind of standards. And I think what I'm seeing is, and I talked to a couple of customers and they also mentioned this challenge of policy management and dealing with compliance and even justifying to their teams, why do I need to add another policy, right? Being able to bridge that to business goals is a challenge for them. So I think the work of a group is doing, tying that with the six security work and the OSCAL work, I think it's going to be a very important piece of work. Trying to provide a solution to the multidimensional scalability problem in a standard way. And I'm reminded literally sitting next to the river and then the bridge, it's like there's this big gap between the developers who wanna move fast and add features and functionality and then kind of on the other side, the SISO and regulatory folks, security ops who wanna make sure things are safe, right? And of course, reconciling those two, building that bridge is difficult. But if we have time for one more quick discussion or we have a question. I can take this one. So the compliance, catalog, profile, all these artifacts, they are the same. Whether I'm looking at the content like infrastructure as code, right? That I need to deploy, so pre-deployment artifacts or the runtime environment, right? I'm following the same, I'm HIPAA or I'm, right? I'm not PCI left and HIPAA right. So the artifacts that we develop or the personas that we are talking about author are the same. What is different may be the policy. So go from compliance, we go into the policy realm. Now there is this new approach, especially that OPA is providing where is write once and use multiple times. Meaning that even the policy that I'm writing is the same and I apply the same one left and right. Again, I'm talking about apples to apples, right? Infrastructure as code and the environment that I deploy. If we are looking at the compliance of the pipeline itself, obviously it's a different set of rules and so on. But if we compare apples to apples, we want to write once and use multiple times. And this means that we bring the differentiation only at the level of abstraction of the evidence. And then all the rest we want to be the same. So it's another way to address the scalability of that because if at each layer I have another set of artifacts, another set of policies, it multiplies. And I think, does it answer the question? Yeah, and to add to that, I think what we are saying is this approach can be applied not just during runtime, it can also apply it in the CICD pipeline, right? With the same artifacts, exactly. And just one more thing to add to that because I think especially for the supply chain, and if anyone's actually looked at an S-bomb and tried to make sense of that, you quickly realize that you have to build out a tooling and a design that allows you to aggregate all this data and align it with policy with other tooling, right? So if you're talking about, we've seen some concrete examples of folks building out catalogs or repositories of OSCAL component definitions, right? That declare here are the policies that I support, here are the controls that I implement. And so I'm hoping that we get to a point where projects, sub-projects, and then vendors will continue to expose, here's the definition of what my system or product supports, here are the policies that can be enforced either against this or with this, and it becomes a very reusable set of assets that then with other tooling, I saw an example for OPA where you can point it to any open API and then it'll generate policy based off of logic and template. So we get to a point, hopefully, where the policy rules themselves are being at least generated in template form and then different subject matter experts can go apply parameters or tailor it to the baseline and the profile, so. Yeah, and then mapping between the standard and the policy, like Anka was also mentioning, is exactly one of the things we want to tackle next is to say how do we create a catalog of that or at least provide a means where folks can customize and build those catalogs. And we want to kind of do that in a more open fashion, right, because right now what's happening is everybody is dealing with this problem on their own. So if you can standardize and as Robert was saying, if the technology providers also can collaborate and expose the parameters needed, right, then it becomes easy for everyone. And to give you a, you know, a peek into the next like OSCAL roadmap, another scalability problem is that right now, if we have to provide the assessment and the reports for HIPAA or for PCI or for all the time, or most of the time we start from scratch. So what OSCAL brings now is another type of mapping. So what Jim mentioned is between the capital P policy and small P policy, right, regulation controls and policy. OSCAL is now bringing up a mapping support between controls so that I'm able now, if I have the results for a particular regulation to reuse the evidence and the results for another regulation through this mapping. So yet another solution, right, to the scalability when I have multiple policies. Well, thank you to the panel. Thank you for attending. And of course, every other Wednesday, 8 a.m., hope we see all of you there. So thank you very much. Thank you. Thank you. And we're happy to take questions here at the stage, or we can move outside if you had one-on-one questions. Thank you. 12 o'clock at IBM. We have a detail on Tressel, detailing exactly that piece of the presentation that we had here on the IBM booth. Thank you, everyone.