 Good morning, good afternoon, good evening. Wherever you're hailing from, welcome to another episode of Red Hat Advanced Cluster Management Presents. Today, we're gonna be talking about a little bit of security and governance with OpenShift Platform Plus. I am Chris Short, host showrunner, streamer to the stars. And one of those stars is Scott Barron. Scott, how are you today? Great, I'm good, man. You're all too kind to us. You give us such an easy entry into your platform. Thanks for having us. We love your show, big fans. I'm gonna be honest, I did not watch much of it during July because I took some PTO. That's fair. But I heard you had a little outage at your home, so it looks like you're doing better. Things are good. Yeah, things are better now. At first, it was Comcast issues and then we just had three tornadoes. So yeah, everything's okay now, but there's a 5G hotspot that I'm getting today. All right, that works. You're coming in loud and clear. You look good. So hats off to you tornadoes or something that just kind of happens every Tuesday here in Austin, Texas. Yeah, it's not normal for us up here. This is the case of life. Speaking of Austin, I'm joined by the Ledecky of security, the gold champion, the stellar star, Jaya. And Jaya joins us as the Chief Security Architect of RACOM. So I'll let Jaya introduce herself. Hi, everyone. Really excited to be here and on Chris's show, it's always fun. I am the Chief Security and Governance Architect for Red Hat Advanced Cluster Management. We'll be talking about how ACM can help you and comply to enterprise standards. We'll also talk about the OpenShift Plus bundle that includes ACM along with ACS, our new star in Advanced Security. Talk about that a little bit, how they all come together to help meet your compliance and governance needs. I've been working in the security space for over 20 years and I'm very excited to be here. Thank you. Jaya's a champion. Thank you for joining us today. And we're also joined by the LeBron James, another Gold River star of the team here, Gus Parvin out of Raleigh. Go ahead and introduce yourself. Hey, I'm Gus Parvin. I'm on Jaya's team. I'm one of the developers on the governance risk and compliance team. I'm here to just show off some of the work we did for the ACM 2.3 release. We've got some cool features coming, some Ansible integration, some tippling, so it's exciting stuff. We're excited to show it off. Yeah, we're fired up Chris. We actually have a GDA coming out in two days. 15th of November went out last week. There's a boatload of technology that we stuffed into this 2.3 release. So Gus is kind enough to have a demonstration for us that we can weave in throughout our conversation. But yeah, again, really, we just wanna talk about the importance of security within our portfolio, how ACM brings that forward into the platform plus, as well as ACS, as Jaya was talking about, we really want that unified message to come through. And we're working hand in glove with not only open shift, but also the ACS team to make sure we have a consistent delivery. So you'll start to see more of that as our roadmaps converge. For example, today we're gonna talk about how we can deploy the ACS central. And in the roadmap, we have plans for how you can deploy the ACS sensor. So all the bits and pieces that go out to the managed cluster and ensure that they're feeding in to one central hub interface. Nice. So yeah, lots of good work that we've been doing for folks like Gus who've been working day night and weekend to make it happen. And Jaya keeping them all tap dancing to the right beat. So what do we wanna do first, Jaya? Do we wanna take a look at kind of our overall picture and where we're headed? Yeah, I think it'll be good to first do some level setting. I don't want to spend too much time on charts, but I think maybe a couple of charts just to walk through and level set the concepts and the architecture. And then I'm gonna give Gus a lot of time. I'll show a little bit of the demo for some of the existing controls enforcement points that we integrate with like gatekeeper and such. And then I'll let Gus show off the cool stuff that is coming in ACM 2.3, okay? Nice. Okay, so you do you want me to go ahead and share my screen? Yeah, go for it. Okay. Yeah, and Chris keep us posted if any questions come through. We'd love to take a look. Yeah. Yeah, we'll do it. Okay, so typically when customers are transforming from their IT traditional IT infrastructure to adopt cloud, one of the key things that they worry about is how do I meet my security compliance and governance needs? So, and these needs are driven by both trying to meet their enterprise security requirements, enterprise software engineering requirements, et cetera. And also for customers who are in highly regulated industries, whether it's healthcare or financial, they have to meet regulatory compliance requirements, whether it is PCI or hip hop or for federal customers, meeting FISMA, FedRAMP and all those requirements, right? So, and if you think about the ops person or the site reliability engineer who's operating the cloud platform, they really are not experts in every aspect of security. And if you look at how to secure a cloud platform, you have to focus on so many different aspects of security, right? You have to focus on authentication, authorization, role-based access control, data and transit protection, data address protection, et cetera. So, how do you ensure that you're operating the cloud platform to meet all these security requirements and how do you make that easy for the SRE? So, this is where our approach is what we refer to as policy-based governance. So, what we mean by that is to codify the best practices as policies and have those policies authored by the subject matter experts for the particular control area. And then using a GitOps mechanism where you manage policies just like source code. So, you have all your policies sitting in Git and then you use a mechanism called subscription to deploy the policies onto your various managed clusters. So, the conformance to the enterprise standards as well as regulatory compliance standards become like a push button automation. So, that is really our vision, right? So, that's what we mean by policy-based governance. And if you think about it, how do you implement policy-based governance? Is you want to ensure that all the various controls, whether it is for security or resiliency or software engineering, they're all configured to the desired configuration state. So, that's where the configuration management becomes the mechanism you use to implement policy-based governance. So, with that context in mind, what are the key capabilities that you need in a system that is providing policy-based governance, right? So, if you think about what we have within ACM, first of all, it has to be multi-cluster. So, one of the things we agreed upon or decided upon upfront is there's not gonna be a single policy engine on this planet, there'll be multiple, right? So, what we want is you want to design, have an approach that can integrate with multiple engines and you want to be able to deploy policies across multiple clusters. So, if you look at the existing policy engines that are out there, whether it's Gatekeeper or Cubano, these are all single cluster engines. So, how does ACM then layers on top of it and makes them multi-cluster up there and it allows you to manage those. And our policy framework is extensible so that you can easily integrate both Red Hat and third-party policy enforcement points. So, for example, when Gus shows off the policy collection report that we have, which is our upstream community for collaboratively building our policies, you will see that we have policies contributed by third-party vendors that we work with, like Systec, Synapsys, et cetera, right? And we also have policies for the Red Hat enforcement points. And Scott mentioned, we are adding policies for ACS, which is a new product within our portfolio, part of the OpenShift platform plus. And we also have policies for native OpenShift security capabilities because OpenShift itself comes built in with security capabilities, including the compliance operator that allows you to enable rules for multiple compliance standards. So, again, compliance operator is a single cluster and ACM brings it to multi-cluster, right? So that's kind of our overall approach. That's a really key slide. I just want to point out three things. One, you told us that ACM is the center of the opportunity here. We're bringing the multi-cluster management capabilities and distributing that out to the stack. Two, we have an open policy, we have an open framework around policy and an open framework around tools. We know that there's not just one single tool in the market. We know that customers already have a preferred player. We want to make sure we can work with that. So look at this list of third-party peps, you know, the list of community policies that we have. I'll put that repo in the chat. Oh, it looks like somebody already did. Thank you. Thank you. Yeah, so it's fine. Thanks, Jenny. And then the third part of that is, again, in looking how ACM drives that capability out at the multi-cluster way, looking at how we can just start to adopt and do it all with GitOps. I'm sorry, but I was just on a call this morning where they said that so-and-so is out of the office and all of the Ansible scripts are on his desktop. Oh. And I was like, okay, this is a customer call. And I said something before, but I was like, I'm kind of in not sorry, but I'm sorry. So, you know, we don't want that to happen to you. We want you to have a central code repository and the YAML-based mechanism, the YAML-based approach really is a readable straightforward code that we have for our policies. And that's stored in code, it's stored in a repo. That's your centralized source of truth that you can spray across the entire fleet. So I love this slide because it really hits those three points to home. Sorry, Jai, I threw you off a game, but I just think it's important to understand the value of the situation here. You don't really have one tool that can do it all. Right. Yeah, and I'm glad you shamed in, Scott, because somebody told me that it's always a good mechanism to have three things to remember. If you go beyond three things, people tend to forget. So when I put this chart together first, now I had many, many bullets, right? And then somebody gave me that advice, distill it into three things. And you got it in before the 15 minute mark? So, hey, we're doing great. Okay, cool. Okay, cool. Okay, let me be quick here because I don't want to give Gus a chance to show off things. So overall, I'll just talk high level to this diagram. I know the words are tiny. That's because we have too many cool things to talk about, but the following charts have broken this up. But from this diagram, just take it that we have a management hub, which is from where we orchestrate the policy deployment and governance. And then you have the managed clusters on which the policies get deployed. And then you have various policy enforcement points on the managed clusters that consume those policies and return to sales back. And then on the right-hand side, we integrate with enterprise tools because we want to play into the current processes customers use to achieve their regulatory compliance and enterprise standards compliance goals. Okay? So this kind of breaks that down. So on the managed clusters, I just wanted to highlight here that if you think about policy enforcement points, what they are doing is they are basically providing new capabilities. And again, I want to emphasize the fact that ACM allows you to manage not just security aspects. You can also manage resiliency aspects. You can manage software engineering aspects. Example of resiliency is you want to make sure that the Linus probe is running, enabled on your parts. Example of software engineering is you want to make sure that a particular version of Kafka is used, right? So ACM allows you to do all that, right? And then these PEPs enable some technical controls and those technical controls then map to compliance standards. And you could have a single technical control map to multiple compliance standards. And if you look at the ACM dashboard that I'll show you, you'll see that we kind of provide you that mapping. And then I wanted to highlight key things that are coming in ACM 2.3 that Gus is going to show off. One is something which we call templatized policies. So why did we introduce them templatized policies? Because what happens is there are certain policies that we have managed cluster specific information that is needed, okay? So then today, meaning prior to ACM 2.3 you will have to define a policy per managed cluster if you need something customized like that. What we have added in 2.3 is the ability to templatize so that you define a single policy, you can then templatize it to apply the particular configuration for specific managed clusters. And you can do that if you want a particular secret that you, for example, populated onto the managed cluster from Vault or a config map or a cluster claim which is specific to the managed cluster. So those are all different ways you can templatize policies. That is one key capability. The second one I wanted to highlight is the integration with Ansible. I consider this one of the key features of 2.3 because this now brings governance and automation together, okay? So customers are already using Ansible to automate many of their IT tasks today. Now think about the power if I can build our policies that tie that automation so that now you can ensure that that automation is driven using your policy mechanisms, governance mechanisms. So that's what we are doing. We are just starting the journey and you will see a demo of that. Those are the two key capabilities coming in 2.3 I wanted to highlight. In addition, Gus will also show off a lot of community contributions for policies. We have a lot of new policies that have been contributed. So we'll show off that. Then I also wanted to talk a little bit about roadmap. What is coming in our future, right? So all the things that are in orange here are things that are coming in the future. So let me highlight that. So myself as well as Gus and others in our team have been working in the Kubernetes Policy Workgroup where we have defined a standard called Policy Report. And that allows you to report results for policies in a standard manner. So now we will integrate our policy framework with that so that we can externalize policy violations using the standard format which can then be used to integrate with all the enterprise tools on the right-hand side. And we will actually integrate with our observability to be able to generate alerts to Slack, et cetera. That's one that is coming. Second is we want the ability to generate policies conforming to our policy format in an easy way from existing policy libraries. Why is this important? It is important because as we mentioned earlier ACM can integrate with multiple policy engines. And what we are finding is each of these policy engines, whether it's Kubernetes or Gatekeeper, they have their own community, they have their own policy libraries being built there. So we want those policy libraries to be quickly brought into ACM. So that is the policy generator piece that we are working on. And we also want the ability to schedule when policy evaluations happen. And lastly, we are introducing this concept called policy set. By that, what we mean is now when I show you the dashboard, you're going to see that we have a list of policies. Then how can you organize them based on the enforcement point or based on the environment where you applied the policy or based on standards. So we want the customers to be able to easily manage because we want them to be widely successful in our Github's mechanism, which means they're going to have a lot of policies. So we want them to now be able to organize them properly. And then when they do that, eventually we can then our vision is once we have the policy set concept, let's say we have a policy set for PCI, right? Then we can grab this policy set and say, apply this to all my clusters that I want to be PCI ready, right? So that's kind of our vision. And so we are setting the stage for that here. With that, I am going to now switch to the demo. Sorry. Can I pause for a second for a question since we're talking about the future. Are there any plans to combine the compliance operator and the container security operator with advanced cluster security? Yeah, go ahead. That's a great question. So the compliance operator again is single cluster today, right? So you can specify a security profile to it and it'll enforce it on a single cluster. There is already work in progress to integrate the results of the compliance operator into ACS. And it is already integrated into ACM today. And I'll show you that. And the difference between the integration with ACS and the integration with ACM is ACM is more focused on a high level integration, right? Whereas ACS is going to have a more drill down integration because ACS is more focused on advanced security. So it will have more of the drill down views and it will allow you to map those violations to risks and more focused on security aspects, right? So that's one. And the second question you asked is container security operator. The OpenShift platform plus includes both Quay and it includes as part of that the container security operator and includes ACS and ACM. The container security operator focuses only on Quay today, whereas ACS is able to detect vulnerabilities across multiple repositories, right? So I expect that those two capabilities will kind of converge together. Yeah, okay, that makes sense. Thank you. Any other questions before I quickly show this? No, there's not. Thank you. So this is our ACM console and if you go to the governance and risk view here, okay, hopefully it'll come up. I hear you clicking on it. Yeah, very good. Yeah. So like I said, at the very top we have the summary, the PCI, the standards based summary. So this is where we will introduce that policy set concept where you will not only see the standards, you will also see things like my production environment has these policies or you will see a box says gatekeeper, right? These are all the gatekeeper policies have deployed. So you'll see that in the future. So I want to show here the gatekeeper integration we have. So for gatekeeper, we have a policy that deploys gatekeeper operator. So again, one of the key capabilities ACM has is this config policy controller. And that basically can distribute any Kubernetes resource. If you think about how an operator is configured, it itself is a Kubernetes set of resources, right? So we are basically using our config policy controller to author a YAML and then we can then deploy any operator actually. I'm just showing your gatekeeper as an example here. And I wanted to show you a gatekeeper policy. So this is a policy for liveness probe, the resolution policy I talked about. So you see here that this policy is configured properly. So that's why that is set to compliant. And there are two things we can do. The way gatekeeper works is gatekeeper is a bridge for OPA to Kubernetes. It installs itself as a admission webhook. And when we deploy this policy, it is going to check on any new resources that are getting created, Kubernetes resources, whether they comply with the policy or not and it will block things, right? So that will be the admission violations if something is blocked. The audit violation is what if you deployed the policy and you already had resources prior to that, right? So gatekeeper also has the ability to periodically audit and report on violations as well. So that's what you're seeing here. So there are some audit violations and there are some admission violations that we are showing here. The other thing I also wanted to show quickly is the compliance operator. So for the compliance operator again, it is the operator. So we have a policy that can be used to deploy this operator. And you can see it is in place for both the local cluster on which the hub runs as well as the managed cluster. And then to the compliance operator, you can configure multiple profiles. And as an example, we have this E8 security scan profile defined here. And you can see that it is doing the scans and then reporting violations. So you can see on the managed cluster here there are violations. I can click on the details and I can see for the various rules that it's checking what are not compliant. Right? So that's a big whoa. You don't want to run this on your home lab, Chris. I think I'm like, I'm like, I'm like, come on. You don't think my home lab is fully secure? You know, big money, no whammy is that kind of thing. Keep your friends cross. Yeah. So the, I mean, in the case of ACS you will now be able to go into more level, next level of detail here, right? So you'll be able to actually see what is the violation how can I fix this violation and all those details, right? So that's the drill down capability ACS brings in, okay? So at this time I'm going to pause as take any questions and I'm going to turn it over to Gus. Okay, thank you. What's cool is like I know the ACS roadmap is a mess with priorities right now, right? They just went through an acquisition. They're under pressure to go full speed open source. They're trying to figure out how to integrate everything with open shift and make it, you know, looking at butter and jelly. We've been there. We know Chris was like running hackathons. They're running, you know, they're doing it all. And yet they managed to produce an operator in about two sprints. Maybe it was three, maybe I'm over-exaggerating. But what's awesome about that is it accelerates the adoption of the ACS central because it's an operator. We can now proliferate that onto the hub. We can start to have that story where ACM is the central management focus of the port of the platform plus the open shift platform plus portfolio piece. It's a lot of piece. And then what Gus is gonna show us here is driving forward that message with his opportunity to show us how it all works together. So Gus, I can see your screen. It looks like you're ready to run with it. All right, yeah. Thank you, Scott. So yeah, I do have a bunch of different policies deployed. So I'm jumping right in, you know, assuming you've gotten the background that Jaya kindly provided and Scott's right. We do have, you know, the ability to quickly and easily deploy operators, the advanced cluster security central server is certainly one of them that we can deploy. I've got it deployed. It's one of the windows I have open somewhere here. I believe it's this one, right? So advanced cluster security is one of the policies that now have been contributed to our policy collection repository. So getting that central server up and running on your ACM environment is now quick and easy. And a lot of that is a lot of thanks to them been making an operator and that's available in their latest release. Another aspect of what I wanted to show is, you know, here's our list of policies. This is what you see in 2.3 and there's something new here. It's this automation column. So over here towards the right, there's now a new automation column that has the configure link or button here that I can click. So let's just click that. And now we have a dialogue where I can, you know, quickly and easily define policy-specific automation and this automation can do lots of different things. Because now it's going to go off to Ansible and you can run, you know, any job that you desire through your Ansible Tower. I've got a credential already defined. So, you know, the first thing I have to do is just select my Ansible credential. The next thing, and I'm zoomed in a lot, you know, when you're looking at this maybe on your definition monitor, you can see a lot more of the things on the screen at once but I want to zoom in so it shows up well. The next thing is the template I want to run. So which Ansible job template do I want to run? And I've got one here, a policy compliance template. I probably should have put Slack somewhere in the template name because its goal was to send a Slack message when I have a non-compliance. The next things here are the extra variables. So you got to do some typing here and I'm going to cheat. I'm going to copy and paste. So you don't need to read what I'm copying. I don't think that's cheating. I think that's just having your source code available. That's right. And I'll mention real quick, you know, what my copy and paste is. You know, I'm providing the policy name as one of the variables, the namespace and the cluster name here. And that's just because my particular Ansible job, you know, uses these fields and we'll see that in a minute. In general, it's a good idea probably to have the policy name. So you'll know, you know, what triggered this violation. It's something that, you know, you just need to specify as one of these extra variables. So walk me through this. Walk me through this. Because typically when a customer uses a certificate type of policy, they're going to be informing. That's the verb. That's a YAML verb. And they're going to be informing about things like wildcards in the certificate or hosting violations in the certificate, explorations in the certificate. So that's one of the typical things you'd be scanning for to kind of figure out what's the status of certificates out there in my applications. Now, normally that's just an audit kind of posture. We're just going to inform. But you're actually wrapping in an Ansible hook here that's going to do some work for me. So help me understand why that's important, why that's impressive. Oh, yeah, absolutely. Yeah, I should have backed up and mentioned, you know, what this policy does. Yeah, you're absolutely right. This policy is monitoring a particular namespace for any certificates that are getting close to their expiration and certainly an Ansible job. And in my case, it's going to alert the administrator that the certificate is about to expire or in my case, it's already expired. But what you can do with the Ansible job, of course, is you can work on your remediation to make sure the certificate is getting properly refreshed and rotated or, you know, the sky's the limit on what you can do with your automation. It could make you a peanut butter and jelly sandwich. I'm pretty sure this is a playbook for that somewhere out there in the Ansible Galaxy. But that's kind of the fun. And I probably shouldn't use that word. That's the value, right? The customers have come forward and said, we love the auditing perspective, but we need more. We need to be able to touch things off cluster. We need to be able to work with infrastructure tooling that our cluster admins don't necessarily get to play with. It could be a CMDB that they're updating. It could be firing off that service now ticket. You're using Slack in this case, which is great. So this kind of thing where you start to marry together traditional infrastructure that's off the cluster with these on-cluster things like applications that are running in your cloud-native environment but bringing those together is what Ansible really is a sweet spot for us in that integration. Sorry. And to add to what you said, Scott, I think Ansible itself is also introducing a lot of playbooks for cluster operations as well. So what we are doing is we can also marry that here, right? So we are basically bringing the automation power of Ansible to the governance power of ACM and help it. So the way I would phrase it is we are helping your chief automated governance, right? Yeah. And you mentioned service now. I'll give a quick plug for an upcoming blog. We do have a blog that's pretty much ready to go. A member of our team named Matt, he has a blog that shows almost exactly this case, integrating an expiring certificate with Ansible and opening up a service now ticket. So that'll be a great tutorial to walk through if anyone needs some extra help on getting started with automating policies and especially in the certificate expiration case. Yeah. We get these kind of requests from a lot of our customers in particular in the financial services. They want extra levels of verification. I mean, everybody wants that, right? Right. So just pick one industry, but to be able to have the extra level of verification, whether that's four eyes of verification and get before you commit, Ansible does provide obviously those breakpoints to bring in another person, bring in your security team, audit that particular piece of it, check what you want to do. And the goodness of this is, these are get based policies, right? These are backed in code. So the demonstration that I've interrupted here rudely, I'm sorry, but this demonstration shows kind of how you create this experience and how you would drive it from a user interface. But these are all manifests that are stored in code repository, these are YAML based. We can shuffle things directly over the API through subscriptions and to get whether that's the OpenShift GitOps operator or the native subscription that's built in. You have all of those options at your fingertips. I'm sorry, Gus, because I went long-winded, but I want people to know, you're showing them that really is a whole opportunity for them to do it for more once they get this code in their hands. So yeah, absolutely, you're right. And we definitely are looking for feedback from customers too, as they pick this up and start using it. I'll mention here the next thing in the demo here, we've entered in our credentials for Ansible Tower and we've entered in our extra variables that we want to pass off to the job. When do we want to run the automation? So we have a few choices here, and this is an area where we're kind of expecting and planning on some customer feedback because right now it's limited to manually running what we call a run once mode and of course disabled, which isn't going to run your automation at all. So I'm going to pick run once mode and it tells you here what that does. It runs the automation one time and that's it. So once it runs, it switches over to disabled. When using GitOps, you can certainly have your policy automation run continually if you want to by having your GitOps, of course, reconfigure the run once mode. So I'm going to save that in order to trigger it though, now that I put it in run once mode, I have to have an expired or expiring certificate, which right now I don't think I have one out there because my policy is compliant. So I'm going to switch over to command line and just create a secret here in the namespace where that policy is monitoring for certificates. That'll take a minute to create the secret and then it'll take a moment to transition to non-compliant once that controller sees that there's a certificate that's expired. Yeah, so we'll be through that Gus because I'm slow on the tape. Did you do an OC apply on the hub cluster or on a managed cluster? I remember Jay had two pictures. One focuses on the hub experience and the other side of that is where we have controllers running on that, you know, managed cluster. So the controllers are all running on managed clusters. It just so happens though, our hub cluster is also a managed cluster. So that's what I'm doing here, but you're right, it is a managed cluster feature. So I'm looking across my fleet of managed clusters for an expired certificate and I just created one out there in the fleet. And in the dialogue here, we do see now that the policy is not compliant on the managed cluster where I just created that certificate and that's gonna cause the automation to kick in and run. It does take a few moments for all the different pieces to connect together and for the automation to run and complete. What will happen in a few moments is I will get a Slack notification. And, you know, I've done some testing, so I've been getting lots of these, but I'll get a new one that will show up after this new Tom stamp I've logged in here at the bottom. So while we're waiting for that to show up, one thing I wanted to highlight, Gus is the credential you use to connect to the Ansible Tower. That is all managed centrally on the credentials tab that you have on the left-hand side, right? And the reason I wanted to point that out is we have Ansible integration with the other life cycles, like application life cycle. And the credential information is kind of centrally managed so that we can use it for all the three life cycles, right? So just wanted to highlight that while we are waiting for the Slack message to show up. That's exactly right. I just switched over to that credentials tab. I didn't show it, just because it's not so exciting for me to enter in my credentials, but it is one of the steps that you need to do ahead of time. While we were chatting about the credentials, the Slack notification did appear and you see the extra vars I passed in provided the policy name and the namespace and the host name details I provided, give me some links here. I could click on to go and take a look at it. And the other value here is I see which cluster that non-compliance happened on, so where it was detected. So this is the managed cluster that's now not compliant in my fleet that has the expired certificate. So what we have here is the details we need to go and provide some remediation in this case because the Ansible job is notifying and not remediating. So Gus, I just wanted to add one more thing, which is our policies can operate in informed mode or enforced mode. So when you operate in enforced mode, we automatically make sure that the cluster is complying to whatever standard you have set in that particular policy. Say for a CD encryption, if we enable encryption and somebody went off and disabled the encryption, we'll put it back. If you operate it in informed mode, then what happens is you will see a violation like what Gus is showing here for the certificate. So what it allows you to do is if you are a customer who has to follow certain enterprise processes, operational processes where I need to open a service note ticket or I need to generate alert to some instant management tool, et cetera. If that is your operational process and you want to follow that and still use ACM to provide that policy-based governance, this is the one way to do that. So you're kind of bringing the two worlds together where you can still apply policy-based governance and you can still meet your IT operational processes standards. So I just wanted to highlight that. Yeah, that's a great point. I'm gonna hit the hammer again that credentials area does open your eyes. It shows you that now this Ansible credential can be used in other parts of ACM, right? So credentials becomes a center point to your story, Jio, which is we know that Ansible lives everywhere in the infrastructure. We're gonna use it in cluster lifecycle. We're already using it. I mean, sorry, what I should say is we know that you're going to use it in cluster lifecycle. That's why we implemented it there in version 203. It has already been an application lifecycle. It comes up with full GA and now it's in governance. So all of our core pillars, all of the areas that we expect our customers to interact, we've brought Ansible integrations into that space and that's why it was important to start to elevate that story as a credential. It's something you're gonna interact with more and more over time. Let's keep track of that for you so you don't have to manually put that in and a bunch of different UI and a bunch of different EMOs. Right, and to follow up on that, Scott, this also helps us in our roadmap to provide integrate this credential management capability with external secret management tools, right? Whether it's HashiCore vault or in all those, because that's another enterprise requirement. So this, so the first step toward that is to first consolidate all our creds in one spot. Now then we can do that integration. Back to you, Gus. Keep interrupting. All right, no problem. I'm gonna use the next Ansible example to try to transition some and kind of show off Ansible gatekeeper and our new template support a little bit. So let's see how this goes. I'm quickly going to go through the same procedure as before, just the policy that I have deployed here is a gatekeeper container resource request not set. So that's kind of a mouthful. Basically, you can use gatekeeper to stand as sort of a guard in your Kubernetes environment and not let things in that don't comply with your standards. In this case, gatekeeper is gonna guard against people creating deployments that don't have resource requests set. So this is like the CPU and memory resource requests and some customers really want you to have that because they're very interested in capacity planning So here we go with, that's kind of the quick background of why you might want this policy, but I'm gonna go through now some automation with this policy. So we want some automation to kick in when it happens and we're gonna use just the same automation here cause I'm really gonna try to tie some things together here a little bit and I'm gonna do the same thing where I copy and paste my extra vars. It's the same idea. These are the extra variables that my job needs, my automation job needs to have. Scroll all down. I'll go once again with run once mode. That's kind of our main mode of operation. We want to trigger a policy when it becomes non-compliant. Right now you see the policy is compliant. So I think I've filled out all of the information. You see and I now have a policy automation defined here in the automation column. I guess I'll back up a minute. We can go back into one of these and see that we have some historical data here from the job that we already ran for the certificate one. And here we can actually view the job that Ansible kicked off and get some details and status information that takes us using ACM search feature directly to that Ansible job resource with those status details. So that's another useful thing I thought I'd just mention real quick. Okay, so back to this. Now we have automation defined for this gatekeeper policy. I want to trigger it. So just like I had to trigger the certificate policy with an expired certificate, I'm going to trigger this one with a deployment that doesn't match the specifications we have for that gatekeeper policy. So we'll do the same sort of thing where we apply a YAML. I get back an error. The thing I want to highlight here is the error is identifying the policy and it's telling me some details about that particular container I'm trying to get and the container I'm trying to apply not having resource requests. The interesting thing here, I'm going to point to real quick is it has the managed cluster name here in the error message. If we go and take a look at the policy that I wrote for this. All right, I got to remember where I put it. We're all on the edge of our seats. Get the popcorn, folks. Of course, just to connect the dots, right? So really what really happened here is the gatekeeper admission controller is basically blocking this, right? Is it what happened here? That's exactly right. That's right. So the gatekeeper admission controller, it blocked it because it saw I did not have and I didn't show the YAML. So I figured that just take a little extra time but if we looked in the deployment, we would see it didn't have the resource request identifying CPU and memory needed for that deployment. Here in the message that we were just looking at in the screen, you remember it showed local cluster. Well, I have a template here. This is a GoLang template. So what we're looking at now is a policy that it's a gatekeeper policy and inside it, we have a template that was resolving to the managed cluster name. So now I can have, you know, customizations as I think we mentioned before, customization specific to the managed cluster, you know, before ACM 23, you would have to code these customizations into separate policies for your different managed cluster. Now using this template feature, instead of having bunches of customized policies, you can have one general policy that can feed in unique values for each managed cluster. And in this case, I'm pooling that managed cluster name directly from the controller that's running on the managed cluster is evaluating it and grabbing it at that time, as opposed to when the policy is deployed. You just blew my mind. You brought together, okay, hold on. You brought together gatekeeper, which has been in the product for, this is our second release now, but you've enhanced that by driving the gatekeeper response. I think you did that with Ansible. So this is a one-time response you did that you haven't even showed us what that did yet, but then there's templatized, the enhancement we put in there, it was a handful of customers, one of that that says go reach out to the managed cluster, pull a little bit of information off of it. In this case, you're decoding a, how CUBE config secret to get the cluster name and you're populating that into the template so that it can expand that and show me the response in that error message. Yeah. That's right. That's right. So, okay, and again, Jay, I'm gonna say a few words, but we are the open framework that brings together all of this, right? Because there's not just one tool to solve them all. So you've brought a GRC framework that establishes policies, YAML-based things that not only deployed that gatekeeper operator, but also deployed this container resource request not set. So that's a webhook. And then it barked at you and said, no, you can't do that. That's using templatization. And you also added a run once ansible automation on here. Exactly. And I don't even think we saw that part yet, but. No. There's more wisdom that can happen. Yeah. We see that it's not compliant though. So when I tried to create that deployment and it failed with that error message, that turned into an event. So gatekeeper turned that into an event and we triggered a non-compliance on that event. So that's why this policy is now non-compliant. And if I look, you know, sure enough here, I have a Slack message that's alerting me of that non-compliance. And it's given me the same details as before. So that's very similar to the other automation we ran. Yeah, so you did a great summary of the three, right? I also wanted to chime in. I know we keep interrupting us, but I wanted to chime in and say that this is another example. This gatekeeper policy is an example, I would say of software engineering standards, right? So you have such standards in your enterprise and you want to enforce them using ACM. You can do that, right? So whereas what I showed you earlier in the gatekeeper policy was focused on resiliency, right? And then obviously we also showed you security related aspects, like I showed you the certificate expiration one and I showed you the compliance operator one, right? So you can see that ACM covers a breadth of these things, right? And you can basically bring all those into governance and you can now automate it using Ansible. So that's kind of the power of the thing. And the templatized policies actually allows us to scale for foreign use cases, right? That's really why we added that. So just, okay. Jay, as a developer, and I'm not even gonna do an injustice to the strength of developers in this world to pretend that I am one. But if I wanted to be a developer and if I wanted to just put in my willy-nilly code, you wouldn't even let me because you are, as a central IT, you've already defined governance about what I can contribute and commit. Exactly. As a developer, I can't do that. Nice. You got a coverage. Yeah. And that's kind of the value that there's two personas in play here, right? There's Susan the developer and there's Johnny the central IT. And they're working together to create a consistent end-to-end security posture across their environment. They can't get away with just, not putting the appropriate requests in these systems. So I love seeing that, Gus. I think it's awesome when you brought that all together. It really shows the end-to-end story of these central IT fashion. Yeah, I would say, we're not really making the life difficult for developers. What we're trying to do is to give them, instead of, for example, you run an application that consumes a lot of resources and then you get into trouble and then you are called on a weekend to fix the problem. You don't want to get into that situation. We want to define these standards. We want to detect when you're deploying to make sure you're complying to the standards will help you do that, right? I think that's kind of the approach here. You're shifting left. I don't want to make something that's going to cause us to shoot ourselves on the foot. You're informing me, as I'm commuting my code and attempting to run it, you're saying, hey, you can put some guardrails on what you've just created. You could easily crash the entire cluster if you're not careful. Yeah. Exactly. All right. Just real quick to kind of wrap up that little segment on the deployment that gave back an error. I just deployed one that did not give back an error. So this assumes someone figured out what they didn't do. They made the changes and to take a look at the deployment to see what the changes were, they added the resource requests and limits, which is what Gatekeeper was expecting to have provided. So that kind of wraps up that part of the demo. The next thing I wanted to show was just another example of using templates. And that one will be in this particular policy. We won't talk too much about what it does, but the key thing, if I can get it to show up on the screen, which might be a little bit of a challenge to get it all show up well here for you. Let's see. Okay. So I will try to describe another scenario where templates are useful. Here, we're doing the same thing. You see we're pulling data from secrets a lot. We have lots of other things you can do. It's not just about pulling data from a secret, it just so happens we have some useful fields and secrets that we wanna pull out. And in this case, we have a cluster name. So just like I used a cluster name plugged it into the gatekeeper constraint. Here I have a cluster name, which I'm plugging into another policy that happens to deploy, it happens to deploy the ACS secure, I forget the name of it, but the secure cluster service I think. So basically their version of a managed cluster. And that way when you take a look at their console and go into their configuration and look at their clusters, what you see or what you probably can't see very well it says local cluster and Twitch-test. Now, if you remember those two names and I switch over here to clusters and scroll in here, I have two clusters, one called local cluster and one called Twitch-test. So here we have a case where you can make some consistency between different things. So you can have a policy that makes sure as you're deploying operators and different resources across your enterprise, now you can try to make sure you have some consistent naming where ACM likes to use the managed cluster name for managed clusters. Well, you can make sure you have policies that are also using that name. And one last plug for templates here in our... Gus, what you just did is what you just showed just to bring it to a higher level is you basically showed ACM policy that can be used to deploy the sensors on the ACS or the ACS secure services on the managed cluster. And by kind of using the templatization capability you're able to ensure that the name by which ACM knows the cluster as well as ACS knows the cluster is the same. Right, and we haven't actually published a policy that does that yet, but that's the idea of what we wanna do certainly and where we'd wanna go. It is cooking, the policy is still cooking in the kitchen as we speak. Okay, keep going. Here's another one, the same thing. Obviously our community is going to start having some templates and policies. So this is something you wanna be aware of when you start donating to our community or hopefully you start using our community of policies. And but you need to be aware, we're gonna try to make sure we clarify in the policies that this policy uses a template and that means you need to be on ACM 23. Here's one, we're in the process of having donated. You see the same kind of information here inside a URL. So here we have, we talked about the case where a message was getting updated and then we talked about the managed cluster cases. Here's a URL for some audit logging. So it's yet another case where these templates can be useful to help make the policies a little more dynamic and not so static to where you would have to create content that works for everyone or multiple versions of the content, right? Yeah, hey guys, we are almost out of time. So given you are in the policy collection report, do you want to just go quickly to the community folder and kind of show off some of the new contributions that we have had recently? Absolutely. We have had a lot of contributions to our community lately and if we, so we'll mention a few things. We have a blog, our community, our policy collection community points to the blog but there's some more blogs out here. So always take a look at the blog. There's probably always more on the blog than we have listed in our community. We'll try to get the relevant ones in there and try to keep that up to date but we want to plug the blog. Here we have the community folder which is where all of our community policies are donated. So drilling and here we have the policies, we have the policies, everyone that donates the policy, we tell them, you know, try to update this, read me, so we get a nice overview of the different policies that have been contributed. We can highlight the, let's see, there's the advanced cluster security central server was recent and probably all of the ones after it would have been fairly recent. The local storage operator I think was donated, you know, very, very recently, it might have been today. We have samples, so some of them show you just how you could do different things with policies like in this case, how you would use a config map to help provide some different configuration values to your managed clusters that could be used by policies or applications. Labeling managed clusters, here's a policy to deploy a start manager's operator. External secrets, there's a Coverno, there's Red Hat Single Sign-On, there's, you know, Schedule, Integrates Controller. All of these have been very recent, pod disruption budget, I really can't go through all of them, there really have been just too many recently for me to even read often. Ron James, up against the clock, hits the slam dunk. The point is these community contributions do get elevated to stable over time. Help us understand what's important to you, help us understand what we need to bring support to. So join us in the community, have your say. Again, these graduate from community to stable over time. But we might be out of time. I know we have more content, so we do plan to come back to your show if you'll have us. Awesome, oh yeah, always Scott, you always bring it and I love you for it. Thank you again, Chris, thank you Jaya and Gus, you guys are fantastic, thank you for all the good work you do. Yes, thank you very much. Thank you to the audience for watching. We will see y'all tomorrow morning for the level up hour at 9 a.m. Eastern, 1300 UTC. And thank you Gus, Jaya, Scott, as always. Really appreciate y'all coming on. This has been a great show and I will see y'all soon. Cheers buddy, stay safe. You too, thank you.