 Hi everyone, can you hear me? Okay, thank you very much for attending our session. Today, Yuji and I are going to talk about how to apply policy-based governance and ensure the integrity of policies. So I'll be talking a little bit about what we mean by policy-based governance and the concepts and stuff and then Yuji will go into more details on what is approached to enable integrity and also do a short demo. Just to quickly introduce ourselves, I am a Distinguished Engineer at Red Hat and have been working in the security compliance and governance space for many years now and Yuji here is at IBM Research in Tokyo and he has also been working in the security space for a long time. Okay, let me talk a little bit about what do we mean by policy-based governance and what are the various aspects about it? So first of all, you know, why do we need it? So if you think about Kubernetes-based cloud platform, enterprises that use it have to operate it to meet various controls, enterprise standards, both internal standards that their CISO sets, as well as external standards like regulatory compliance standards, PCI, HIPAA, etc. So, and you want to be able to accomplish meeting those goals with minimal operational cost. So, applying the policy-based governance approach enables you to do that because you are providing a more automated way of accomplishing these goals. So, what do we really mean by policy-based governance? What we mean is that if you look at a particular cloud platform that is being managed, whether it is on-prem or whether it is hosted in the cloud, there are various personas involved in using that platform. You know, there are application developers who are running workloads on that platform. There are site reliability engineers and administrators who need to operate it to meet security, resiliency, and software engineering standards. And there are sec ops for folks who are worried about the security aspects of the platform. And there are compliance engineers who have to produce evidence for audits and they're dealing with auditors for various regulatory compliance standards. And then you also have the CISO who also sets their own standards as well. So, you have to deal with the CISO security architects as well. So, you have all these different personas who are involved. And how do we ensure that those personas are collaborating on a more day-to-day basis as opposed to just scrambling during audits and so on. So, that's really what policy-based governance allows you to accomplish. And let's talk about how. The how is, how do we do this is you represent best practices as policies. And these policies are stored in a repository like Git. And they are managed just like source code. And they are deployed using GitHub's methodology. And then any violations are detected and routed to, you know, instant management tools so that you can either automatically remediate those violations or you at least have automated opening of service tickets and so on. And then you can also fine-tune the policies to, based on the day-to-day experience. So, that's really what we mean in terms of how we want to do this. And then what are the benefits of taking this approach? One of the key benefits is reduction of the operational cost. Because if you think about it, the people who are really managing the platform are necessarily not the experts in all aspects. So, they may not know, you know, exactly how to enable various security controls or resiliency controls and so on. By actually representing those best practices as policies that are managed like source code, now you can have the correct SMEs actually authoring those policies and reviewing them and approving them in Git. So, that is how the operational cost for the SRE and the admins are reduced. And it also, by taking this approach, you're also doing this on a day-to-day basis so that you have a continuous view of how your security posture is, how is your compliance posture by taking this approach. At least for the controls for which you have enabled this. And as I mentioned earlier, it's really important for the day-to-day collaboration to happen among the various personas. Because typically, you know, today what happens is the collaboration happens kind of when there is an audit, you know, and you're getting ready to prepare for the audit. That's when, you know, everybody starts talking and, you know, trying to figure out what to do, right? But if you kind of had that collaboration happening through the GitOps methodology on a day-to-day basis, then it becomes more efficient and you can really achieve the goal of continuous security and audit readiness. So, as part of the Kubernetes Policy Workgroup, we have, we last year published a white paper on policy management, which had this architecture that talks about the various building blocks that you need. The policy administration point is where the policies get pulled in and deployed across the various managed clusters. And then on the managed clusters, you have the policy decision point as well as the various policy engines which act as policy enforcement points that can actually apply those various policies. So, you can look up our white paper there, and we also did a panel session last year at KubeCon, and we're doing another session. This year, Anka here is in the room. She's part of that activity and come and see us at KubeCon. We are going to have a follow-up panel session on this topic. And then I also wanted to highlight that in terms of applying this approach, we do have an open cluster management CNCF sandbox project that has the building blocks needed to apply the policy-based governance approach. And it has this policy add-on component that enables that capability. And some key aspects there are the ability to have templatized policies so that you can, for edge scalability, you don't have to deploy that many policies if you need to customize things on specific clusters. And it also has this capability called policy generator that allows you to take existing policies, whether it is OPA or QNO and so on, and even just regular Kubernetes configuration, and convert them to apply compliance and other metadata to deploy them to the managed clusters. And then we also have this concept called policy sets that allows you to group policies for ease of management, whether you can group policies by PEPs or you can group policies based on specific aspects like security, residency, etc. We also have a policy collection repo where we invite community collaboration to build out these policies. And so take a look at that as well. So with this approach, the key is, since now we are managing best practices as policies, and you are driving the desired configuration state on your clusters using this policy-based approach, then policies become very critical because now they can actually set how your clusters are operating. So that is why the integrity of policies is extremely important because it is a very powerful mechanism. So I'm going to turn it over to Yuji so he can take us through the details of how do we apply integrity, etc. Hi, I'm Yuji Watanabe from IM Research. So as Jay mentioned, policy is a really important piece. So the integrity of policy is really important. If the policy is compromised, total cluster has the damage. So the approach to protect the policy is signature. So by using signature, we can allow us to check the policy integrity and control the policy who can define the policy. But the question is the policy, this is a policy for governing total Kubernetes system. So the question is how we can use this policy mechanism to enable the integrity of the policy. That is the question and I am trying to cover in this talk. So the approach is like this. So first policy is signed. I will explain how the policy is signed. The policy is basically signed, then it's delivered to the hub cluster, then it's deployed to the managed cluster. And on the managed cluster, we put the admission controller to check the signature of the policy. Then if the policy is modified, the admission of the policy is blocked. And so this is the mechanism of the overall approach of the protecting the integrity. So this is the policy signing. So actually, how can we sign the policy? The tool is available on the 6.2.2. It's called K8S Manifest 6.2.2. This works as a plug-in for the QCTL command. By using this command, if you learn this command, the signature annotation is attached on the policy. So this is the encoded message body and the signature encoded by signature. So this is a signing mechanism. So then I will type this. So the enforcement site is we use admission controller. We actually published a project called Integral Tissue. This is admission controller for the signature manifest signature. And this works with OPA Gatekeeper. And it provides a webhook API backup. And also in the latest release, we worked with Kibern team to enable this signature verification capability on Kibern. So by using this YAML Manifest signature verification enforcement, we can block the admission of the policy, which is compromised. Or even after the admission, this tool can be used to check the policies in the cluster. So it's a continuous way. So this is an enforcement mechanism. Thank you. But the question is how this mechanism can be deployed, can be enabled on the large number of managed clusters. So for deploying this admission control we use policy. So actually the Integral Tissue policy is used to deploy the Integral Tissue admission control on the managed cluster. Then also we have two different policies. One is for detecting the deny admission events to the cluster. So we can detect what kind of admission request is actually blocked by, because of the birth signature. And we have another mechanism called observer policy. So it works with Integral Tissue to check the existing or existing resources matching with policy. So by using these three policies, these policies are deployed by the ocean mechanism, then the managed cluster integrity of the policy is protected on the managed cluster. And this is an example. So the first this is if the policy, this is a command to check the policy on the cluster. So all policies, three policies, Integral Tissue policy, event policy, observer policy, all the state is compliant. Then let's assume we create some sample policy. So sample policy is not signed. So then I try to deploy this sample policy to the target cluster where you have, but if it's loaded to have, then have pushed that policy to the managed cluster. But the protection of the managed cluster is inhibited. It actually detects the signature violation and reports the, reports the non-compliant. So in this case, so Integral Tissue event policy reports the compliance, non-compliant. This means some deny event is coming to the cluster. So this is, this is because the sample policy is does not have the proper signature. So if the signature is, later, if the signature is properly attached, then admission request coming again, then the state becomes compliant. Okay. So for that, use the SIGS to CLA, CUBE CT plug-in to create the YAM sign-in, then applies the policy to the cluster. So these two could generate the, attach the annotation to the original policy. So this is the new YAML file which has annotated, signature annotation. Then in this case, it's coming to the cluster. Then the policy becomes compliant. Okay. So this, I talked about how the signature enforcement and signature verification can be enabled by using the policy mechanism. Another question is if the one cluster has, is, is used for the signing something. So for example, actually the policy signing. So in that case, the signature must be delivered to the cluster. So this approach, this is a proposal, one proposed approach to use the board connected to the hub cluster. Then the, the signature signing key is stored in the board. Then by using policy mechanism, the key is delivered through the hub. But this delivery is done by the encryption. So the key is securely delivered to the target cluster. So by using this, the key is not stored in the disk cluster directly. And no need to manage the direct collection between the board and the cluster. So how can be the kind of the secret delivery distribution hub for distributing the secret to the target cluster like the signing key? So for this, again, we use the policy mechanism. So the design is like this. So we use the external secret operator, which enables us to bring the secret on the board to the cluster, cluster secret automatically by using the, that automation is provided by the external secret operator. So, so external secret operator, we use the external secret operator. Another building block is the policy template. It's, we can define the policy, but the policy has a template. So some template can, can increase some value in the policy and deliver to the target. We can deliver the value to the target cluster securely. So by combining these two approaches, we can enable the kind of the secret distribution hub idea. So first, two policy, we use two policy. First one is, of course, the policy template to deliver the secret on the hub to the target cluster. Then the second one is policy for the external secret. This, so this policy is used to create the external secret on the hub cluster. Then secret, this, this, this external secret, this custom resource is created. The external secret operator automatically loads the key from the board to the target hub cluster. Then this secret is loaded into the policy template. Then this is delivered in the encrypted home. So the, so the, this is an example of the template, policy template example. So the, this is a policy that here you can see the template. The, this is the hub, the some secret on the hub is loaded into the here and, but, but it must be encrypted on the secret. So it's, so basically the hub and managed cluster has a common secret for encrypting the data. So by, so the templates, template engine on the hub cluster actually loads the secret on the, on the hub. Then encrypt the, encrypt and embed the value here. So as you can see, so this is encrypted. So the value, then the, so basically this policy is delivered to the target cluster. So, but the policy itself has, doesn't leak the secret because this is encrypted. Then if this policy, encrypted policy goes to the managed cluster, this part is decrypted by using the common shared secret key on the, on the managed cluster side. So that's the mechanism of deployment. Okay. Okay. So the, this is a final phase. So we proposed the, in this talk, how we can protect the integrity of the policy by using the policy, policy mechanism. So the signing and enforcement and monitoring and the key distribution is covered. And so we have the several talk related to the, to this session, this, this, this talk that we, in the, in this afternoon that we have the another, another session for the Kibern, Yammer, Yammer-Maribus signing verification on the Kibernok. This is the new release. This is the joint, joint presentation with Jim Baguario. And the second one is, Jaya mentioned the policy governance talk, is the main Kibernok session. And the last one is we are, we talk about how this manifest signing and enforcement can be enabled in the CDK top scenario. So we have several, so if you are interested, please come, come. Thank you. Thank you. I see that you apply your basic technology now in synergy with other platforms that badly need this, this capability. I was wondering if you could share with us what you have next in the roadmap because it looks fantastic. Thank you, Anka. Yeah. So what we have in our roadmap, so, so what we talked about, what UG talked in detail was how to protect policies with integrity, right? But then the other talk also, we expanded that work and we are applying it to any Kubernetes resources. So it could, it could be application artifacts and such. So, so this is essentially a broader concept than that. So now what we are also doing is to apply this for automation aspects, right? So you take, you have Ansible that is used for automation. Now we can also sign Ansible playbooks. Because if you think about it, when I talked about policy-based governance, when you detect a violation, you want to be able to auto-remediate violations. So you make yourself an automation to do it. So how do you ensure that that automation is also has protected with integrity? So we have, in fact, there was a presentation last week, I believe in Ansible Fest where we talked about that, protecting integrity of Ansible playbooks. So we have, we are basically applying this whole concept so that the full life cycle is protected, right? And, and we want to have a consistent approach to do that. Okay, Mike, correct and thank you. I'm not too familiar with these policies. Mike, correct and thinking that say you didn't sign the policy, you didn't protect it. And a person, a hacker got in and modified that policy. It's not that doing that would allow them to do things they otherwise couldn't do, because our back and things like that would be in effect. It's just that the management, technical management wouldn't be notified that a policy had been violated. So basically it would be shutting down the warning system by changing the policy to allow something that management typically wouldn't let them do. Is that correct? Yeah. Okay. Yeah, and I think to add to that, right, you are essentially using policies to define how your managed clusters are configured, right? And some of the configuration could be related to security and stuff, right? So I agree with you that, you know, on-get itself, where the policies are managed as closed, you still have those governance mechanisms around our back and such. And this is adding another layer to it to ensure that by mistake or, you know, incorrectly, you know, you're not changing some configuration that now results in your security controls not operating to the standards that you want, right? So that's right. Is there another question? I guess not. Thank you very much for attending.