 are talking. Hello everybody and welcome to yet another OpenShift Commons briefing today as we like to do on Mondays. We like to have AMA ask me anything, questions about different aspects, technology initiative, different upstream projects. And today we have Jaya Ramatham and Yu Cao who work on our governance and security work at Red Hat. And they're going to talk a little bit about open policy agent, how and gatekeeper and how all that works within the context of some of our advanced cluster management product offerings. But we're going to have live Q&A at the end too. So wherever you are, please ask questions in the chat. It'll get relayed back to the speakers and we'll have some live Q&A at the end. So with that, Jaya, could you introduce yourself and you and take it away. You are on mute. Jaya, there you go. Try that again. Still on mute you, Jaya. Hi everyone. Thank you, Diane. Hi everyone. Thank you for this opportunity. I am Jaya Ramatham. I am the Chief Security and Governance Architect for our Advanced Cluster Management Offering. And I have with me Yu Cao. 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. And we also have an upstream community called Open Cluster Management. So we are here to talk about just some underlying principles and overall architecture of our security and governance capability. And then we will delve deep into OPA and gatekeeper and how that integrates with ACM. Okay. 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. And 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. So really what they're looking for is the ability to maintain security and audit readiness on a continuous basis. And they want to do this recording has started for open hybrid cloud. Should I start over or should I continue? You can continue. I can grab that last the first bit from from the live stream. Okay, awesome. 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, you 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 homegrown 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, etc. 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, right? 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 your 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, etc. And then the policy gets distributed to the managed cluster on the managed cluster, you have policy enforcement points. And these 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 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 OPI integration is one such example and Kubernetes 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 Git, 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 I talked about. And then the these results are then collated back. And and so you have everything available in a central manner. There are a few roadmap items that we highlighted here, where we want the policy framework to associate ansible playbooks to trigger automated 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 or things that are roadmap items. So now I want to drill down into details of how we have integrated with Gatekeeper and OPA. So let me start with a quick overview of Gatekeeper and OPA. So Gatekeeper allows you to evaluate compliance of Kubernetes resources to specify policies. And what it leverages under the covers is OPA. And OPA is the policy engine that it uses. Now OPA itself accepts policies in a language called Regal. So think of Gatekeeper as providing the bridge from OPA to Kubernetes to the Kubernetes world. So it allows you to specify the policies as Kubernetes constraints, which can which can in turn contain the Regal constructs. And Gatekeeper can then consume those and because it registers itself as a policy enforcement point through the webhook. And so it's now able to pass on those Regal constructs to OPA and use OPA 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 updated. 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 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 OPA into ACM. First of all, we are delivering going to deliver operator that can deploy Gatekeeper and OPA. 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 OPA 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 ACM 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 have a ACM 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 ACM 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 OPA 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 U 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 detects 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 open cluster management community. And you can connect with us there and ask any questions, etc. Before I turn it over to you, I also want to give you a quick demo of our open cluster 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 so you can see here we also have third party contributing policies here. So you will see here a policy from SISTIC. 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. Jay, 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 as a community meeting that happens weekly. And definitely, you know, 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 there's one quick question here before we go to the demo Tobias is asking if if the Gatekeeper community would announce mutating admission controller, will you integrate such an option into RACM? 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 RACM to adopt those. Yes, that's our goal. I'm so grateful that you finally said that acronym out loud and it's RACM. Because I have that's that's a wonderful way to pronounce it. So I'm going to use that going for it. So thank you. That's a good point. Let me clarify RACM and ACM stand for the same thing. ACM is Advanced Cluster Management and RACM 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. So 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. Right. So hi everybody. My name is Yu Tao. So I'm the dev lead for RACM security and compliance team. So today I'm going to do a quick demo for how you can use RACM 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 RACM products. So if you go to our product documentation, there's an overall architecture diagram here. So if you click on it, you'll 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 responsible for propagating the policy from hub to manage cluster. So how it 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 embed your 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 create also create a placement rule. So since Reckham is managing the is a control plane that 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 you can select a subset of cluster of a divine. For example, in this case is all your deaf clusters and then create a placement binding that find the policy and placement together basically tell our policy propagator to this policy needs to be applied to these clusters. So this is how we propagate policy to manage cluster. So the reason I explained this is so this is the framework that to distribute policies and the actual the actual policy that is being executed or evaluated on the managed cluster is we call it policy controllers or policy consumers on the manage cluster. So the framework propagates the policy to manage cluster, distribute them to manage cluster and then hand it over to the actual policy consumer installed on your manage cluster. For example, the gatekeeper policy consumer or compliance operator or the auto box policy controller that we ship, recommend ship, for example, the configuration policy controller. So once it is it reached the manage cluster, the actual policy consumer on the manage cluster will will apply evaluates the policy past past in and then return and then generate results. And the policy framework will retrieve those results and return it to hub so that you can you can view the results through single control plane using Recon console. So that's the governance framework policy framework and we put in place for Recon. So in terms of gatekeeper policy, so from this big picture, so gatekeeper controller is one of one of the policy consumer from Recon policy policy framework perspective. Now so now let's take a look at the actual gatekeeper policy. So we've talked about that we can use a Recon policy to install gatekeeper and we can also use a Recon policy to apply gatekeeper constraints and then which collect the results back to hub. So this is done through defining Recon policy. So as Jay mentioned in this policy collection report, you can find you can find the gatekeeper operator policy and also some a few other gatekeeper policy that actually apply certain constraints on your clusters. So let me take a sample. Let me go through in details. For example, the first the gatekeeper operator gatekeeper operator is is an F is an effort that we will be actually involved in the upstream community. So the gatekeeper what gatekeeper operator does is it packs if the gatekeeper is an open shift operator. The operator responsible for the lifecycle of gatekeeper so it can install gatekeeper it can delete gatekeeper. And of course we are we will we are also working on upgrading those kind 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 Recon policy to to to to install gatekeeper across all your managed cluster. So what you need to do here is you define a policy CR, policy CR here and then includes multiple templates. So just very similar to how 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 cat 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 the catalog to pull down the gatekeeper images. And so and then 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 is and then we enable the admission events flag so that we can we can so that when there's a violation generally for for for any new when there's a violation generally for any new is a new resource created on my cluster that being that was that is blocked by this gatekeeper. It will generate a kubernetes events. So this is for the purpose. This is for the purpose for Reckham to be able to collect the result for admission admission scenario. So then so once this this this policy is created, you were and by created then it will based on the cluster selected here, right? So it will install the the gatekeeper operator on managed clusters. So for this is the Reckham console. So I have a gatekeeper policy operator policy installed here. So as you can see, this policy currently is being applied to this this managed cluster. So if you go to this managed cluster here, it was so this is currently being this policy is being forced and is compliant. So this means the operator has been installed on your managed cluster. So if you go to the ocp console here on this managed cluster, this is not managed cluster. Let me open. This is the managed cluster. And then if you go to operator here, go to install operator, you will see gatekeeper operator here. So it is so very simple. So the 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 report violation back. So installing gatekeeper is just the first step, right? What what's really 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 I create a gatekeeper sample policy here. So I think it's easier to look at in here in this code. So gatekeeper. So this is from the gatekeeper. This is from the policy collection repo. You can find it. You can find it in policy collection repo. So in here, we are using the same policy CR to distribute the gatekeeper constraint constraint template. As you can see, we have three templates here. If you look at the details, right, this, 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 on the cluster based on the template object definition you provide. So if you look at the the CR CR fields here, so you create a configuration policy, it has object templates inside the spec. So in this object templates, anything defined in this object templates template field is the actual CR you want to create in this example. So currently, we are we are using compliance type must have, which means you must have an object with this CR. So look at this. So this is the gatekeeper constraint template, right? So basically how we integrate is you are if you have good constraint template and constraint CR already, so you can use configuration policy to create an 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 distributed across all the managed cluster. So that's how how the constraint template is delivered to manage cluster. So you don't you don't have to write any code, you just need to create this policy and embed your constraint template thing for the constraint here. Then the Reckham policy framework will create these two CRs on the cluster on the cluster and then and then gatekeeper gatekeeper instance, the controllers were taken over and evaluate these these two CR. So if you look at details of this CR, this is a sample namespace constraint template constraint I took from from gatekeeper gatekeeper website. So what it does is it requires any any names and a this regular basic defines any input resource resource needs to have a field called label and inside that label field, you need to have a you need to have a have a have a label with name with name with certain name. So the name is being exposed as a configurable parameter called labels. And in the inside constraint, so you're basically basically applying this constraint template. I'm here I'm applying on any namespace. And also I restrict the namespace to be these two these these two namespace because I didn't want to apply all want to apply to ordinary space. But if you remove these it will it will be all namespace. And that and then I want the actual labels to be gatekeeper. So so for so for example, if if if so if we want to test this this policy that 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 do that. Here I believe I've already logged on the log in on to the gate the the manage cluster. So let me double check. So here on my manage cluster, for this 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 that we are applied that we are applied using Recom policy is actually in place and and 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 centrally through Recom control plane. Then it's the violation part. We want to be able to collect violations. So if you look at look at the the other two templates that we are embedding in this policy CR. So 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 it is looking for any CR on the managed cluster called KS required label. 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 want we want it is we are using must have compliance type here. So what it does is we require we require on your cluster you need to have a CR called NS must have gatekeeper with this kind in 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 is this constraint is being created on the managed cluster. So gatekeeper audit controller will start to scan your entire cluster and then try to figure out if you have every any pre existing by a non compliance exist. So if there is any, it will actually update the status field to tell you, oh, there's some 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 this policy will return non compliant. That's how we collect the results. So if for for that's how we collect results for audit. And then let's look at the dimension scenario for the mission scenario saying we are creating another configuration policy and we are looking for events events for this constraint template for this constraint case required labels and then with name and as must have go gatekeeper. So basically so as you can see here we are using compliance type must not have. So we expect there shouldn't be any events with these annotation on the managed cluster exist on the managed cluster. If it exists that means there's violations. There's there's something wrong. So this policy will return non compliant. So now let's come back to the console here. So as I did as previously I did this, I try to create a namespace without label. So now as you can see here it is for this this admission template is report reporting non compliant 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 what exactly it is. So oh there's a this is this is what is violating this part of this policy. So this event exists but it should it should and if you click on your YAML it is going to pull the details of this event. So as you can see it tells you admission webhook that 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 Recon. So we implement we integrate gatekeeper not only just installing the gatekeeper and then creating the gatekeeper constraint constraint template but we also collect the result for both an audit and an 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 Recon. 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 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 you can trigger a scan. So from using certain profiles. So here if you look at the the EA scan policy here basically this policy triggers trigger this policy triggers an essential a security profile scan on your managed cluster. And we are also using configuration policy to achieve that. So by just create using configuration policy to create scan-stated 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 from me. That's great thanks you 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 client compliance operator. There was in chat a conversation about the difference between the compliance operator and gatekeeper. And I think both Jaya and I weighed in and you did a nice job also summarizing that here. So the compliance operator is specifically focused on on regulatory controls technical controls that map to regulatory frameworks. I just want to share just because we're really excited. In addition to the E8 profile which is an essential 8 profile from Australia. There are some the the compliance profiles available with the OpenShift compliance operator includes some controls that meet NIST 800 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. Jaya 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. Yeah does that make sense? Yeah can I can I share grab the share again? Please do. I think you should be able to see my screen right? 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 Christian 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 security regulatory compliance of 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 and also you can remove the cube admin 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 constraints etc 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 etc 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 you know these kinds of policies readiness probe is in place these are all resiliency related policies right? So so those are examples of that and then and then you can also set up policies for software engineering which is things like you know making sure that Kafka is in place because that is your standard for streaming right? So so those are the kinds of things you can actually author and as you was mentioning and 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 CRs 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 the 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 are 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 day-to-day operations without writing a lot of 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 Wreckham 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 great right so they have their own community where they based on customer requirements they're building out policies right and then once they feel that the those policies are stable enough they then contribute into this community right okay and 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 right and it becomes part of our Wreckham 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 but 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 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 just going and getting my deck okay you can see my deck so I think if you look here let me go into that okay so the policy enforcement points right these are the these are the entities that consume the policy and return violations so this is where you know 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 those that entity that is configured as a webhook is able to accept its configuration or policy as a community cr then you can use our built-in power config policy controller to distribute that to that right so that is one example right and then there are communities obviously is has its own runtime controller so for example when we propagate a policy for it cd encryption that is actually being enforced by communities 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 etc 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 so it helps me to understand that you mean it more broadly so right the afalco 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 and chat but but maybe we'll just verbalize for for everybody else as well Carolyn had asked whether open shift is required on all clusters in order to use policy-based governance and no as as Jay said in chat ACM itself runs on an open shift cluster but ACM can manage other kubernetes distributions besides open shift today the compliance operator is only running on open shift it is designed to the content that's available which is written in scaps secure content automate security 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 open shift and the operator mostly works on on open shift we want to extend it to other coop 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 is open source so you can do that today but again ACM itself can can manage both open shift and other kubernetes clusters with other kubernetes distros just to complement so the the policy framework the governance policy framework so the hub piece does require OCCP cluster but the the piece on the managed cluster we do support other kubernetes kubernetes flavor but also so but the outer box 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 on kubernetes cluster but it can be integrated using configuration policy it is you can still do that and and also to add the gatekeeper operator also works on non-kubernetes environment 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 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 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 ship 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 would 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 apply to the cluster you want that makes sense like because there 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 policies 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 is 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 on OCP 311 but the policy controller or consumer on managed cluster it might not support OCP 311 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 the those CRs but since those CRs don't even exist on 3.11 it will return non-compliant okay so we'll have to all right so I'll have to figure out which one is useful and which one is not yeah and I think this is where I think the placement rule applies right so when you 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 these this policy to a cluster that matches this label right so so what you could do is you could assign labels to your clusters depending upon what version they are etc 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 they are on 3.11 I just want to kind of pick your brain ticking the three last three minutes opportunities and so they they want to follow the needs standard right and so they're running they are moving to four but they not yet they're still on 3.11 what what are the policies that you would recommend them to start on doing with ACM if there is any documentation I can just take the link and read about it yeah I think the the the blog that I was sharing could be a good place to start let me I'll put that link in the chat so nice I want to go read I read them over the weekend they are super okay yes yeah so yeah we know the 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 city at city encryption should work on 3.11 right did you support did 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 to help you out okay thank you so much appreciate it great tool thank you and there's one question from Tobias in in the chat right now a question regarding the roadmap item in terms of audit etc 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 I think the gatekeeper audit scenario obviously we support right meaning when I say support that should work the roadmap item related audit was more on the hub being able to generate audit logs for policy lifecycle events and have them routed to Sims so that is something we are we'll work on in the future but the if you're talking specifically about the gatekeeper audit scenario that'll be fine you should be able to use that with that help now at the top of the hour and I'm sure both Paul and I who are trying to follow all of these projects in the CNCF and the new ones are incredibly grateful for you guys taking the time to explain all of this and it's really been helpful I will upload this video and get the slides from Jaya and put them together and tweet them out shortly and put them on somewhere we maybe we'll put them in a blog post as well somewhere so you can get them this was really really good and we definitely sounds like we're going to 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 thanks again and thank you everybody for taking the time and asking great questions so that I didn't have to this was this was good and thanks Kirsten for for jumping in there take care thank you everyone bye-bye see you