 and welcome to the Cloud Multiplier. Today is episode two, so if you caught us last week, we talked about HyperShift. Today, myself, Gernie Buchanan, and my co-host, Joy Deep, have the honor of welcoming two new guests, Gus Parvin and Jaya Ramathan. I hope I pronounced your last name, Jaya. I didn't ask before we got in the stream. I really need to work on that. And they are from the PolicyGRC and many other things team here at Red Hat. They're joining us today to talk about a very interesting topic about fleet-wide policy, governance, compliance, and even more of these fun distributed cloud problems. But as always, we're not directly into the meat of things. So first, we need to talk a little bit about what has been going on for the past couple of weeks with top of mind topics. I now get to put my favorite thing for the week is to put Joy Deep on the spot and see if he has brought anything this week. See what's top on his mind this week. Hey, thanks. Hi, everybody. So a couple of fun open source projects that I'm looking at. So I'm looking at Facebook's Profit. It's a time series forecasting. Gernie, it sounds like you've never heard about it. No, I haven't. So we are collecting all of this data, right? And everybody is collecting. So you want to make sense out of that data. And most of the data that we collect is time series. You have a timestamp and then you have some metrics. And Facebook actually has a robust library which is to forecast and do a bunch of other things. And while there are many forecasting libraries available, this one has caught attention because of a few things. So I'm checking that out and can't help. The other interesting thing that's on top of my mind, Gernie, is the release of Red Hat Advanced Customer Management 2.5. It has many, many, many exciting features. Yeah, that was going to be mine, Joy Deep. That was going to be yours, I guess. It's obvious that I have to mention it because, admittedly, I was on vacation during the week. But I am on the productization team for Red Hat Advanced Customer Management. So my team did a wonderful job of shipping the thing on time while I was out hiking at Yellowstone. So it was the easiest release I've been through personally. But that one was a long time coming. And all of the things we talked about last week in Hypershift, some of the stuff from Today for Policy and a bunch more from future shows and other things, is now live. My favorite part is definitely they consolidated the UI. So now you just get a cluster switcher in the UI, which is just wonderful. I have like 100 clusters that I have to worry about on a daily basis. So that makes my life a lot easier. And Joy Deep, I have to ask, so how is Profit spelled? Gernie, I have to ask, how do I answer this chat? Flash drive, so I don't have to answer the question. Oh, Profit, first one, Anna, Profit. Let me leave it to you in private chat, OK? Got it. Yeah, that's right, we do have a chat in here. Let me go ahead and I'll share that out to everyone. So there's that. I hadn't seen this at all, Joy Deep. That's a really interesting project. So is this just projection in general? So you can just pile some time series into it and get projections out? Well, there are some. I'm talking to one of our customers who wants to project. But usually it's just more than projection. There are many problems that you want to know, for example, without having to stare at the data. You want to know if something changed under the covers. Maybe your sales was like this. It was at 100. Then it hopefully at 150. And you do not want to be staring at the numbers, but you want to know if there's a change in trajectory, if a certain pattern is being repeated. So there are many different kinds of things that you need to do. Profit does some of them. Anything coming from Facebook is pretty robust, actually. You'll have to see if it fits. Always some caveats. You can use as long as your data behaves this way. Yeah, there's always an expectation. Yeah, interesting. OK, other one, I get to put Gus and Jaya on the spot. So anything on the top of your mind today for either of you, any fun open source projects, and I think you've been working on? Yeah, I can always do a plug for my favorite political group, Oxford Community, that we have been working for the last couple of years on advancing policy management, best practices, et cetera. One of the things you're focusing on recently is the compliance angle. So if you're interested in policy, in security, policy, governance, and all the good stuff, welcome to participate in that one. So I want to make sure that I keep that open. And I wanted to add that since you talked about ACM 2.5, I do want to say what my favorite feature in that release is, is the introduction of policy set to group policies for deployment. And Gus will of course talk a lot about that in today's talk. Awesome. Gus, anything cool for you? The cool thing I played with last week was the new release of the Caverno policy enforcement point. So they had a 1.7.0 release, which was long anticipated by me. It has some cool new features that let you apply configuration. It has some similarities to our governance risk and compliance. But some of these features are really neat because it hooks into the API server, so it does some validation. Plus it can do some resource creation. So it was a very interesting new release. That's very interesting. OK, so I'm getting ready to see a lot of this appear in our development workspace is what you're saying. Couple new versions of it. OK, that will be interesting. Yeah, this is really the edge. It's brand new, so not a lot to demo on that new release. But we'll certainly show some different things that show the GRC framework often in a lot of different ways, and including using Caverno and Gatekeeper. Awesome. So that means that we are slowly expanding and the policy world is not only related to security, but it's spreading in other domains as well. Configuration and things like that. Is that what's happening as well? That has always been the case, right? So whenever we pitch policy, we always say that you can apply policy management for security, resiliency, software engineering, best practices, as well as configuration management. And one of the strengths of ACM is its ability to integrate with multiple policy engines, including Caverno that Gus mentioned. Fantastic. OK, I think I'm feeling the thunder from Gus. We should. Yeah, I was about to say it's feeling about time for us to get. We're slowly transitioning into the meat of it. So Gus, I think the intro question is give us the elevator pitch on policy, because I don't know much other than every problem that requires a configuration change. The solution is usually a policy engine of some sort to make that true. So I'll let you give us the pitch, and then I'm sure we'll have plenty of questions. Yeah, and maybe the best way to get the pitch started will be to show a slide, to help dictate kind of where the problems lie. So I'm going to share my screen really quickly here. Awesome. All right. There we go. If I go into slideshow mode, hopefully that will. Maybe I need to hit it again. There we go. There you are. Oh, there we go. OK, so governance, risk, and compliance. We are one of the pieces of advanced cluster management. We do have a security focus. So whenever you're thinking about compliance or governance and managing risk, you're concerned about the security of your cloud multiplier. And we're advanced cluster management. So we're concerned with clusters and lots of them. When Red Hat has another product called Advanced Cluster Security, and its focus is the container security. Now, when you think about security in that product and security in advanced cluster management, what do they have in common, and where are they different? So for advanced cluster management, on the screen here, we have a few of the different key points for ACM. And one of them certainly is these cloud environments can be dynamic, because this is the cloud multiplier show. These cloud environments can come from different places. It can come from public cloud. It can come from on-premises. They can be hosted from VMware or bare metal. So there's lots of different ways these clouds can be stood up. So our ability to understand the risks and manage compliance across all of these clusters can be quite of a challenge. And that's what we're here to try to help with. I mentioned Caverno. I mentioned Advanced Cluster Security. I mentioned Gatekeeper, plus our own policy framework that comes within GRC. They're all tools that help you manage this multiplying set of clouds. Now, what is it really all about, and how do we differentiate some of these things? Caverno, Gatekeeper, the OpenShift Compliance Operator, these things run on a single cloud. So they're not really multi-cloud on their own. With GRC and the benefits of using GRC with these solutions, you can easily make them multi-cloud by using our policies to deploy them out, to deploy their concept of policies. We'll be using the word policy a lot. So it stopped me, certainly, when you get confused, because I'm talking about Gatekeeper policies versus GRC policies. It can be a little bit of an overused term. But what we're all about here is trust. So how do I trust my cloud? Advanced Cluster Security, you think about that product separate from Advanced Cluster Management? It's about trust. Trusting the containers, though. It's a deep dive of trust for the different containers running in your cloud environments. Advanced Cluster Management, we're about trusting all of these clouds that you're building, which, of course, include containers, too. So the product's work will hand in hand. Advanced Cluster Security is part of the OpenShift platform. Plus, we'll probably talk more about that later. Actually, I think we'll definitely talk about that more later. But for now, just know that we're really trying to build an environment that has clouds that are being deployed. They're coming up. They're being torn down. And we want to know that they're being installed and configured with the right set of tools, the right configuration. We want to have that understanding that compliance is being applied properly. So these bullets that you see on the screen, we want an open solution to being able to make sure that we can trust these clouds. And whether you're the compliance, like a SecOps or a compliance engineer that's trying to make sure that we're checking off all the boxes on the different compliance regulations you need to meet, or whether you're an SRE that needs to make sure the application teams have the tooling and the different prerequisites for the applications that are running available. GRC, our Governance Risk and Compliance policies, can be a key part of making this kind of automatic. We get into taking a look at our policies. They all have placement information that allows you to apply configuration to the right set of clusters. So that's kind of what our policies do. Our policies define a set of Kubernetes configuration, and it lets you apply them to a set of clusters that have something in common. Maybe they have a compliance requirement in common, a cloud, a provider that's in common, or maybe it's an open shift version that's in common. So the placement concept, of course, is part of advanced cluster management. And that's something that's key also for providing that benefit of governance risk and compliance across the clouds. OK, I feel like I've talked for a while. Yeah, so I have plenty of questions now. So if I'm getting it correctly, policies are kind of our smallest unit of definition for configuration. So ACS, Stack Rocks folks, they very much care about the security of a container running. Is this a secure base image? Is it behaving and configured in a secure way? The policies we're going to talk about, or you're going to talk about mostly, and I think you have a bunch of demo stuff as well, mostly focuses around configuration, making sure that you have resources in a cloud platform configured in a secure way. And correct me if I. So base definition of a policy is kind of a statement of you want something to look like this. You define what you want a resource or what you want a configuration to look like. And it'll tell you if it isn't in that state and potentially make it true. Is that what we're talking about? That is one of the primary use cases, absolutely. We have what we call a configuration policy controller and its job in life is to compare configuration on Kubernetes resources on a cluster to what's in the policy. And it has two modes in form or in force. Okay. So once you know if there's a difference or if it's in enforce mode, it can try to enforce and make sure that it's configured the way you intend the cloud to be configured. Okay, so we do, yep, go ahead, Jaya. Yeah, I wanted to just chime in a little bit on Gurney's question, right? So I think the way to think about advanced cluster security and advanced cluster management is I always use a team, right? So if you take a team, advanced cluster security is basically going deep into security aspects and making sure those are configured properly, right? Whereas advanced cluster management is the top line, right? And it is more broad, it focuses on security but also other aspects like resiliency, software engineering, et cetera, right? And also think of advanced cluster security as one policy enforcement point that can enforce policies for certain aspects. A customer could have multiple policy enforcement points on their managed clusters like Kubernetes gatekeeper, et cetera as well. And ACM itself also has policy controllers that could run on the managed clusters as well, right? So you want to be able to deploy policies that are honored by many of those PEPs, policy enforcement points, which support various technical controls or not more technical controls. So I think the way I would phrase this whole thing is you're right, configuration management is kind of the underlying theme here because if you think about it, the customer when they operate a particular cloud, they're trying to enable all these various controls. And if a control is not configured properly for best practices, it's as good as this control is not in place, right? So this is where I think ACM's policy-based governance is ensuring, like Gus said, that the controls are deployed properly, configured properly, and it can report violations, right? So, and that's why we are trying to make the life of the SRE who has to manage these clouds easy because we are getting these policies authored in Git and deploy them using GitOps. So by getting them authored in Git and using that as a repository and managing policy as code, you can now have the right SME subject matter experts and personas involved in authoring those policies to ensure and reviewing, to ensure that it meets best practices. So that's kind of the overall approach. Okay. And this lets you build, I guess once things get incredibly complex, it lets you build kind of a structure or a framework of trust that is traceable and verifiable and visible. And I guess the good thing you mentioned that a lot of this is in Git and spoilers, I do know actually let me drop, there is a big repo for anyone watching. Feel free to ask questions in chat and take a look at the policy collections repo. It's really good framing for what we're talking about, but as we have, you have a lot of policies defined here that are already defined in Git that someone else could inherit for that task as well. So that makes them very transferable and very consistent, gives you a consistent environment. Okay. And I guess what we can define is a Kubernetes resource at any one of the clusters or any 10 of the clusters or any hundreds of the clusters, right? It must be a Kube resource, it can be anything. It can be a secret, it can be a config map, it can be an operator, it can be a namespace, right? Yeah, exactly. That is what the configuration policy controller that Gus talked about is one of the key pieces of the puzzle, right? Because it can basically distribute any Kubernetes configuration. And you can distribute it to a set of clusters. So that is very powerful. And Jaya, I mean, clusters out of curiosity, since we are talking about cloud multiplier and we talk about multi-cloud and edge, has these been tested with thousands of clusters? Can we manage that? Yes, so Gus, you wanna talk about the templatized policy feature that we have that helps with that. And you can come to that, but I don't want to deal with it. Yeah, yeah, yeah. Okay, but we have a way to, yeah, go ahead. Right, yeah, I mean, I will mention, you know, I've seen an environment where thousands of clusters were being managed. I don't remember the exact number, but it was over 2,000. So those environments are possible. So cloud multiplier is a great name for how GRC can be used. We talked about the configuration policy controller. It's not the only one. So we do have other controllers that are security related. It's commonly thought of as certificate expiration, which is generally how people use it. It can actually do a few things other than certificate expiration. It can enforce your organization's requirements maybe as far as how long a certificate lifespan can be. So, and it can also look at the DNS names to see if maybe you're using wildcards in your certificates and maybe that's something your organization doesn't approve of. So we can flag things like that. So the certificate policy controller is one of the other ones. There's also a IEM policy controller which simply checks cluster admin usage within a cluster to make sure that you don't have an unusually hard number of cluster admin users, which would probably be a bad sign. And a teaser maybe for an upcoming episode was what if you have a need that doesn't match one of those three very well and won't really answer that question now, let that happen maybe in a future episode. Okay, I feel like you've teased a future for us. So this is starting to sound very much like a very good generic toolbox for controlling, ensuring, unifying this experience. So I have to, the next thought is do you have any good exit? Give me an intro with an example. Do you have any good live examples that don't involve checking any of my infrastructure for cluster admins? As long as we don't do that today, I think everything's fine and we won't have any issues. Let's just not do that one. Yeah, so. Yeah, no, I was just saying whether you wanted to kind of one of the things when you were trying to explain the capabilities of a product, right? Someone told me that try to net it down to three things that people need to remember. So I wonder whether you wanna just summarize ACMs, policy-based governance capabilities in terms of if somebody has to walk away with three things, what would those three things be? Okay, you have some. I think that matches well with these three things here. So, yeah, take a look at this slide. Three things we have, like we've been talking about, we have the multi-cluster policy. So our policies can be used, not just to handle applying configuration that works with our policy engine, it can also be used to work with the additional policy engines that you see. I guess that's more of the second point. The first point, we're really focused more on the ability to write our policies that can help you achieve the different compliance rules that your organization may have. We have annotations inside of the policy that helps you organize your different policies to make sure you are achieving, progressively making your clusters more secure and reducing the risks that clusters may be susceptible to. Then these all kind of tie together pretty tightly, because the last one is thinking about the link that was posted in the chat. We do have a policy collection community, and we have lots of different details there. The bullets go over a few of them, but we have blogs that are linked to from that community. We have a policy generator, which is the last link. So writing policies isn't always fun, but if we could make it a little more fun, that's where we bring in the policy generator. It makes it a lot simpler and a lot less burdensome to try to get formatting and everything just right. You can go through it and just turn on features and create the different resources that you're concerned with taking a look at in your cluster. The different contributions in this policy collection community come from lots of different places. We really have contributions from across Red Hat, across different teams, donated from other places in the community, and these contributions are fairly active. So we do have new contributions coming in, being reviewed even today. So we've talked about gatekeeper and caverno sum and the compliance operator. So I've mentioned some of those things. There are contributions out there that you can go and take a look at. Some of the organization of our community is a lot of these things are community created. So it's community support for some of these policies, but we do have stable ones that we will support and make sure are working and that we run in our automation pipelines to continuously validate that they are working as expected. Because, can I ask a couple of questions? Absolutely. So I know that, for example, the OpenShift platform has a wide variety of partners and integrations, et cetera. So if I think about those things, like whether it is partners that provide, for example, external secret management tools as an example, right? So there is a good ecosystem out there. So what are we doing to ensure that those partner capabilities can also be used with ACM from a policy management point of view? Can you highlight what we are doing there and? Absolutely. So you mentioned the Kubernetes policy work group earlier, which, when you dig into that work group a little bit, one of the cool things that they have done is create a custom resource that is being adopted across many different areas of the security. The cloud security industry. And that's a policy report CR. So we use it in ACM, the ACM observability or the ACM insights takes advantage of a policy report to help have a consistent way for reporting back policy passes, failures, mostly care about failures. So in the ACM case, it's populating it with the failures because with those 2,000 clusters we're talking about, if we put all the passes in there, it would be too big of a report to care about. Policy report is used in lots of other places. So that's how Kaverna reports back, it's auditing. So when you think of what I mentioned earlier with inform and enforce, gatekeeper, Kaverna, did they all kind of call it different things? So it might be dry run, it might be audit. Okay. Yeah. So the policy. I was about to ask, while you're at it, tell us a little bit more about Kaverna and gatekeeper because I have always wondered, are these all different communities that have sprung up out of the same policy, centric, governance, centric working group, that these same security areas? Because Kaverna is relatively new to me. I've heard of gatekeeper before, but Kaverna was a recent one for me. Right, so, oh, go ahead, Joydee. Sorry, guys, the other thing, if you get a chance, what Jaya's prod reminded me of, do we have any integration or are we planning any integration around vault? Has she got vault, for example, to manage secrets and stuff like that? So. So maybe let me make a couple of comments and then I'll let Gus talk about Kaverna and gatekeeper. One thing, as a follow up to what Gus talked about the policy report CR, right? In fact, recently in the KubeCon, European EU conference, there was a presentation of the policy work group that went through various technologies that have adopted the policy report CR, including Falco and Trivi and a bunch of other security technologies. So that's something that the presentation is out there on YouTube, so go and Google and listen to that one. That's pretty interesting. And then Gus actually authored a policy for ACM that can actually consume the policy reports CRs, right? So that is out there in the community folder as well in the policy collection report. So we'll be able to harvest some of the results from these other technologies. The other point I also wanted to add is, many of the partners, the partner ecosystem that Red Hat has, those partners are also contributing policies for ACM. So we have partners like SISDAG, ZetaSat, BlackTuck, you know, they've all contributed policies and you will actually see those in the policy collection reports as well. And to now answer Joy Deep's question before I give it to Gus, has she called Walt? That is one thing I'm really excited about which is the integration with external secret management tools. And one of the cool features in ACM 2.5 is Hubside Secrets Propagation to Manage Clusters. So what that means is you can actually, and there is an upstream community called External Secrets that allows you to integrate with external secret management tools like Hashtag or Walt, et cetera, right? As well as secret management tools provided by cloud providers. Now if you have that integration onto the ACM Hub, then ACM, and then now you're able to pull secrets from Walt and put it into the secrets of the ACM Hub, ACM can now distribute those secrets to your fleet, right? Now this makes it really easy because the customer will have to just do the integration at the Hub and then ACM handles the rest. Imagine if I have to do this integration at every managed cluster, that's a lot of work. So I'm really excited about that feature. And I'm already seeing several use cases for it and customers are already asking about that. So that's really cool. So now I'll yield to Gus, okay, go ahead. I'll yield to Gus now to talk about Qano and Gatekeeper. Yes, and I do wanna talk about Qano and Gatekeeper, but I also wanna go to the next slide, which is more of an architecture slide. Qano and Gatekeeper will show up on the next slide, so at least I think they do. They show up on the right-hand side. Yes, there's Qano under the third-party integrations and Gatekeeper just above it listed as one of the ACM integrations with, and you see our config IM and insert controllers there too. So these are all policy enforcement points that you can use with GRC. Also, you see the compliance operator like we mentioned before in advanced cluster security. But kind of the point of this slide is to show our overall architecture and what J.O. was talking about just a moment ago with the vault and external secrets and pushing secrets from the hub to the managed clusters. You think of our policy framework in the same way. You're altering and creating policies. They get placed on the hub and, well, you alter them and put them on the hub either through GitOps or directly creating resources there. And then through placement, they get pushed out throughout your enterprise of clusters that are being managed by ACM. Okay, so there's a lot of different details on the screen. It might be best for the sake of time just to gloss over them, but I will mention, I don't think we've mentioned integrity shields yet. So we're using policies to try to, eliminate risks and to try to guarantee our clusters are being created consistently. So what is integrity shield? How do we know the policies themselves can be trusted? So just like you can sign containers to make sure your containers have not been tampered with, you can actually use integrity shield to sign your policies to make sure policies haven't been tampered with. So that would catch. So I guess what I'm seeing on this chart is we take policies and anything, these other frameworks, Caverno, Gatekeep or all of these other things and you can put it on a hub and then selectively put it on your fleet of, I've made myself a problem when I have 3,000 clusters or 2,000 clusters and I need to see it there. But that step in between the hub and that managed cluster is one of those where something's in flight. Some data is in flight. So integrity shield is going to protect and make sure that that policy payload arrives in the expected state on to all of the clients as well as managed clusters. Is that the point? That's right. Okay. Yeah, the point is there's not a point where the policy is gonna be tampered with. So it's signed and it will not be pushed down to the cluster if the signature validation doesn't match. Yeah. Wow, that's a whole other layer. Yes, that's another layer of integrity. And to add to what Gus said, that integrity capability integrates with six store. The reason I mentioned that is because ICMS is about six store in the chat. Yeah. So we do integrated six store. In fact, that technology was built by IBM Research and they have contributed it to the six store community. And in fact, we are working very closely with Qverno team for them to use some of that stuff within Qverno as well. So that's why we're closing the loop, right? So we're basically taking the technology that we developed and contributing it upstream so that it can be utilized. So yeah, so the integrity of the policies obviously is extremely important like I said, because now we are using policies to ensure that you're operating your managed clusters to standards. Awesome. Okay, that's pretty cool. We do have a question. I can jump in, take a quick break from the chart, Gus. Let's see if this will show up on screen. It's a longer one. Working with an organization to use their own CAs often is extremely frustrating. A single TLS sessions need a CAA bundle reference to work. Does this external secrets function make this less frustrating? That might be for Jai and it might be for Gus. Yeah, I think it certainly could. Yeah, go ahead, Jai. No, yeah, we're gonna do it. Okay, yeah, so no problem, yeah. So absolutely one of the intentions of our ability to push secrets from the managed cluster to your fleet is to handle problems such as the CAA problem. Well, we can jump right in and talk more about Advanced Cluster Security and OpenShift Platform Plus, the exact reason that what this exact problem is solved with policies in that scenario because you have Advanced Cluster Security, which has a central server deployed to the hub and in our configurations and their managed clusters, whether you call it sensors or, I can't remember the other name for it right now, but they connect back to that central server. They need certificates that came from that central server so that they can securely connect back. Well, how do you get that pushed down? Well, you can either manually do it, you can certainly have some kind of Ansible playbooks to do it, or with little to no effort, you can use our policy set for OpenShift Platform Plus and just deploy the policy set and not only will it deploy the central server for you, it will deploy all of the managed cluster components for ACS, they'll connect back, they'll get the secrets and you don't have to manually push those secrets, the CA Bundle down to those managed clusters. So we could actually go into more detail here, take it as an opportunity to show a live system. Did you have a question? Oh, my favorite. Yeah, so Gus, I mean, while you're bringing this up, so what you're saying is that if in my multi-cloud domain, I need to deploy a hub-spoke architecture, something that is in a hub-spoke, I can use a policy set and I can deploy and that will take care of the entire communication, I mean, securing the communication, et cetera. Yeah, exactly, policy set, I... I get it. I mean, we can talk more about policy sets here, I had hoped probably to go over that in more detail. So we'll come back to the slides here, but okay, so that's the Advanced Cluster Security Console. Here we have the Advanced Cluster Management Console. This is new, the new ACM25 release across the top, we see an overview page by default and then we have a policy sets tab and a policies tab. So under policy sets, I have a policy set called OpenShift Plus Hub and OpenShift Plus Clusters. If I could look at the OpenShift Plus Clusters, I can see that it is deployed to a different managed cluster than the hub, well, I only have one extra managed cluster. So the particular policies here, if it will let me scroll down, okay, so I think it's just these two policies here. One of them is just reporting back status and the other one is a set of details that handles making sure the secrets are pulled down properly, so if I drill down into it, when you drill down into policies, you're going from the policies that the user created and as you dig deeper, you're going closer to the managed cluster where the policy is deployed. So I've dug down now into the policies here. A table showing the different managed clusters where the policies deployed and I can drill down now to the cluster level and see details in here about the policy. So it's a lot of details and the one thing I want to point out is here is an encrypted certificate value that was pushed from the hub and is now on the managed cluster. This encrypted certificate data gets decrypted by our policy framework and it creates the secrets from this data, so we have details here. This is the data portion of the certificate. The key is admissioncontrolcert.com and you have other keys here. If we scroll down, we'll see the other details here about that particular secret and there are additional secrets too because advanced cluster security has three components and they each need a different secret. They all contain the certificate data that lets them securely interact with the hub. Okay, so this policy is just defining to sync those secrets and pieces of content from the hub to your cluster that you want to be configured. So in our CA example earlier, this will make sure that that managed cluster has the CA necessary to handle that communication path. Now, the good news of course here is you didn't actually put this encrypted content in the policy. This is what ends up on the managed cluster so I jumped in pretty far here. So if we back up a step and edit, let's see, edit the policy where we have a little bit of trouble maybe getting that on the screen nicely. We have a template here. Notice that the temp has this special hub keyword. So if you were familiar with our older releases, that the ACM 2.3 release, we introduced templates and in 2.4, we introduced the hub templates but here in 2.5, you can now use hub templates with secrets. So the important thing to know with 2.5 is using this template, you can pull in a secret from the hub and it will automatically encrypt it and back when we were looking at our architecture slide, this encrypted value is actually what's gonna get synced down to the managed cluster. So that's how the magic happens and then the managed cluster is able to decrypt that value. And to connect the dots, sorry for the interruption, but to make sure I connected the dots, that secret on the hub can actually be populated from an external tool like Hashiq or Walt by using the secret operator, right? So that is how you can have that end to end flow. That's a good point, absolutely. Yeah, and then I assume, I'm guessing integrity shield also plays a part in this, you have a secret source that's providing a secret to the hub. That secret's getting templated into what is being applied and sent to this, your 1, 100,000 managed clusters. And I assume that that in-flight is also through integrity shield or can be since you have policy that it just, it's running through a policy. Yeah, the policy can be protected using integrity shield. Okay, that's amazing. Yep. This is actually huge and a general comment for, I mean, Gus is showing policies and stuff like that, you know, for the audiences, for the listeners, if you guys, if you folks just log on to the policy collection repo, as Gus said, there are enough examples. And from there, you can jumpstart writing your policies very quickly. It has enough varied example of what people are doing with policies. Okay. Exactly right. I was just gonna say, I'm gonna have to mention this. Yeah, absolutely, we hope. Sorry. I wanna make sure before we run out of time that we also mentioned about the policy generator. So Gus, when you respond to what Joydeep was asking, bring in the policy generator as well. Yeah, so I think I wanna try to tie all of it together and the policy generator being a part of that. Let's just show the policy collection repository. Okay, it's zoomed in well enough, I hope so that you get the idea. We have a policy narrator directory. If you go to that directory and our policy collection repository, it has instructions on how to use and get started with the policy generator. The generator itself is in another repository, but it's linked. Notice there's a couple of directories. There's one customized, which is just a basic sample. The basic sample has policies for gatekeeper and caverno and some general policies also. So it's a general sample. There are also policy set samples that use the policy generator. That's where we're gonna go, cause we wanna take a look at what we're just looking at. Just like policies, there's the stable and community folder at the root level of the repository that has just donated policies. Here we have something similar for our policy sets. Under community, we have the OpenShift Plus policy set. So where we were, okay, so this is what a generator could look like. Really all it is is the customization YAML that points to our metadata file and these other directories the other files that you would have here that you don't have to organize them in directories, but they could be just files located all here together, but the files that you collect here instead of being policies, they are the actual resources that you want to create. So if we drill into the ACS central and we wanna take a look at its operator, this is just a set of resources that will install the central server's operator and create the CR that the operator acts on. That's what you do, that's why the generator is a little simpler. I'm not creating policies here. I'm just putting the resources that I would see on my system here. And back in this top level directory, I have a little bit of metadata that says, okay, here I want to create a policy and I want it to be in form or in force and I have my security categories, my security standard and then the path pointing to the particular resource. Okay, so you can bring your bundle of YAML that you want to see or ensure that is on a managed cluster or on your fleet of clusters. You just have to have that box of YAML and this looks like a customized generator. So you can just use customize to turn that into a policy and make bring that into existence. Exactly. Absolutely. That easily. It is customized, it's got built-in support for the app life cycles subscription controller. So you can use ACM's application life cycle and point to this directory in this GitHub repository and it will install the policies generated from this generator directory. Wow. Yeah, I wanted to also add that, so that's absolutely right, Gurney. So basically what we are saying is, customer, if you're doing configuration management today and you have all this configuration file sitting somewhere, right, YAML? And you want to kind of make them into policies so that, and why do you want to do that? The reason you want to do that is because that then gives you, allows you using the metadata and associate those with various standards. You can also generate alerts for policy violations integrate with ACM observability automatically to integrate with PagerDuty and Slack and all those good stuff. You can trigger and some automation for policy violations. So you get all the holistic end to end flow by doing that, right? And you can also deploy these policies using Git and add integrity to them, the things that we talked about, right? So it just makes it a more strengthens it from a security and governance perspective. That's really what you're doing, right? And Gus, if you want to show the overview page where we have how the policies can be viewed in the context of standards. So if you go to our overview page, you will, because you are associating this metadata with policies, now you can actually see how the, how you're stacking up against various standards, right? Against regulatory compliance standards like PCI, et cetera, as well as enterprise standards like this day, 10 to 53, things like that. And that's what you're doing. Yeah, and Jaya, this is what the SecOps people want to see. They want to see everything green here, right? Yes. Yeah, okay. Absolutely. Right. And the other thing I also want to add here is, I think we have talked about a lot of cool features. I want to kind of bring it all together, right? So just to summarize, right? We talked about policies. We talked about policy sets. We talked about templatized policies, how you can tailor policies for various clusters. We talked about both, and templatization both at the hub and the managed cluster. We talked about policy generator, right? So if you have all these tools, cool features, I mean, where do I start? I mean, how do you go about operationalizing this, right? So I think so Gus, myself and others in our team have started putting together some best practices for this, right? So I think the way we would say is first and foremost, adopt GitOps. That'll be our mantra, right? And then the second is start with policy sets, right? And you organize, so you create a repo in Git, create multiple folders for each policy set, and then organize those policy sets in terms of the personas. Because by keeping this in Git, you are basically authoring everything there. You can do reviews, approvals, et cetera. And so you want to tailor that towards your personas, whether it is the SecOps or SRE and admin, et cetera, right? And you can also have the CISO security architect review the policies as well, right? So the whole thing can happen in Git, right? And then by combining these policies into policy sets, and that would include configuration that you bring that you auto convert to policies, you can then associate placement to deploy the policy sets to your managed clusters, right? And then get that full life cycle. So that's kind of the overall approach. So Gus, you want to add anything to that? So I know we are still authoring these best practices, so welcome any feedback, any questions on that topic too. So I'll just mention that, you know, Jaya was talking about the different personas. One of the key values with policy sets is now, now instead of, as in previous releases, just having a long list of policies. And here it's difficult for me to know as the SRE or as the SECOPS, which of these policies should I be concerned about? That's one of the reasons why we now have policy sets to help alleviate some of the problems where there's a policy and I'm not sure if it impacts me as the SECOPS or if it's really someone else's. So now we can try to organize the policies and it's not just to organize them for the purpose of, you know, the SECOPS or SRE knowing if the policies for me or not, it's also to help with the placement. So if I have this set of policies I can use, use placement for the set instead of having to go policy by policy and knowing if each one is placed on the right set of clusters. Okay, so that, that lets you take your bin of things that might be GCP specific if you need to deploy like a GCP appliance that's some Coobery sources. You can take your cluster API things for Google Cloud and you can take those specifically and put them all in a set that holds 10 different policies that says 10 different things, put them in a GCP box and apply them just to GCP clusters. That's what it sounds like flow wise. Okay, exactly. Exactly, yeah. And you could have in your organization somebody who's a GCP SME, right? So now they own that thing and they own that piece, right? So it allows you to kind of segment and manage policies in a more efficient way. Okay. And sorry, you can come to the screen to check the status and you can get the violations, you can get notified of a violations other ways as well through Slack and Pager or whatever you choose to. Awesome. Okay. And by taking your resources and turning them into policy you kind of get all of that, all of that rich community integration with policy and all of the other alerting and all of the other components you just get that for free because you've converted it to policy. That's incredible. And everything is defined in Git, could be defined in Git. Yep. So Gus, I saw a ACM hardening box there. You wanna talk a little bit about that? What are we doing there with ACM hardening? Right. So we have ACM hardening, a cluster hardening and an open shift hardening with ACM hardening. We are trying to make sure we have a set or we keep accumulating the best practices for the ACM hub itself. So in this case, you see I have violations and that's because for a hub cluster you really should have your backup and restorative and I haven't done that. So I have a violation there but it is also taking a look at some of our other best practices as far as the hub is concerned, just checking on status of subscriptions and different key resources within ACM at the hub level. The other hardening ones, the cluster hardening that would be more of a general Kubernetes focus and the open shift would be the open shift flavor of Kubernetes and some of the security best practices for open shift clusters. So can you talk, because one of the things I've been, terms I've coined is the automated governance, right? So this is where we are integrating ACM with Ansible Automation Platform. So Gus, can we show a little bit on take a policy, an example policy where you can trigger Ansible Automation for a policy violation. So that's one aspect, right? The other aspect and maybe I'm sure Gurni has lined this up as a future topic here is how we have now introduced Ansible Modules to drive ACM itself, right? For driving ACM Ansible Automation through ACM and there are some benefits to doing that. So I think that's definitely a future topic but what I wanted to highlight there is by letting those automations run through ACM, now you can also tie ACM's policy management into that flow, which basically means now I can monitor what service accounts are being used to run these automations, right? And see whether those service accounts are getting deep provisioned on a periodic basis so what kind of privileges are being granted on automation? So these are kinds of things that you can now monitor by bringing ACM into that flow. So that gives you better enhanced security and governance when you're running your automations. Absolutely, so it would probably take me a few minutes to do the automation, I did install it but I haven't finished setting up. The next step is to create a credential which I could go ahead and do but it would just take a little while so we probably could postpone that if you like. It sounds like we need to have you back and do a end-to-end live demo with us on this is what it really sounds like and maybe get some of the Ansible folks in too. Absolutely. What do you guys think? Be happy to come back because I know we didn't get to even all of our two five features. Yeah, I was gonna say there's a lot in this box Oh, let's see. And let's see, we can probably start wrapping up here just because I see some folks, I think moving on for, I assume the next thing in their day but I didn't want to stop us too early. I'll share out, Jaya just shared out a nice link that I'll send out. Is there anything else we wanna close on? I think I've learned a lot today that I can bring my box of YAML. I can turn it into policy and then see how my clusters are behaving based on that bundle of YAML. And it looks like there is a collection repo that I can go and get a bunch of pre-made bundles of YAML for different hardening. And that's all in the open domain. So I think we can all get to that and make my own. And yeah, there's a deploy directory that helps you deploy it using GitOps with ACM very easily. Makes it very quick and easy to get started just straight from this policy collection community. And if the details here aren't enough to get you started then just click on the blogs directory and we have bunches of blogs that go into even more detail on these things. Yeah, the only thing I wanted to add while we wrap up is the next aspect we are focusing on is compliance, how to bring the compliance angle. So you saw the beginnings of it when Gus showed you how you can add the metadata and represent policies in the context of compliance standards, right? So what we are now doing is to integrate the policy reports here that Gus was mentioning with OSCUL, OSCUL is a standard from NIST for compliance assessment results. So that's a piece of work we are working in the context of the policy work group and we are also bringing it in into Red Hat products. So that is something watch the space. So that will give you a more holistic view from a compliance point of view. And as you know, we have a lot of managed services within Red Hat. So one of the things we are also looking at is how to apply these techniques to Red Hat's managed services in the cloud. So that's another area of focus as well. So those are the two things I wanted to mention. And the link Gus Gurney just shared is a conversation myself and one of the GitOps product managers had with Red Monk. So you can listen to that, that'll give you a flavor of the direction we are proceeding. Awesome, sounds like we have two more shows coming up then. One soon about compliance and let Gus finish showing what he didn't get to demo today and number two on a managed service once Jaya has that up and running, right? Yes, yes. Sounds like you're busy for a month. And then of course the Ansible integration, right? That's the third show. Oh yeah, oh goodness, yeah we do. Okay, well the schedule's filling up everyone. So it will be an exciting time. Anything else before I close off Gus, Jaya, anyone? No, this has been awesome. Thank you for the opportunity, Gurney. Yeah, thank you. Always and glad to have you on. Thanks for joining. Joy, do you have any closing thoughts? No, this is just awesome. This is just awesome. I'll close then and say check out the stream archive. Check out, Jaya has a huge list of resources that she's assembled that I'm gonna leave on the YouTube. There is a YouTube page stream for this. So it'll be a stream archive. I'm gonna leave it all in a comment there. So if you wanted to use amazing resources she's prepared, I'll drop it all there. Most of the links have been in chat already. But if anyone wants to read up more, that's where to go. Thanks everyone for joining today and watching and please feel free to reach out to the show contact at cloud multiplier at redhat.com or reach out to any of us individually on our various emails that have shut up. So without further ado, I'm gonna play the intro as an outro and promise to eventually get an outro here soon. So thanks everyone. Do the next one.