 Thank you for this opportunity. I am J.R. Aminathan. I'm the Chief Security and Governance Architect for our Advanced Cluster Management offering. I have with me Yutao. He is the squad lead for our security and governance capabilities within. Both of us work on this project called Advanced Cluster Management for Kubernetes within Red Hat. We also have an upstream community called Open Cluster Management. We're here to talk about just some underlying principles and overall architecture of our security and governance capability. Then we'll delve deep into OPA and Gatekeeper and how that integrates with ACM. This chart basically talks about the various security and compliance challenges that customers face when they adopt Cloud. Specifically, the key thing I wanted to highlight here is customers generally have to meet various enterprise standards as well as industry standards. For example, if they are in regulated industries like financial, healthcare, etc., they have to meet standards like PCI, HIPAA, etc. They also want to adopt open technologies, and they typically have to deal with more than one Cloud provider, and they also need to go through multiple audits. Really what they're looking for is the ability to maintain security and audit readiness on a continuous basis, and they want to do that for an open hybrid Cloud. So our approach to achieve that goal of continuous security and audit readiness is policy-based governance. So what do we mean by that? Typically, if you take a particular Cloud environment, say Red Hat OpenShift Cloud Platform, and you want to secure it, the customer would enable various security capabilities that OpenShift provides out of the box, and they may also want to use some capabilities provided by third-party and some home-grown capabilities as well. And what they would like to do is to ensure that all these security controls are configured to industry best practices or their enterprise standards, and these standards could include standards from NIST, like NIST CSF, NIST 853, and also, like I mentioned, industry segment standards like PCI, HIPAA, etc. So the subject matter expert for a particular control knows very well how to get that control set up, but if you're talking about a SRE or a SecOps person who is responsible for ensuring that the configuration is set up properly, they may not be an expert on all the aspects of security. So how do we make this easy for them? So the way we make this easy for them is by ensuring that these best practices are represented as policies that result in a desired configuration state. So that's the overall approach, and that's what we refer to as policy-based governance. And in order to do this, what we have built out is an extensible policy framework that can be applied across the entire stack. It allows you to incorporate multiple policy languages easily, and so that's what we'll talk about in detail, the Gatekeeper OPA, which is one of the policy languages, and you will also show a demo on how that can be done. And we provide a lot of out-of-the-box content, but we want to make sure that content is customizable, and we need the ability to easily integrate third-party controls, et cetera. So that's kind of the overall approach of policy-based governance. So I want to introduce some terminology here just to level-set what you're talking about here. So if you think about policy-based governance, so there is a policy authoring point where the policy is specified. Now, this authoring point could be either the console or it could be a CLI or it could be GitOps. Our preferred methodology is GitOps. The reason being that allows you to manage policies just like you will manage source code. So you define all the policies in Git, and then within our ACM product, you can define a subscription to pull those policies and deploy them onto the managed clusters. So that is our policy management point. So this distributes the policy. It consolidates policy violations across a fleet of clusters. It also allows you to integrate with enterprise tools from a central point, because that is how customers view the cloud as just an extension of their existing IT infrastructure. So they want the management to integrate with their incident management systems, security operations center, their enterprise GRC tools, et cetera. And then the policy gets distributed to the managed cluster. On the managed cluster, you have policy enforcement points. And these consume the policy and they return the violations. So an example of enforcement point would be the Kubernetes Admission Webhooks and also the runtime controllers, Kubernetes controllers themselves, as well as several controllers that we provide, the configuration policy controller and the certificate management controller, as well as any operator that runs on OpenShift managed cluster can also serve as a policy enforcement point. And one of the examples of the operator is the compliance operator that allows you to implement security profiles on your OpenShift clusters. So, and then the policy enforcement point can optionally invoke a policy decision point to check whether a specified policy matches how a control is configured. Now, in some cases, the policy enforcement point may itself do this check, but in other cases, you could invoke a PDP. And the gatekeeper OPPA integration is one such example and Kubernetes is another example. So based on this terminology, here is the overall architecture. So as you can see here on the management hub, this is where the policies are defined. And as I mentioned, it can come through from gate or it could be through UI or CLI. And then from here, it gets distributed to the managed clusters. And then here you have the various policy consumers. These are essentially the policy enforcement points that we talked about. And then these results are then collated back. And so you have everything available in a central manner. There are a few roadmap items that we are highlighted here where we want the policy framework to associate Ansible Playbooks to trigger automated playbooks for policy violations. And we also want to integrate the policy violations and generate alerts to the observability component, which can then integrate with the enterprise incident management tools. And we also want to route audit logs to SIMS for the security operations center. These are all the orange items in this chart are things that are roadmap items. So now I want to drill down into details of how we have integrated with gatekeeper and OPPA. So let me start with a quick overview of gatekeeper and OPPA. So gatekeeper allows you to evaluate compliance of Kubernetes resources to specify policies. And what it leverages under the covers is OPPA. And OPPA is the policy engine that it uses. Now OPPA itself accepts policies in a language called rego. So think of gatekeeper as providing the bridge from OPPA to Kubernetes, to the Kubernetes world. So it allows you to specify the policies as Kubernetes constraints, which can in turn contain the rego constructs. And gatekeeper can then consume those because it registers itself as a policy enforcement point through the webhook. And so it's now able to pass on those rego constructs to OPPA and use OPPA to do the actual checks of whether the policy is complied to. So two scenarios to consider here. One is the admission scenario. So this is executed whenever a Kubernetes resource is created or operated. And so think of it as once the gatekeeper policy is in place, then any new resources that get created will be governed by this admission control. But what if some resources already exist before you put that policy in place? So that is the second scenario, which is the audit scenario. So the audit scenario allows you to periodically evaluate existing resources against policies to detect any non-compliances. So in order to complete the picture, there were a couple of things we had to do in terms of how we integrated gatekeeper and OPPA into ACM. First of all, we are going to deliver operator that can deploy gatekeeper and OPPA. And so this work is actually progressing in the upstream community. And what we have done is we have focused the community and made it part of our open cluster management downstream. So we will deliver this as part of the ACM product. So one of the cool things about the ACM product is our built-in policy controller, config policy controller can pretty much distribute any Kubernetes CRs. Now the deployment of operators itself is represented as a CR. So by delivering gatekeeper OPPA as an operator, now you can just define an ACM policy that ensures that this operator is deployed on the managed clusters. So we are going to provide that. In addition, you can also use ACM to define policies on what gatekeeper itself is enforcing. So the constraints that I talked about. So those can be also authored within RACM and propagated to the managed clusters. And then as I mentioned, there are two scenarios, admission and audit scenarios. So in both cases, we want to be able to detect policy violations. So in the case of the admission scenario, we just, we have a RACM config policy that can process the events that are generated by the gatekeeper webhook. And in the case of audit scenario, we look for the status field in the gatekeeper constraints. So we are able to pull both this information back as I showed in the architecture into the central ACM hub and display the results there. So this architecture diagram pictorially depicts what I talked about. So you have the RACM hub and then, which is distributing policies to your managed cluster and within the managed cluster, you have the config policy controller. And because we have this built-in config policy controller, the whole integration with gatekeeper OPPA is happening just through the authoring of these policies. So you really don't have to write any code. So we have a policy that we have authored to deploy the gatekeeper operator. So that operator is then watches over this gatekeeper CR. And then it registers this webhook that monitors the audit admission scenarios. And then you will also have a policy to deploy the gatekeeper constraints. So, and then we have a policy, as I mentioned, to detect the violations two policies, one for audit and one for that mission scenarios. So, you is going to give us a demo on these capabilities. But before I hand it over to you, I also want to highlight that we have also, we also have integration in place with ACM for the OpenShift Compliance operator, which is another, an example of an operator that can be deployed on the managed cluster. And through a RACM policy, we can make sure this operator is deployed. And we also have another policy that allows you to specify a profile, security profile that directs the compliance operator to perform the compliance checks and return results back to us. So we'll show a quick demo of that as well. That kind of is the quick short overview. And I have in this chart a link to our OpenFuster management community. And you can connect with us. And ask any questions, et cetera. Before I turn it over to you, I also want to give you a quick demo of our OpenFuster management community. So, as I mentioned, when I provided the overview of policy-based governance, typically you have various controls in place. And the controls could be for security, could be for resiliency, could be for software engineering. And you want to ensure that all these controls are configured properly to industry standards and enterprise standards. And in order to do that, our goal is to codify those standards as policies. And so it's very clear that Red Hat on our own cannot produce all the policies needed by all our customers. So that's why we have created this policy collection repo. So it's a spot for us to collaborate to build out these policies. So if you look at this repo, we have two folders. We have a community folder and we have a stable folder. So the stable folder includes all the policies that are delivered as part of the ACM product. They are fully supported by Red Hat. And these policies are organized in terms of the NIST 853 standard. So you have various controls within this security controls within this catalog. And then for each of the controls, you can see we have defined policies. So, and you is going to show us a demo of the compliance operator policy that can deploy the compliance operator. And also this essentially a security profile policy that allows you to scan the managed cluster for this particular security profile. And then for Gatekeeper and OPA, we have policies as well. And then there is the other folder here, which is the community folder. So the community folder is where we invite contributions from the community. And these policies are also organized in terms of the NIST 853 standard. And the Gatekeeper policies currently are in the community. And the reason is because we are currently working on an ACM release where we are productizing this capability. So they right now sit in the community. So you have a Gatekeeper operator policy that allows you to deploy the Gatekeeper operator. And then we also have other policies for Gatekeeper contributed here as well. So you can see here, we also have third party contributing policies here. So you will see here a policy from Cystic. They have contributed a policy for their operator. So the reason I wanted to highlight this is to invite contributions from the community. So we are also working with various customers to have them contribute here as well. Jaya, if people, I think the OCM team group is meeting on a semi-regular basis now. Have they started the community meetings? Yes, we have started the community. The open cluster management has a community meeting that happens weekly. And definitely invite participation in that as well. So I can include that link as well into the chart. Okay, that would be great. And there's one quick question here before we go to the demo. Tobias is asking if the Gatekeeper community would announce mutating admission controller, will you integrate such an option into Rackham? Yes, so we are active participants of the Gatekeeper community. You who is here on the call with me along with a couple of others from Red Hat are active contributors there as well. So we are watching the space there and our goal is to keep up with any enhancements that are made in Gatekeeper and associate policies in Rackham to adopt those, yes. That's our goal. I am so grateful that you finally said that acronym out loud and it's Rackham because that's a wonderful way to pronounce it. So I'm gonna use that going forward. So thank you. Yeah, that's a good point. Let me clarify. Rackham and ACM stand for the same thing. ACM is Advanced Cluster Management and Rackham is Red Hat Advanced Cluster Management, the same product offering. And our upstream community is the open cluster management community, which is this one. And Ginny just shared a link in the chat for the open cluster management community. There's a projects page in the repo that you can find the agenda and things like that for the upcoming meetings. I'm going to stop sharing now and turn it over to you. Perfect. Yeah, welcome for the questions as well. Thank you. All right, let me share my screen first. So, hi everybody. My name is Yu Tao. So I'm the Dev Lee for Rackham Security and Compliance team. So today I'm going to do a quick demo for how you can use Rackham policy to install Gatekeeper and then apply a Gatekeeper constraint on the managed cluster and then report any violations it detects. So, first of all, let me recap a little bit about the governance and risk architecture in Rackham products. So if you go to our product documentation, there's an overall architecture diagram here. So if you click on it, you will see a large diagram. So the governance policy framework we put in place, it really consists of multiple piece, right? So there's a one piece on the hub and there's a few piece on the managed cluster. So on the left, so on the hub, so we have policy propagator, which is responsible for propagating the policy from hub to managed cluster. So how it does is so when you create a policy, you need to also create a placement binding and placement rule. So if you look at the sample here, so we have a policy CRD, which is the CRD that we use to invent your, the real policy. So if you look at the CRD definition here, so we have a field called policy templates. So inside templates, you define the actual policy you want to apply on your managed cluster. So you can create a policy with multiple policy templates using different policy language. And then once this is created, you also create a placement rule. So since Rackham is managing the control plane, they're managing multiple clusters, right? So when you import a cluster, you can label a cluster. So the placement rule simply here is you can select a cluster either using the label selector. So we call cluster selector, but what really does is it's using labels on the cluster so that you can select a subset of cluster of a divine. For example, in this case, it's all your dev clusters. And then create a placement binding that find the policy and placement to basically tell our policy propagator this policy needs to be applied to these cluster. So this is how we propagate policy to manage cluster. So the reason I explain this is, so this is the framework that to distribute policies and the actual policy that is being executed or evaluated on the managed cluster is we call it policy controllers or policy consumers on the managed cluster. So the framework propagates the policy to manage cluster, distribute them to the managed cluster and then hand it over to the actual policy consumer installed on your managed cluster. For example, the gatekeeper policy consumer or compliance operator or the auto box policy controller that we ship, Recom ship, for example, the configuration policy controller. So once it's reached the managed cluster, the actual policy consumer on the managed cluster will apply, evaluates the policy past in and then generate results. And the policy framework will retrieve those results and return it to the hub so that you can view the results through single control plane using Recom console. So that's the governance framework, policy framework we put in place for Recom. So in terms of gatekeeper policy, so from this big picture, so gatekeeper controller is one of the policy consumer from Recom policy framework perspective. Now let's take a look at the actual gatekeeper policy. So we've talked about that we can use the Recom policy to install gatekeeper and we can also use the Recom policy to apply gatekeeper constraints and then collect the results back to the hub. So this is done through defining Recom policy. So as Jay mentioned, in this policy collection repo, you can find the gatekeeper operator policy and also some, a few other gatekeeper policy that actually applies certain constraints on your clusters. So let me take a sample here. Let me go through in details. For example, the first, the gatekeeper operator. Gatekeeper operator is an effort that we will be actually involved in the upstream community. So what gatekeeper operator does is it packs, it packs the gatekeeper as an open-shift operator. The operator responsible for the lifecycle of gatekeeper. So it can install gatekeeper, it can delete gatekeeper. Of course we are also working on upgrading those kinds of stuff. So it controls the whole lifecycle of gatekeeper. It simply makes installing gatekeeper easier. With gatekeeper being delivered as a gatekeeper operator in ORM or in OCP catalog, you can use Recom policy to install gatekeeper across all your managed cluster. So what you need to do here is you define a policy CR here and then it includes multiple templates. So just very similar to how you install an operator from ORM. So you create a namespace. We define the catalog source. Currently the gatekeeper operator is not published yet. So we have to define a custom catalog source. And then you create a operator group to tell operator which namespace to operate on. And then the subscription to subscribe to the catalog to pull down the gatekeeper images. And then you create this gatekeeper CR. This gatekeeper CR is part of gatekeeper operator. So it tells you how to configure gatekeeper. But if you create this CR, the gatekeeper operator will install the gatekeeper based on the spec the configuration provide. If you delete this gatekeeper CR, the gatekeeper operator will delete the gatekeeper instance on your cluster. So here, as you can see, we are pulling an image from upstream gatekeeper as this. And then we enable the admission events flag so that we can, so that when there's a violation January for any new, when there's a violation January for any new resource created on a managed cluster that is blocked by the gatekeeper, it will generate a Kubernetes events. So this is for the purpose for Reckham to be able to collect the result for admission scenario. So then, so once this policy is created, then it will be based on the cluster selected here, right? So it will install the gatekeeper operator on managed cluster. So for this is the Reckham console. So I have a gatekeeper operator policy installed here. So as you can see, this policy currently is being applied to this managed cluster. So if you go to this managed cluster here, it was, so this is currently being, this policy is being enforced and it's compliant. So this means the operator has been installed on your managed cluster. So if you go to the OCB console here on this managed cluster, this is not a managed cluster, let me open, this is the managed cluster. And then if you go to operator here, go to install operator, you'll see gatekeeper operator here. So it is so very simple. So you just need to use this operator. You just need to use Reckham to install this operator for you. And then the gatekeeper is installed on a managed cluster. So now let's take a look at the, how you can apply gatekeeper constraints and then report violation back. So installing gatekeeper is just the first step, right? What really has value is, you want to apply gatekeeper constraint and constraint template and then collect results back. So here we, I create a sample, I create a gatekeeper sample policy here. So I think it's easier to look at in here, in this code. In this code, so gatekeeper. So this is from the gatekeeper, this is from the policy collection repo. You can find it in policy collection repo. So same here, we are using the same policy CR to distribute the gatekeeper constraint template. As you can see, we have three templates here. If you look at the details, right? This is actually leveraging the configuration policy, which is the auto box policy consumership in Reckham. So what it does is, what it does is it can create, update, delete resources on the cluster based on the template object that definition you provide. So if you look at the CR fields here, so you create a configuration policy, it has object templates inside the spec. So in this object templates, anything defining this object template field is the actual CR you want to create in this example. So currently we are using compliance type must have, which means you must have an object with this CR. So look at this. So this is a gatekeeper constraint template, right? So basically how we integrate is, if you have a constraint template and constraint CR already, so you can use configuration policy to create it on the managed cluster. So what you just need to do is, you just need to embed the constraint template inside a configuration policy, and then put it into policy CR, which is responsible for distributed across all the managed cluster. So that's how the constraint template is delivered to manage cluster. So you don't have to write any code, you just need to create this policy and embed your constraint template, same for the constraint here. Then the RACOM policy framework will create these two CRs on the cluster, and then gatekeeper instance, the controllers will take over and evaluate these two CR. So if you look at details of this CR, this is a sample namespace constraint template constraint I took from gatekeeper website. So what it does is it requires any names, and this regular basic defines any input resource, needs to have a field called label, and inside that label field, you need to have a label with name, with name, with certain name. So the name is being exposed as a configurable parameter called labels. And inside the constraint, so you're basically applying this constraint template. I'm here, I'm applying any namespace, and also I restrict the namespace to be these two namespace because I didn't want to apply to ordinary space, but if you remove these, it will be ordinary namespace. And then I want the actual labels to be gatekeeper. So for example, so if we want to test this gatekeeper constraint, basically we can just go ahead and create a namespace without label gatekeeper, then it will be blocked. So let me do that. Here, I believe I've already logged in onto the manage cluster. So let me double check. So here on my manage cluster, for this deployment, I'm actually applying to these two namespace. So if I try to create a namespace, if I do this directly, it will create a namespace without any labels. So you can see here, the gatekeeper actually detect that and block the creation of this namespace. So that means the gatekeeper constraint constraint template that we are applied using Recom policy is actually in place and working. So that's how we distribute and apply a gatekeeper constraint constraint template from Recom console by using a Recom policy. You don't have to log into each manage cluster and apply it, you just need to do it essentially through Recom control plane. Then it's the violation part. We want to be able to collect violations. So if you look at the other two templates that we are embedding in this policy CR, though here, as you can see, we create another configuration policy, right? This is for audit scenario. We name it policy gatekeeper audit. So what it does is it is looking for any CR on a managed cluster called ksrequiredlabel. This is the constraint that we created in previous object template. But additionally, we are adding additional fields to it. So what it means is we are using must have compliance type here. So what it does is we require on your cluster, you need to have a CR called NS must have gatekeeper with this kind and API version. Additionally, we expand the status field with total violation zero. So this is for audit scenario. So the way it works is so once this constraint is being created on a managed cluster, so gatekeeper audit controller will start to scan your entire cluster and then try to figure out if you have any pre-existing, non-compliance exist. So if there is any, it will actually update the status field to tell you, oh, there are some violations pre-exist. So it will increment the number here. So currently we expect the number to be zero. So if it's not zero, then this policy will return non-compliance. That's how we collect the results. So that's how we collect results for audit. And then let's look at the dimension scenario. For dimension scenario, same, we are creating another configuration policy and then we are looking for events for this constraint template, for this constraint. KS require labels and then with name NS must have go gatekeeper. So basically, so as you can see here, we are using constraint type must not have. So we expect there shouldn't be any events with these annotation on a managed cluster, exist on a managed cluster. If it exists, that means there's violations. There's something wrong. So this policy will return non-compliance. So now let's come back to the console here. So as I did, as previously I did this, I tried to create namespace without label. So now as you can see here, it is for this admission template is reporting non-compliance and it tells, oh, there's an event exist in the gatekeeper namespace system. We can click on view details and take a look at what exactly it is. So, oh, this is what is violating this policy. So this event exist, but it should be. And if you click on view YAML, it is going to pull the details of this event. So as you can see, it tells you admission webhook, basically the request is being denied by this constraint from gatekeeper. So this is exactly the same error you've seen here in the command line. So this is how we implement gatekeeper with Reckon. So we integrate gatekeeper not only just installing the gatekeeper and then creating the gatekeeper constraint template, but we also collect the result for both at an audit and admission scenario. Okay, that's my part for the gatekeeper demo. Just to quick mention, thanks to the power of the Out-of-box configuration policy controller shipped with Reckon, so we are able to also, of course, install any operator. So for example, compliance operator here. So compliance operator. So if you look at the YAML here, this policy is also, you can also find an in-policy collection repo. So you can find it here. So a very similar concept. We use configuration policy to create namespace, create operator group, and create subscription. So then the compliance operator is installed on your managed cluster. And then you can trigger a scan. So from using certain profiles. So here, if you look at the EA scan policy here, basically this policy triggers and essential a security profile scan on your managed cluster. And we are also using configuration policy to achieve that. So by just using configuration policy to create scan-set binding, compliance suite, and then collect the result back. So this is all done by doing just creating configuration policy. So you don't have to write any code. You just need to create a YAML of the policy. And then you can integrate with compliance operator and as well as gatekeeper. Okay, that's it for me. That's great. Thanks, Yu. And if I could, this is Kirsten Newcomer. If I could chime in just for a minute at the end of our conversation about the compliance operator. There was in chat a conversation about the difference between the compliance operator and gatekeeper. And I think both Jay and I weighed in and you did a nice job also summarizing that here. So the compliance operator is specifically focused on regulatory controls, technical controls that map to regulatory frameworks. I just wanna share just cause we're really excited. In addition to the E8 profile which is an essential E8 profile from Australia. There are some, the compliance profiles available with the OpenShift compliance operator includes some controls that meet NIST 808 53 regulatory requirements including at rail core OS, not just the Kubernetes layer. And we just shipped a profile for that is inspired by the CIS Kubernetes benchmark. So check that out if when you get a chance. And I don't know if there are other questions. I've kind of been thinking of a few that I wondered if whether they might be helpful to folks. And they kind of tie back to OPA versus gatekeeper versus the compliance operator. Jay, you mentioned kind of three types of policies, policy categories. You mentioned security, resiliency. You also mentioned software engineering. I think we have, I think maybe it would be useful to give some examples of each of them. Does that make sense? Yeah, can I grab the share again? Please do. I think you should be able to see my screen, right? It's coming, there it is. Okay, so this is the policy collection repo and then if you go down to the bottom of this repo, this page, we have a lot of blogs here. And one of the blogs I wanted to highlight here is this blog. And this blog talks about how you can implement policy-based governance using our configuration management capabilities, right? And here we talk about like Kristen, you were asking, there are best practices for three areas that I outlined, which is security, resiliency and software engineering. And this blog goes into the details of how you can, of examples in each of these categories, right? So for example, for security and regulatory compliance, the first one we list obviously is the compliance operator, right? So we talk about how that can be configured using RACM. And then we talk about the HCD encryption. So there's a policy that's available to ensure that the Kubernetes HCD database is encrypted, right? And also you can remove the queue badminton because the best practice obviously is to not use a single administrative account, right? You want to be able to use different accounts for different users to have accountability. And then policies for role-based access control and SEC security cost constraints, et cetera, right? So these are examples of security-oriented policies but you can also have policies for resiliency. So for example, if you want to make sure that the logging operator is installed because you want to be able to collect logs to check the health of clusters, et cetera. So you can do that. And many of the gatekeeper policies that we have as examples here, I have to go back to the community. So there are gatekeeper policies for ensuring liveness check is in place and make sure you're using the latest container image. These kinds of policies, readiness probe is in place. These are all resiliency-related policies, right? So those are examples of that. And then you can also set up policies for software engineering, which is things like making sure that Kafka is in place because that is your standard for streaming, right? So those are the kinds of things you can actually author. And as you was mentioning, the key point of this blog, if I go to the conclusion here is, right? The point is all of these policies can be put in place without programming. And I wanted to really highlight that because our built-in config policy controller, as I mentioned earlier, can distribute any CR. So as long as you are able to represent a capability, say for example, as an operator, an operator can be deployed using a CR, right? And then you can configure the operator as long as it takes configuration, as given it is a resource, you can configure it. And if it returns the results back as CRs, we can process those as well. That's really like you were showing in this demo. We were able to integrate with Gatekeeper because it met all those characteristics, right? So we didn't have to really write code. We just had to author policies. So I think that's the beauty of this approach is it's very easy to put these best practices in place for your data operations without writing a lot of code. In fact, without writing any code. Yep, Jaya, are there out-of-the-box policies that are available that in the Gatekeeper community, I know you showed us the community for RACOM, the community branch. What does Gatekeeper provide out of the box? I think many of the policies that we have put here in our community were contributed by our community of practitioners. So they have their own community where based on customer requirements, they're building out policies. And then once they feel that those policies are stable enough, they then contribute into this community. And then the next progression is if we find that there are enough customers asking us for a fully supported version of that policy, then we promote that policy to stable and it becomes part of our RACOM product. So that's kind of the three-step progression of how we are building our policies and moving them into fully supported versions. Great, that sounds good. Let's see, so you answered those example and another thing you mentioned early on in the conversation, you kind of mentioned, well, you used three different words and I just wanted to see if there was clarity. You said that there are, of course, admission controllers, runtime controllers, and then later you talked about admission and audit. So I wondered, I think the admission controllers were fairly clear. Could you give us an idea of what some of the runtime controllers are? Yeah, let's see. Or is that the audit? Yeah. Yeah, let me go back to my, to sharing my deck. Jaya, we lost your voice again. Can you hear me now? Yep, perfect. It's just going and getting my deck. Okay, you can see my deck. So I think if you look here, let me go into present mode. Okay, so the policy enforcement points, right? These are the entities that consume the policy and return violations. So this is where you have the admission webhook. So anything that is plugged in into the admission webhook. Now Gatekeeper is one example of that, right? That is plugged into that. Now somebody could write another webhook that is processing policies, for example, right? As long as that entity that is configured as a webhook is able to accept its configuration or policy as a Kubernetes CR, then you can use our built-in config policy controller to distribute that to that, right? So that is one example, right? And then there are, Kubernetes obviously has its own runtime controller. So for example, when we propagate a policy for its CD encryption, that is actually being enforced by Kubernetes itself, right? We don't have to do an external controller to enforce that, right? But then we have certain other controllers, like the certificate management controller is something that we provide. And that allows you to detect whether certificates are expiring, whether certificates have wildcard, certificates are being used, et cetera, right? Those are policies that you can define and that can be detected using that specific controller. And compliance operate is another example, right? So... Okay, I had thought of things like Falco. So it helps me to understand that you mean it more broadly. So... Right, yeah, Falco is here as well. So that's another example of a runtime controller, right? Thank you. Also just really quickly, because I know you and I responded to Carolyn in chat, but maybe we'll just verbalize for everybody else as well. Carolyn had asked whether OpenShift is required on all clusters in order to use policy-based governance. And no, as Jya said in chat, ACM itself runs on an OpenShift cluster, but ACM can manage other Kubernetes distributions besides OpenShift. Today, the compliance operator is only running on OpenShift. It is designed to the content that's available, which is written in SCAP, Secure Content Automation Protocol. This is a standard that's required by a number of our customers, which is why the compliance operator is written in SCAP. It today, we only have content for OpenShift and the operator mostly works on OpenShift. We want to extend it to other CUBE clusters in the future, likely or at least share it upstream to make it easy for others to extend it. Although, of course, the project is open-source, so you can do that today. But again, ACM itself can manage both OpenShift and other Kubernetes clusters with other Kubernetes distros. Okay, just two compliments. So the policy framework, the governance policy framework, so the hub piece does require OCP cluster, but the piece on the managed cluster, we do support other Kubernetes flavor, but also, so, but the OuterBox controllers, for example, the configuration policy controller, it also support other Kubernetes flavors. So that means, if you want to integrate something that it's not running on Kubernetes cluster, but it can be integrated using configuration policy, it is, you can still do that. And also, to add the gatekeeper operator also works on non-Cubernetes environment, a non-OCP Kubernetes environment. So of course, if you want to use OLM way to install it, you need to install OIM, but you can also install it without OIM. So the upstream version actually supports multiple way to install gatekeeper. Yeah, those are all excellent points, you. I think, yeah, I wanted to add here, like if you go to this open cluster management policy collection report at the very bottom, that's where we have listed all our blogs. So you can take a look at it. Also, this is the open cluster management community. So if you're interested in trying out this capability, that's a good place to start. And we have community meetings, so you can definitely get engaged there. And like you said, you know, for example, if you want to try this out on a non-open shift cluster, at least on the managed cluster side, definitely you're welcome to do that. I have one question. This is Shana. I have a customer who is running currently right now, 311. I noticed ACM Rackham supports 3.11.200 and above. And some of the policies when I install it, it actually require like let's say image vulnerabilities and it will require container security operator on the managed cluster. And I was just wondering like what all the policies will install operator for the managed cluster if there isn't or it is kind of a pre-rex depends on what policies that you're applying to the cluster you want. That makes sense? Like, because there are times that I would not know what my managed cluster has. As an admin, I will want policy, A, B, and C. And then when I create those policy and I figure out, oh, those clusters doesn't have it would like for a gatekeeper you will deploy the gatekeeper for the cluster, but gatekeeper is actually only support 1.14 and above. And so there isn't, it's that mean that I cannot have gatekeeper policies on the 3.11 cluster. So yeah, I can take that. So yeah, so as I mentioned previously, there's two pieces, the framework itself and also the policy consumer. So the framework does work on OCP 3.11, but the policy controller or consumer on managed cluster it might not support OCP 3.11. So it's really case by case. So if you try to create a gatekeeper on 3.11, then since it's using configuration policy, it will try to apply those CRs, but since those CRs don't even exist on 3.11, it will return non-compliant. Okay, so I have to figure out which one is useful and which one is not. And I think this is where I think the placement rule applies, right? So when you are applying a policy to a managed cluster, you do that by using this concept called placement. And one of the things that you can use is you can assign labels to your clusters. And you can say that apply this policy to a cluster that matches this label, right? So what you could do is you could assign labels to your clusters depending upon what version they are, et cetera, right? And that will kind of determine, you know, which policies get applied where. Okay, that's a good idea. Thank you. Just thinking aloud is there's real customer questions. They are on 3.11. I just want to kind of pick your brain taking the three last three minutes opportunities. And so they want to follow the needs standard, right? And so they are moving to four, but they're not yet, they're still on 3.11. What are the policies that you would recommend them to start on doing with ACM? If there is any documentation, I can just tick the link and read about it. Yeah, I think the blog that I was sharing could be a good place to start. I'll put that link in the chat. So nice. I really want to go read. I read them over the weekend. They are super, yes. So Jay, we know the compliance operator is not supported on OpenShift 3.11. There is a hardening guide for OpenShift 3.11, but there's not automation that I'm aware of. Does ACM have checks for OpenShift 3.11 like that mapped to NIST 853 or some other NIST framework? I think the encryption policy at CD encryption should work on 3.11, right? Did you support OpenShift 4 support? Sorry. Yeah, both OpenShift 3.11. And you can encrypt at CD in both OpenShift 3.11 and OpenShift 4. How you do it is slightly different, however. There are differences in implementation. I just didn't know whether any of your other checks. Yeah, I mean, the other check is the certificate expiration. That definitely should work, I think. That's another area that you could look at. Yeah. So, Shauna, if it's for 3.11, this is Kirsten Newcomer. Feel free to shoot me a note. KNewcomer at redhat.com. I'll see what I can do to help you out. Thank you so much. Appreciate it. Rachel, thank you. And there's one question from Tobias in the chat right now, a question regarding the roadmap item in terms of audit, et cetera. Does this include having a result that could state deny but not denying the actual resource creation and rather just firing a violation alert to SIEM? Meaning, yeah. Okay. You read that. Yeah. I think the gatekeeper audit scenario, obviously we support, right? Meaning, when I say support, that should work. The roadmap item related to audit was more on the hub being able to generate audit logs for policy lifecycle events and have them routed to SIEMS. So that is something we'll work on in the future. But if you're talking specifically about the gatekeeper audit scenario, that'll be fine. You should be able to use that. This was really, really good. And we definitely sounds like we're gonna have to have you back as the OCM community grows and more of these policies are out there. This is just a deep dive here and very good. You, thanks very much for the demo. It was quite, quite good. So thanks again. And thank you everybody for taking the time and asking great questions so that I didn't have to. This was good. And thanks, Kirsten, for jumping in there. Hey, Carol. Thank you, everyone. Bye-bye.