 Okay. Well, as an homage to the Chicago musical, is everybody here? Is everybody ready? Let's do it. So welcome to the policy-based governance risk compliance panel discussion. We are the CNCF Kubernetes Policy Work Group. Before I jump into the panel contents, I'd like to introduce the panel. We have Anka Seiler, distinguished engineer from IBM. We have Andy Suderman, CTO of Farowinds. Jim Baguardia, founder and CEO of Nomada. And Punam Lama, a product manager at Google. Myself Robert Ficalia, CTO of Sunstone Secure. Just a brief set of intro notes about the Policy Work Group. Our entire focus is to work with the Kubernetes community and discuss how policy can be made practical, how it can be made better, discuss architecture and best practices. And so we give a big welcome to everyone who is either working within the Kubernetes project, the constellation of other CNCF projects, or just in general as an operator or user of Kubernetes to join, if you have any interest or any contribution in the policy landscape. Or if not, just to observe. The work group has so far produced a number of outputs. We have done some white papers on Kubernetes policy management. We have a high-level overview. We have contributed back an API, CRD, for policy output. So there's a myriad of different policy engines and ways to express those policies and different DSLs. We decided several years back that there was a need to at least define some layer of abstraction that reporting can be done in a consistent way. And so we've worked with a number of the projects and different community contributions that have either native integration or component bridges adapters to that standard. And then we just released our white paper on Kubernetes governance risk compliance, and that will be the focus of today. We wanted to just get a quick show of hands on a couple of questions just to see where the familiarity is. So for those who are implementing or planning to implement a Kubernetes environment, let's say, are you aware of using any form of policies today? So number one, okay, great. So I'd say about half. Anyone using policy as code and kind of GitOps related? Okay, about a third. What about compliance as code? Does anyone use that today? All right, we have a couple of early adopters. Fantastic. And then one other question, what are your top pain points for Kubernetes policy and or governance? So number one, deciding on which policy engine to use. Is that a pain point? No? Okay, everyone seems to have that challenge solved. Writing and managing the policy content itself. Is that a pain point? A couple of hands. And then how to map across policies, compliance standards, frameworks. Okay, a few more hands. So good mix of challenges. And then there are going to be questions at the end. So please tell us what pain points and challenges we aren't capturing and what you're really facing in your day-to-day work. So with that, before I get into the panel, I think obligatory of these days to tell a GPT-generated joke. So why don't Kubernetes pods make good comedians? Anyone? GPT says, because every time they try to deliver a punchline, an admission controller interrupts saying, sorry, that's not allowed here. Hopefully that'll get us off on a light-hearted note. So everyone is here because of policy, GRC. So, Anka, maybe you can start us off. How do you think about GRC? How do you define GRC related to Kubernetes? Thank you. Thank you, Robert. So we are all familiar with the concept of governance, mainly right processes at high level in corporate. When we are talking about governance in this context, compliance governance, we are referring to ways, processes to be able to manage the controls, their alignment with the technology that implements the controls and the responsible parties. Digitizing this process, NIST offers the OSCAL framework and standard, which stands for Open Security Control Assessment Language. And we have an opportunity implementation of that with the compliance Tressal, which we hope to make available at CNCF. So, again, the governance context here is to really help you translate the high-level regulation language through compliance as code down to the policy as code in order to be able to provide automation and goal being continuous compliance. So that's the final goal. Yeah. I think that's a good high-level overview to start with. I guess maybe Putnam, I'll follow up with you. How do you really kind of map the G and the R and the C specifically to Kubernetes? And how do you think about Kubernetes in your context? Yeah, sure. Thank you, Robert. GRC for Kubernetes is coming up quite a bit these days because more and more enterprises are running business critical applications on Kubernetes. So GRC has been important for enterprises for a long time, but now it's coming up quite frequently in context of Kubernetes. So when you think about GRC for Kubernetes, there are two Cs that you should focus on. It's the cluster and the container. So cluster, you can also map it to your platform. So things that you do not want your platform consumers, you know, not to do or things you want to monitor if they are not doing right. And also from a container perspective, you want to make sure that the workloads that you're running on top of your cluster actually is in line with your operational best practices or your cost optimization best practices, coding best practices, or operational best practices. So in a way, you know, I like to say that governance is things that you don't want someone to do on your platform or workloads or things you at least want to monitor. So we recommend policy based GRC for Kubernetes. Policies are just pieces of configuration and, you know, once you have policy as a code, the controls that Anka was talking about, you express it in policies and once you have it written as a configuration, you can then apply it to the full lifecycle for your cluster and your container through, you know, develop, distribute, deploy, as well as during the runtime. So it gives you a coverage for entire lifecycle of your cluster and the data. So I guess to maybe ask a little bit further, Jim, because that's a, you know, there's a huge array of tasks that just laid out. And you've got this kind of, you know, menu of different capabilities within Kubernetes. You know, maybe it's, you know, network policies, RBAC policies, validating emissions. So how do you recommend people approach tackling the challenges and tasks that Poonam mentioned? How do you, is there a framework? How do you work through that? Yeah, so like Poonam was mentioning, Kubernetes policies are pieces of configuration. And these configurations, like Kubernetes, other, you know, like whether it's deployments, other manifests, to make them as declarative as possible, but then for these policies to apply to your particular workloads or to even, you know, basics of your cluster configuration. So one of the things going from, you know, just the policy declaration, because the policy is basically a set of rules. And, you know, I mean, within an organization we all have rules, we all have things we follow. But how do you make this part of the Kubernetes lifecycle management itself? Right, so when you bring up clusters, if you're using GitOps or if you're using CI CD, how do you manage these policies? So more than just the policy enforcement, one of the things we've done in the working group is kind of laid out a framework for policy management itself, which includes reporting. And reporting also has to be collaborative where the developers or the folks using your cluster need access to the reports as well. So really the right way to think about it is to start with the basics like pod security, cluster configuration, CIS benchmarks, and then work your way up into more complex, you know, best practices, things which might be organization-specific or regulatory-compliance-specific. So if you need to follow PCI or HIPAA, you can have policies and controls which map into that. But then within the Kubernetes and cloud-native, you know, framework, codifying as much as possible, making sure all of this is declarative, can be deployed through your regular tooling, getting the reporting and then tying it back into your compliance is, you know, the automation as well as the collaboration aspects of it, right? Because policies, they're no good if only one team can see the policies or the policy result, but making it available to developers, security teams, operations teams, all of the stakeholders involved. Well, can I just double-click on that? Because as you mentioned, this is kind of a team sport. So is it, you know, what's the most practical approach, especially for a large organization where there may be 30 people on that Zoom call? Is it a bottoms-up approach? Is it top-down, or is it some kind of meeting of the two? You know, so we see some organizations have, you know, policies initially expressed in security tools which may not be available to all of the stakeholders involved. But over time, the trend that we see is just using Kubernetes-native APIs, like what the workgroup has done with the policy reporting, being able to even, you know, get the policies themselves written in as-native format as possible, right? So just within the ecosystem, we've had tools like OPA Gatekeeper which use, you know, different DSL for policies, tools like Qiverno which, you know, made policies more native, and now we have validating admission policies which takes that to the next level. So the more you get and standardize on Kubernetes APIs, the better off, because that becomes a standard for collaboration. And then, you know, tying in things like exception management, reporting results into that lifecycle itself, you know, is a good approach. Did anyone else have any thoughts to share on this kind of team approach and how to coordinate or bridge that collaboration? Yeah, just to add to that, you can oftentimes, when I talk to my customers, you know, they have a central team who is responsible for the rules that apply to the whole organization. And then, you know, you could have multiple lines of businesses and they may be able to express the policies, write the policies which apply to their lines of businesses. And then, you can have development best practices or operational best practices which are written by your SRE teams or your operational teams. So if you want to implement policy as code for an organization, I like to think of it as a tiered or, you know, layered approach to cover, you know, multiple areas for your Kubernetes cluster and your workloads. I'd just like to add that, you know, another thing to add to your arsenal in that is, you know, we can't go a whole talk without adding in some butterswords, but shifting left. Being able to push the results of that policy into your infrastructure as code and pushing that towards the folks who are actually working on that infrastructure as code can really bring that policy to the whole group, not just a top-down approach. Great. I'm going to pick on you now that you've got the mic. So this sounds great. You know, at one end of the spectrum, you might call it ivory tower, the other, you know, kind of the right focus on compliance. But, you know, this kind of sounds like slowing things down. So how do you balance that with kind of a need to be agile and move fast? That's a great question and one that I love answering because I think, you know, people see, and maybe I'm talking to the wrong group here because everyone raised their hand and said they're already using policy. But when I talk to a lot of folks, they struggle to implement policy because of that exact attitude and that it slows things down. It's blocking us from deploying to our cluster. It's blocking us from getting apps out faster. And I think we really need to, as a whole community, get into the mindset of what we're doing is mitigating risk down the road and we're making our lives easier in the future and we're doing this now. And so it may slow us down a little bit right now but the payoffs are huge later down the road and they'll make us more secure, more efficient, hopefully reduce costs throughout time. Anka, I was wondering if you had, yeah, some observations given you've kind of worked on this domain. So one of the first feedback that we get in this context about starting applying not only on the left but as early in the development cycle, the policies where, well, you know, this is not the production environment. Can I have a simplified view of the world? And the governance allows you to be able to do that, know what you are doing and having profile or baselines of those policies that are simplified in your development environment so that you don't have to have that heavy, highly stringent set of policies and requirements as you have in a production environment. So that's, you know, one way of alleviating, right, the pain of doing in a development environment a lighter level of policies. Another point that I wanted to bring is that if you are interested in working in regulated environments, the configuration type of policies is one aspect of the many type of policies that you need to do. So as part of the governance, right, you will need to be able to cover type of policies that are more batch processing, process-oriented, and so on. So just to know that, you know, there are possibilities with the, you know, Kubernetes policy engines that, you know, Jim has pointed out, where we can develop all these type of policies, being able to bring in the data from the various points of interest and be able to leverage the policy engine to support those as well. Another aspect that I want to point out in the governance context is that the most difficult part, right, so we have a lot of policies developed and in a lot of smart people here who have implemented policies for access control, for networking, configuration, and so on. The difficult part is really to map those to the controls in the regulated environment that we are talking about and the tools that we have described in the GRC paper will give you a first set, you know, hands-on available tools to author that type of mapping. And the key point is that you don't have to do it every time from scratch. If your team or, you know, in the industry, you have one that is available by using crosswalks, you now are able to reuse one of the mappings that you have in order to support different types of regulated environments. So, one example, if you have your policies already mapped to NIST because there are already cross maps between NIST and high trust or NIST and SOC2, or you are able now to leverage those policies to support your other regulations. And another good point that Andy made on the CACD, yes, you want to shift left but you want to do that smartly. You want to write once and use multiple times, meaning that the same policy that is used at runtime, you want the same policy to be leveraged at shift left. Why? Because the semantics must be the same. If your customer sees that they are red at runtime but green at CACD time and we use different policies, the semantics might not be the same. So, that red and green may not align but if we write once and use multiple times, then the semantics are aligned and we know that those two mean the same thing. And all these points, if you read the paper that Robert mentioned, you are going to find those details, those principles of GRC in the paper. Great. I just wanted to close off this idea of the team collaboration. At the end of the day, someone has to own this problem if you think about the racy matrix. And this is really to all the panelists. Who do you see owns this today? Who do you think should own this? Accountability and responsibility for implementing these. Anyone? Yeah, so the trend that we are starting to see and you'll hear about in a lot of talks today is this shift from, you know, we have had administrators, system administrators moving to DevOps or DevSecOps, and now you hear a lot about platform engineering, right? And it's not that DevOps isn't necessary or is going away anytime. Platform engineering sort of incorporates that but more and more what we're starting to see, especially really in like mid to large enterprises, is that the platform team is taking on the responsibility of guardrails, right? Because the whole value proposition of a platform is developer self-service and by definition to be able to do that and if you want secure self-service, you are going to need policy and guardrail to be baked in into the platform itself. So making sure, again, going back to the point of, you know, policy as code, making sure that the platform engineering team is looking at this as one of their items on their checklist as they're, you know, providing access to infrastructure, access to other application services. But then of course doing it in a manner where also security and developers can collaborate on that because if developers don't understand the policy results, you can shift as far left as you want. They're not going to do anything about it if they don't know what that means, right? So it's important we're all kind of, you know, speaking the same language and that's one of the benefits of using Kubernetes as the platform for building platforms is you get that level of standardization across teams. Go ahead, please. Yeah, and you're using policy as code. So, you know, rather than collaborating with each other with a sheet or a document, if you're following GitOps type of processes, you start collaborating with multiple stakeholders within your organization by, you know, code commits and peer reviews and things like that. So you are introducing the SDLC best practices through policies and that actually saves you a lot of time like Andy was suggesting. I think those answers cover the, you know, who's responsible for implementing policy and guardrails. But I think what we were missing in the racy chart as Robert asked us is accountability and, you know, the why of the policy. And I think that's a difficult question depending on the organization that you're in, but somebody has to own compliance. And so whoever that compliance team is, whether it's security or whether it's, you know, somebody in the C-suite or whatever, has to be able to speak that language. And so I think this is where the work with OSCAL is going to be beneficial to be able to speak that language top to bottom. Okay. I can add one word to the OSCAL. Again, this is the NIST standard for compliance as code. It's not just the languages. It provides also a framework. It covers at least seven different personas with very clear separation of duties. This is the layer that you have between the governance and the policy as code. So the moment you need regulated environment, that is really the layer that starts now bringing or bridging the, more of the operational side, developer side, the policies as code into a language that is more familiar to the C-suite that Andy mentioned. So in this framework, we have the artifact for the regulators. We have the artifact for CISO. And the core artifact that I would expect the audience here is interested is called component definition. The component definition in OSCAL allows the technology owners, product owners, software developers, hardware teams, product owners, process owners. We are talking about batch processing for processes. Component definition allows to describe how the technology implements the controls. And this is your key element, key artifact to go from the manual processes into compliance digitization and bridging into the policy as code that you have today. So that separation of duty allows the right persona in this suite of personas to take the lead. So there are, I have seen teams where it's more bottom up. It starts with the policy as code and then you start to see how it's mapping, how relevant I am to NIST, how relevant I am to high trust. And you also have more of the green field where you start with the CISO teams. They define the baseline, they define the, and then this comes as requirements to develop those policy as code. So I think both type of approaches have, I have noticed them being viable. At the end of the day, what you need is a common language with the auditor so that what you provide to them has the right evidence. And the evidence obviously is not going to come at the controls level. It's going to come from the really, you know, the policy as code and the information, the data that is collected in order to validate that that configuration is correct or the inventory, what is the type of policy that we are dealing with. If you could pass the mic back to Andy. I wanted to revisit something you said, Andy, about that accountability and especially the C-suite. And also we've kind of been framing policy and compliance more as kind of a checkbox toil exercise. And it can be used, you know, most people think of security policy, but I think there are other opportunities to use policy as guardrails. I think, Jim, you mentioned our best practices, Poonam. So if you were to make recommendations how you've seen policy in a more positive light that the C-suite would pay attention to, maybe you can give us some observation. Yeah, I mean, I'm a little biased because of who I work for, but I think cost is a great opportunity for policy to be used for good in order to enforce policies that help us right-size our clusters, reduce costs, and implement better resource requests and limits over time in our clusters. Anyone else? Yeah, please. Yeah, one thing to add to that and this also, you know, of course, every organization wants to move faster, wants to deliver value faster to their customers. So also, you know, policies to generate resources, policies to configure things on the fly. So we all know of, you know, control loops within Kubernetes, right? Every Kubernetes controller runs a control loop within the cluster. You have GitOps controllers running wider control loops, but policy engines can also run a control loop and look for certain triggers. Let's say when a namespace is created, automatically generating default network policies, automatically configuring roles, role bindings, things like that, that could also be policy-based. And all of this is, again, leading towards secure self-service, which allows developers to move faster, but without breaking things. Yeah, and if you have used OpaGateKeeper, I'm sure Kverno as well, there is mutating Webhook, which is available in both of these policy engines. So if you have some best practices for your, you know, SRE or operational purposes, for example, every service should have a liveliness probe. Or, you know, your memory or CPU usage should not exceed this. You can actually apply those type of best practices using the mutating admission Webhook as well. Although not technically, it's a little bit complex, but it does standardize a way of either implementing, you know, cost optimization or operational best practices for your organization. You can have a central control rather than everybody being aware of those best practices. Just very fast. I have two quick questions. How many of you believe that we are able to generate those policies as code via AI? A few hands, yeah. Okay. How many of you would like to see those policies generated via AI? Yeah, many more hands. Okay, thank you. So actually, either any of the panelists, just following up on the kind of the pros and cons and, you know, again, that C-suite view, what kind of, they're going to ask what's the return on investment? Because there's people investments, time and priority investments, and then maybe actual infrastructure, software, licenses. So help us understand the pitch that someone needs to make to the C-suite. What's the ROI? So one simple, you know, kind of rule of thumb, and we all, you know, again, whether we label ourselves SREs or DevOps or platform teams, you know, these teams tend to be fairly small within large organizations, right? So if the ratio of platform engineers to developers, let's say, if you're trying to get to 1 to 100, to do that, you need automation as much as possible. You want to codify as many things as possible, but you want to do it in a collaborative way. So one good metric is just that ratio of how many DevOps or platform engineers do you need for a developer and getting to, you know, that 1 to 100 type of thing to be able to service. Now, of course, in smaller organizations these engineers may be just part of, you know, the development teams itself, but in larger organizations that may be a good metric to track. Yeah, and if you're looking at your compliance and risk, it becomes very expensive if you know, you are not compliant, you are not meeting certain guardrails which are important for your businesses. It could lead to reputational or business loss as well. So, you know, considering automating all the guardrails which are important for business as well as implementing compliance as code would actually lead to a better security or compliance posture for your organization and ultimately will lead to saving a lot of money, time, effort for everyone. And I'm going to pick on Prina Minanka as kind of representing cloud service providers host providers. Is that the responsibility of the cloud platform providing the Kubernetes infrastructure or does it rightly belong more on the independent operators and users? So security, governance and compliance they are shared responsibilities. A cloud provider can have a very compliant and secure platform, but you may have applications running on top of that platform which are not compliant. So it's always going to be a shared responsibility, although using some of the standard compliance as code mapping so I kind of like to think about this in a three-step process. You go through any compliance framework or standard you understand the plain English, you map it to Kubernetes you write a policy for it. You apply it and then you can achieve continuous compliance like Anka was describing. But ultimately you have to have a coverage for your platform again going back to the two C's clusters as well as containers to make sure the whole stack is compliant. Thank you Poonam. So we are in these guys together. The key point is the customer responsibility metrics. Look out for the upcoming Cascale artifact for that and I think that would help to clarify what is inherited and what is in the hands of the provider because when we have offering as a service the managed part obviously it's in the hands of the provider. We know how to take care of that. But as you know in security we are as secure as the weakest link so having a clear representation of the shared responsibilities as Poonam mentioned is key here. I wanted to leave a couple minutes for questions so before we get to that I just wanted to make sure that everyone attends the meetings if possible. I would like to say join the mail list the group. And then Thursday there will be a meet the contributor community so please welcome everyone to join that. And then there's a feedback QR code so I guess we can open it up to some questions from the audience if anyone has. I think there's a microphone in the middle aisle or you really want to shout it out so one best practice that's emerging and there are standards like salsa or supply chain levels for software artifacts that are emerging is to run certain checks in your CI pipelines and now with OCI 1.1 what you can do is attach artifacts signed artifacts to your images which policy engines like Kibirno or OPA gatekeeper can verify before allowing that image to run in your cluster. So following that is a great approach because it now centralizes some of the gathering of this information whether it's a DAS tool, ASAS tool, other provenance generators, other things you want to run in your CI pipeline. Collect that information, sign it attach the attestments and then verify through policies. And Jim and I were having this conversation earlier today where your policies are also code so you can have an OCI image for your policies you could sign it and then you know for sure like which policy is deployed where and you propagate it to your test production exactly like you're propagating your workloads or applications. Right once use multiple times. Absolutely. I think we have time for probably one more question if anyone have. Well thank you everyone for joining today and before we go just a quick announcement I've been serving as co-chair now for a couple of years and I decided to move on and I have the privilege and honor to welcome Poonam and Andy as new co-chairs of the policy work group so thank you. I'm sure that you grow the group and get more people to attend. Thank you everyone for joining. Thank you so much.