 Some of what's going on in the week, if you watched it, the OpenShift product management team went through a whole session on what's new in 4.9 and it's over two hours long so you know this weekend get your PJs and you know grab some popcorn and watch that. So today we're not going to, we don't have time to get into all of that so we're gonna cover a few key areas and Rob's umski helped with this and if you've watched the other OpenShift comments we already did a recording but Rob is online. If you're watching this on the live stream or you're in Hopin right now he's there answering questions and I'm also on the OpenShift product management team. I'm Karina Angel. I know a lot of you but please come say hi during the break. Alright so let's dig into some of this. First thing I want to talk about is how OpenShift is exploding for more than a single cluster use case. Almost all of our customers are running not only one or two but 10, 20, 100 clusters and so you need standardized tools to manage this fleet of OpenShift that's out there. Alright now it comes down to this multi-cluster layer. You need tools to manage your whole cluster, you need tools for the multi-cluster management. You need a container registry to store all your artifacts and your applications and your security and getting your configuration and compliance checks across your fleet and then there's this routing layer. So your global ingress, your egress, your load balancing, your service mesh and then bringing that into the cluster itself and getting encrypted tunnels between all of your clusters so they can talk together and this goes all the way down to the node layer where you're actually interfacing with the hardware. So you're doing hardware offload, your super fast helco type workloads, your GPUs, your other machine learning tools and it's all backed by multi-cluster storage, your backups, your disaster recovery and all your storage needs are met across the entire fleet. So that's the OpenShift ecosystem. Today I want to talk about a couple areas in depth. We have multi-cluster, security, automation and when Christian runs over here from his keynote he has a great demo set up for you. So covering these areas as well. And so for each of these areas we're going to talk about what's going on in the upstream, what's going on right now and then some futures. So let's talk about multi-cluster. Upstream there's two main areas and the multi-cluster arena. First there's open cluster management. Now this is the upstream for advanced cluster management product and this is being bootstrapped right now and donated to the CNCF. So go visit it, join the community and give it a star. So this is simplified fleet management and it's key for managing all of your clusters. There's a bunch of cool things under the hood for cluster provisioning. It's through a project called OpenShift Hive. Now that's another open-source project. It provides a framework for doing governance and compliance tasks. So delivering your policies down to your fleet, auditing your fleets, making sure they're in compliance with the policies and all other kinds of security and compliance needs. Another thing you need to do is actually deploy out to your fleet, your applications. So that's another key part of this project. You can do dynamic place cement and other policies around your applications. So replicated between under the hood it uses projects like Argo CD, which we'll talk more about later, Open Policy Agent, which we'll also talk about more later, and Thanos for metrics and observability. Now another great thing that's happening upstream is all the work with the cluster API. This is a project out of a working group in the Kubernetes community that says it's designed to fill the gaps and tools like for like Kube-ADM. So Kube-ADM is a CLI for bootstrapping Kube clusters. And it turned out to be not as declarative as you need for doing infrastructure as code workflows. So if you want to describe an entire cluster and maybe stamp it out 20, 30, 100 times, you weren't really able to do that with Kube-ADM. So this is going to, this wraps around Kube-ADM and provides a better tool for that. Let's see. So right now in OpenShift for multi-cluster management, a lot of that upstream work is being baked right into OpenShift. First there's a cluster creation in ACM, so Advanced Cluster Management. Today you can boot new clusters that will automatically inherit all the role-based access control governance security policies that you have across your entire fleet. It sees a new cluster shows up, it automatically applies all of that policy. You can also manage the full life cycle of all your OpenShift clusters. So that's software upgrades, scaling out the cluster, managing other things like that. Another really cool feature is cluster pools. So just like we have pools of machines, worker machines, you can have pools of clusters that you can claim. So if you're doing some quality testing and you need a quick cluster, you can go claim it, use it, tear it down, destroy it, all without having to wait for it to be installed. So that's a huge time saver and it's really cool. On the monitoring front, it's really important to have application deployed across your clusters have the big picture. So it's important to know what's going on, how many resources are you using, have I claimed too many resources, am I using too many that are reserved and not actually in use. So we have built-in dashboards for that. See the networking arena. So this is really key. You have a front end that needs to talk to a database on a different cluster or you've scaled out the database across two different clusters and you need to talk to each other. So extending that network in link is also key. The advanced cluster management can help you expand that pod network across the encrypted link. And another really cool thing is all your pod IPs continue to work. So it looks like Kubernetes does on a single cluster, but it's on multiple clusters and it can be a ton of clusters. So that's really cool. And the CNCF Submariner project is the backing technology here. So go check that out too. If you want to dive further in. All right, quick roadmap for multi cluster, some key items. So the new cluster switcher, you can move in the UI. You can move between seeing all your clusters and then dive further into a single cluster if you need to debug or change the configuration. And some other things that are coming out in the ACM world, just continuing to mature and the shared SSO is something that can be very easily configured. Once you have access to all your fleet management tools. So we're looking into that as well as built in default policies for governance and risk. So things like CIS compliance can be built into ACM and the Submariner multi cluster networking that we talked about. And there are test workflows for that right now. So if you want to dive in and go look at that, working on getting that to GA, but definitely if you have feedback, please let us know. All right, that's a really quick overview of the multi cluster world. And of course, if you're online, ask Rob questions, he would love that. Now let's dive into security. All right, pod security. Pod security has been deprecated and it was deprecated. And it's being replaced in Kubernetes 125. Or at least that's the target removal. OpenShift still supports, just want to make sure everybody's still clear, still support security context constraints. So even though we're talking about upstream, just want to, that's not going away. But if you are a partner or your clusters depend on pod security policy, start looking into pod security. The future replacement for pod security policy is much, much simpler. So if you're used to more complex policies, you'll want to look into Open Policy Agent or OPA or Kyverno. So OPA right now is supported in ACM through a plugin. See something else that's going on upstream where it intersects Kubernetes and Linux is the user namespaces. So user namespaces, that's something that works with SC Linux. It protects the container context on the operating system, on the operating system node. So this is an intersection of that. It's actually a CRI, so it's a container runtime interface feature that we already use in OpenShift. But the Kubernetes community is going to plumb that all the way down into Kubernetes. And when that happens, OpenShift will start using it automatically. What that allows you to do is user ID mapping. So if you have root inside your container, it doesn't mean that you have root outside or root on the host. So upstream, this enhancement proposal is still in progress. And so we hope to use that as soon as it lands. We talked about advanced cluster management. And now let's talk about advanced cluster security. I'm sure you've seen all the announcements on ACS. So advanced cluster management and advanced cluster security together with OpenShift. This is a offering called OpenShift Platform Plus, if you've already heard a lot about that. So OpenShift here in the middle, it comes with a mutable operating system. So with all the default security policies and automated operations. But now you have a number of different personas. And so we need additional tools to help out all of them. So starting on the left, starting with advanced cluster security. Say you have your security and your operations folks, your SecOps, if you will. Those folks have a very focused role. They're looking at threats that are happening right now in the cluster. So real time security incidents, as well as automated things like scanning for compliance and vulnerabilities, auditing your network policies. They can do all of that through advanced cluster security and then affect the number of OpenShift clusters across the entire fleet with your standard set of policies. Now, where advanced cluster management comes into play is some of your other personas. You have developers that are deploying applications and they want to store their applications as code and they can deploy all of that through advanced cluster management so that you have exactly what's happening in production at any moment in time. Now your DevOps team might be changing some cluster configuration at the same time. And they want to have that also managed as code through security for security. And so going through the pipeline of changing around some of the default config on the cluster that can happen through that pipeline as well. All orchestrated through advanced cluster management. And then your security folks, they may want to affect some of those same cluster configs. They can do that through advanced cluster management as well as deploy out our quay registry. So developers can scan those things at build time. So one of the cool things is you can scan your containers at build and ACM and then scan it again at runtime as you're going through ACS. Let's look at some of what's happened on our security roadmap. Mentioned compliance a few times. So we have a compliance operator that can do CIS benchmarks and standards like that. We'd like to build that into the OpenShift console. Right now it's available in the ACS UI. So you can already look at that. But we'd like to expand that even further. And if you've been tracking JetStack's StartManager project, it's a really popular tool for generating certificates for web applications. We are productizing that and bringing that into OpenShift and we're doing it in a unique way. It's going to be automated certificate management for all the users in your cluster, but it's going to do something kind of interesting. Where you can issue certs from a number of different places. So you can issue certs from the internal cluster CA, which is what OpenShift uses right now. Or you can do it from your Hashicort vault or Let's Encrypt. Let's Encrypt is more for web applications. So it's one of the traditional use cases for cert management. Now from those two you can actually issue certs to a number of different places. And probably the main thing is going to be developer applications. And those are running on your cluster, but they can be used for operators that are installed on your cluster. And if you have operators doing webhooks, if you need certificates from them, they can also, you can roll those through this project as well as other Red Hat products like middleware. OpenShift sandbox containers. So this right now is available in tech preview for 4.9. So that we're working towards GA that and if you have feedback on your sandbox containers can reach out. And this lets you run your third party or your untrusted code. And it's designed for your applications that are cloud-native. So they're already in your containers and they need a little bit of extra isolation and you wrap all of that in this extra kernel. So it's just a bit safer. And we hope to get that FIPS certified by the second half of next year. And FIPS, sure we all know, but it's a U.S. government standard. Security standard. Alright and last, username spaces. We talked about this already, but once this lands upstream, we want to bring it out of blocks into OpenShift. So for all the applications that are running in OpenShift. And this is especially helpful for OpenShift builds. And if you want to use the Quay registry, by design, they are third party untrusted code and or just by nature, we want to protect those as much as possible. So further focus on security. Alright, that is what we have for security. Let's talk about automation. Alright, we talked about platform level and management level automation earlier. What's also being driven across OpenShift is workload and development automation and standardization of how your applications are delivered automatically through your workflows. Now there's a lot of innovation that is happening upstream. It's not on the slide, but what I really want to mention is the GitOps working group where Christian is right now. I haven't seen a few, ah there he is, thanks. So Christian was just there, but the GitOps working group is a very active community and just kind of exemplifies what upstream is. And just multiple companies coming together to focus on GitOps and anyway I want to mention and that's through the application delivery technical advisory group. So if you want to get involved, go join that. So Argo CD is one of the most popular projects in this area and that's the upstream for OpenShift GitOps. And Argo right now, I mean there's continual support for Helm customize other tools that are really popular and consolidating those features into the user interface. Previously and still now there's all the different interfaces that you have to switch between and now they're being consolidated. So another thing, so for example, since Customize 4.2 has been pulled in, now you can specify that Helm should include CRDs when inflating a chart, so that's cool. Argo CD has also moved to project scope repositories and clusters and what this means is that it makes it easier for developers to continue working without having to reach out to your cluster admin or needing your global configs. And another key enhancement I didn't put it on here is the application, application sets that's part of Argo CD. I know Christian is very excited about application sets. So and with applications that you can create, modify and manage multiple applications through your templated automation. So previously you can only do that through a single repo or namespace. All right, Tecton. Tecton is the upstream for OpenShift Pipelines. It's continuing to gain maturity with Pipeline as code. Teams can configure your builds, your tasks and deployment and code that's trackable and stored in the central repo. And with this continued focus on DevPsychOps, so security running theme. So there's support for your rootless images and your experimental hermetic execution mode. So that removes the networking so that you can go ahead and test it without worrying about, it just isolates it more and makes it more secure. One last note on Tecton, they're also doing a lot of work on advanced error handling and making it easier to debug your pipelines if something happens. So again, that maturity for the project. Cata. Cata is really interesting. So this is Kubernetes event driven autoscaling. So that's what Cata stands for. This is event aware autoscaling. So currently with autoscaling with your HPA, it's focused on CPU memory. However, Cata has this concept of scalers. And what this means is that now you have different triggers such as that you can set up such as a SQL query. So that's cool. Or a stream or how many messages you have in your queue. So you have these different triggers that you can set up to scale your application. Also exposing your cloud events. So cloud events. This is it's a specification out of the serverless working group. So that's another CNC up working group. And that allows you to set up. It's a specification defining a common standard for common format for your event data. So that's really helpful in creating all the scalers. So there's a lot of work being done there. Cata is being productized into OpenShift and that's going to not land for a little bit. But we're doing a lot of work upstream on that as well. Alright, Knative. Make sure we have time for Christian's awesome demo. Knative is the upstream for OpenShift serverless. And the Knative OpenShift serverless team really drives a lot of work upstream. So there's so much going on. So Knative functions. The OpenShift serverless team donated the all the work being done on functions to Knative. And to the Knative sandbox. They're also driving a creation of a functions working group. So if you're interested in serverless functions, go get involved upstream. And also they're putting a lot of effort into there's a function repository directory that has all kinds of run times and templates. And then let's see. Apache Kafka. The eventing team has done a lot of integration work with Apache Kafka upstream. So there's so much going on integrating those as well. And for serving, I've talked earlier about the end to end encryption. So driving a lot of work upstream on encrypting all hops through your cluster. There's a lot of cold start improvements too. So alright, so what's happening right now? Again, I want to talk about so workload automation as well as cluster automation. Workload automation. All that work being done upstream for your GitOps and your pipelines, that's all coming downstream. Also integration work with advanced cluster management. And a lot of off cluster automation. So more integration with Ansible. Also talked about the scaling. Dynamic scaling of using Kata is the backing technology. And under the covers it uses the horizontal pod autoscaler. So puts a wrap around that and by default the pod autoscaler uses CPU and memory utilization to autoscale. And Kata just expands on that. Cluster automation. Alright, we talked about multi cluster management. Just want to highlight all the different areas where automation is being driven across the platform. So automation through advanced cluster management to manage your entire fleet through ACM. And right now definitely want to highlight you can manage up to a thousand clusters in a single hub. And that's just amazing. That's a lot of clusters. So started this by saying that we see that a lot of customers are using 10, 20, 100, it's even up to a thousand. So and even more they're testing further from that. Want to also highlight that by design OpenShift 4 is designed to automate all your operations. And operators themselves are designed to automate your workloads, your day to operations. Alright, automation roadmap and then we can get to Christian's amazing demo. No pressure though. Yeah. Some highlights on the automation roadmap. Alright. Again, continuing to build on all the work being done upstream for tecton and get ups or go see in tecton. Alright, and integrating further with tecton hub so it's easier to pull the workloads in or the workflows in from tecton. Hub and a lot more pipelines as code use cases. Something really exciting will be the GA of OpenShift builds V2 and build packs for pipelines. So move in from OpenShift builds to V2. And of course the sandbox containers and pipelines. So there's so much happening and so much that's going to land. Exciting times. Serverless. Again, that Cata integration talked about Cata before and that will be probably more in the looking at 411 and beyond time frame to bring that into OpenShift serverless but it's on the horizon and that'll be Cata complement each other so that'll be great bringing that into OpenShift serverless. Advanced cluster management. So I mentioned a thousand clusters they're going to be doing even more testing and improving the performance and scale of managing across the entire fleet. There's so much more I could say but I want to make sure we have time for your demo. So we talked about multi-cluster, the multi-cluster layer and each of the layers and Christian if you want to come show us what you have prepared. Let's go. Can we switch up? Yeah. You guys have a monitor here so this is really cool. By the way this is the first time I've seen this in any conference so let me quickly set up here because I actually want to mirror my desktop and hopefully this doesn't cause a kernel panic. Should I make it a little bigger? Maybe just a scotch. Okay there we go. So actually by the way it's great to see everyone here. It's a little awkward to be back at conferences after so long not being at conferences and seeing everyone in 3D is actually really cool. It's a little weird where I guess we'll get over the awkwardness as the week goes and it'll be really cool. Actually a quick shout out to Grish, Grish is someone I've worked at for a long time. It demos sort of halfway inspired by some of the talks he's had with his customers where we talk about how OpenShift, ACS, ACM, it's all better together. So I'm kind of go through a workflow to talk a little bit about how you can integrate ACS and all its functionalities into OpenShift and into ACM and into pipelines to kind of just see how you can have that security integrated all in. So here I have ACM, so Advanced Cluster Manager. I was supposed to say Red Hat Advanced Cluster Manager sorry. And so here I have a list of my clusters. Again it has like if you worked with ACM before you should see that there is my local cluster. I keep forgetting how to monitor but I'm so used to looking this way. As you can see I have the local, this is the whole local hub cluster. There's a little test cluster here. This is actually what I really think is really cool about ACM is that this actually test cluster is in my home lab. I'm behind a firewall and ACM is still managing it. So for those who have like things like disconnected clusters or their gap clusters, ACM can still work in a model where you can still have that secured. So this is literally, it's a server sitting under my desk. But I'm also managing this cluster called Cluster2. And I can from here it gives me certain information about the cluster. You know what version that there's an upgrade available that there's nine nodes in this cluster. It's actually pretty big because you'll see why in a second. Looks like there's an issue being identified here. That wasn't there yesterday so I won't click on that. And then you can actually go to the cluster here itself. And this is OpenShift, one of the managed clusters here. There we go. And part of this installation is that I'm actually running ACS. So just like anything with OpenShift, just like the entry point for anything in OpenShift is the operator hub. You go to the operator hub, it's there. So this is advanced cluster manager. I've already pre-installed it, pre-set it up here. And I kind of want to go through just a little bit about ACS in general. So see here, this is a dashboard at first glance. You can see that I have some system violations. I have zero critical. I have 165 high. I have all of these at a glance. I can see what's going on here. I can see my top riskiest deployment. And you have to kind of keep in mind with security, especially with ACS, this is all relative. So risky, it just means relative to what it finds. So since I have zero critical, risky doesn't necessarily mean critical. It just means these are the top offenders of what you have here. And it shows you the list of those deployments. I like to take a look. This is my favorite page, by the way, of ACS. When I first started working with ACS, I'm like, I wish I had this back in OpenShift 3 and OpenShift 2. I'm like, seriously, right? So here you can see the top violation is that someone accessed a secret. This secret just happens to have the QBadmin password. So it raised that as a violation. Right now it's set up just to note it. You can set it to either block it, or you can set it to fire off alert to page of duty. Hey, someone accessed the secret. It accessed it multiple times. This is not a big deal because it was me accessing the secret. But this is actually really cool. This is probably one of my favorite things. I wish I had a way to just notify me when someone's accessing something in my cluster. Some of the vulnerability management here. Yeah, there we go. So this gives you an information of the top riskiest deployments, right? So here there is an application called price list that Jason, I don't know if he's around. He helped me build it a long, long time ago and he made fun of me because I misspelled purse list when I first built it. But anyway, this tells me the image that I got scanned. There is the top riskiest components here. It tells you which CVE and whether it's fixable or not. So basically you can have information that tells you, hey, you need to rebuild this image. You need to make sure this image is updated. You can go back to your developers and say, hey, we found these vulnerabilities. We're not going to deploy this out. It could be as simple as, here there are a bunch of RPMs, so it's just as simple as a DNF update on the image. But this is like my top riskiest one because I think I built this like two years ago. I'm not sure. One last thing is the network diagram, which I also really, really like as well. You can see the network flows. For example, here I want to choose, okay dude. So this shows the network flows. It shows what is connecting to what here. There's an ingress network flow. You can do things like list network policies and you can actually do things like assimilate a network policy. So you can see what's going to block what without it actually doing it. And you can actually do that workflow here. So you can actually see at a glance how everything is connected to everything else and what is allowing access to what. Let me bring back that page. This one right here, it says these workflows here, it's kind of anomalous. Why? Because it's wide open to everyone. So the Stack Rocks right away tells you that, hey, this traffic is wide open to everyone and you may want to take a look at it. And then you can simulate again in the network policy simulator. So this is all great. This is all great tool for an admin, great tool for security practitioners or having containerized workloads coming in. But really what I want to show is that how you can integrate it in your pipelines. So Karina was talking about Argo and Tecton, that's kind of like the world I'm in right now. Here I have an application that's deployed with Argo CD. Oh, by the way, if I go back to ACS, actually ACS sees that it's an Argo application. So it actually, there's that integration there. So just really quick, but back to the demo app. So there's a demo application here that is built using pipelines and deployed using Argo CD. If I go to the, here we go, the pipelines here. So I have a pipeline here, this pipeline built that application and deployed that application. But part of the building process I have integrated with ACS to where it'll run the security checks while it's building. And it'll either block or it'll allow the build to continue fully to deployment run. As you see here, I built it initially, it went through. I've added a few more security checks to the ACS integration, right? So we, because we want to see it fail, right? So let's start this build process. So this build process kind of kicks off. It takes a little bit because if you've worked with pipelines that actually goes and grabs a persistent volume first as a workspace. So you can use it as a workspace and do the git cloning right here. So there is a, there's a git clone that happens. There's a deployment check, meaning there's that security scan that happens using ACS. And then the deployment happens afterwards. So let me put the logs here. So this takes a little bit, there it goes. So it does the git clone. And as you can see here, let me see if I can expand this, make it a little bigger. We do all this with UIs and in the end we just like terminals, right? So here, as you can see, it went by really quick. Looks like I have a bunch of violations. The initial violation, I guess for my name space, there was no violations because that's all that was sent in the initial run. And it looks like I have some CVEs that I need to fix. So there's like the version of curl, the version of busybox, right? And various other violations. So it sets the overall status to fail. So once it fails, here I go back to the details page, I go back to the pipelines runs. It didn't actually finish and it didn't actually deploy. It stopped, right? It stopped short of deploying the application. As you see here, it's still on that same version. And this is how you can use ACS within your pipelines to kind of stop this at the source, right? Just like literally, we're talking about the Git clone. Does a scan, it could do an image scan. It can do policy scans from your YAML file, right? So like if you're doing a GitOps workflow and you're storing your YAML and Git, it can actually scan those and make sure it's to compliance, right? So compliance meaning whatever you set, the real sets that you set for your environment. So that's the, I think I'm almost out of time. Yeah, good timing. So that's it from a high level that you can show how you can not only use ACM to deploy multiple clusters, but you can also use ACS to manage the policies on those clusters. And then also integrate your pipelines from a developer standpoint, from a developer workflow. Developers can then be notified early and often when a violation exists or whether they need to update, not have it further down, right? You don't want that further down in your process where you're delaying a deployment of your application because there's security violation and they have to rebuild and redo the whole process. You scan that early and often and be alerted early and often and have it fully integrated into one platform. So yeah, with that, thank you very much. I'm not sure who's up next. Stu is coming in. Yep. Thank you. Thanks, Christian.