 Hello, everyone. Welcome to the Red Hat Advanced Cluster Security Roadmap session. I'm joined today by the Red Hat ACS product management team. I'm Kirsten Newcomer. I'm also joined with Jamie Scott, Theron Kaspen, Shubha Bhaddi and Norma Singh Kaur. Our agenda today, we're here to talk to you about, we're going to introduce Red Hat ACS in case you're not familiar. We'll share our vision for managing Kubernetes and container security. We'll also share a little bit about what we've done recently in Red Hat ACS, and finally spend most of our time talking about the roadmap, priorities, near term and longer term. Jamie, please take it away. Thanks, Kirsten. So over the last few years, we've seen a trend. Teams need to do more with less. And what that's really resulted in is Kubernetes becoming the standard for application innovation. Teams are delivering microservices. They're working toward declarative architecture and they're working toward immutable infrastructure. And what that's really resulted in is Kubernetes adoption, hockey sticking and cloud services becoming part of the standard of innovation. And as Kubernetes and cloud services become more and more important to the industry, Kubernetes native security has become increasingly critical. And that's what ACS does today. ACS helps you to secure your supply chain, secure infrastructure and secure workloads, as teams look to develop a more developer centric in DevSecOps operating model for application delivery. Next slide. So we've asked ourselves these questions and we've talked to many customers and we found that successful security programs really come with a few key attributes. Teams want faster time to resolution. Vulnerabilities and security misconfigurations are ultimately an expense center for the organization. And in order to reduce the cost of that expense center, people need faster time to resolution of issues. They also need to break cross functional barriers within the organization. Security teams, development teams and platform SREs all generally speak a different language. And teams need to bridge that cross functional barrier in order to be more successful in their collaboration. And finally, there's a large skill gap in the industry and a large context gap. Developers and security people, it's unreasonable to expect them to know everything. A developer needs to stay on top of technology, but that can't know the ins and outs of security. And meanwhile, it's not reasonable to expect a security person or security engineer to know every technology. So there's a skill and context gap that as organizations scale needs to be bridge. So how do we do this? Well, in order to deliver value beyond protection, we need to solve these three problems. And first is faster time to resolution. In order to do that, we need more effective prioritization workflows. We need to create feedback loops early and often between development teams. And we need to improve data quality and remediation guidance in order to help developers fix issues as effectively as possible. We need to break cross functional barriers. To do that, we need to provide guidance to teams and the tools that they use every day. We can't expect developers to shift out of their workspace into a security tool. And we can't expect security teams to shift into different tool sets. They needed this information and they needed in a common workspace that they log into every day. We also need to enable collaboration between these stakeholders. That means we need to create a common language for each of them. And that common language for Kubernetes is different for each organization. We need to break that skill, that barrier of language. Finally, we need to design security enforcements to minimize outages in a way that developers can design around in order for a security enforcement action, never to actually break an application, because that ultimately will result in a business impact and financial loss of an outage. So finally, we need to really address the skill and context gap within our industry. And in order to do that, we need to simplify the adoption of security practices with standard patterns for developers and security teams that provide guardrails for each organization. We need to mature incident response capabilities without of the box policies, and we need to enable each and every team to make more informed risk management decisions with contextual data in order to help them facilitate those decisions. Next slide. So how does it Red Hat Advanced Cluster Security help you do this today? First, we help you with vulnerability management. We scan your images for known vulnerabilities, and we help you to enforce policies based in your CI workflows in order to ensure that vulnerabilities are managed appropriately for organizational policy. We need to help teams with configuration management, and that's what Red Hat Advanced Cluster Security does. We identify configuration risk ranging from common misconfigurations to even to the ability to look at Kubernetes RBAC. And we help developers look for misconfigurations in their deployment handles in order to help facilitate and accelerate their security checks throughout their organization. We also help teams with compliance and network segmentation. We help compliance teams to align with industry standard frameworks and give them insight into their compliance posture. And we also allow teams to audit and recommend network policies in order to help facilitate network segmentation across the industry. One of our core use cases is risk profiling. That enables teams to focus on the most risky deployments in their environment so that they can focus their energy on tasks that would have an outsized impact on their security posture overall. And finally, there would be no security tool if it didn't have runtime detection response. So we help teams to identify deviations from known good activity and to alert on known bad activity such as crypto mining services in order to really help them get a pane of glass into the real-time threats of their organization. Next slide. So how do we want to involve Kubernetes security over time? So we've done that recently by helping developers admins and notification feedback loops. So for developers, we've streamlined risk management processes by enabling teams to look at false positive risk and look at accepted risk and make these decisions of this is a false positive or this is an accepted risk directly into their CI workflows. We've also simplified issue prioritization by bubbling up the most important issues directly in CI so that developers know what to focus on instantly without having to triage through a lot of alerts. For administrators, we've reduced set of cost. We've done that by a simplifying administration of OpenShift platform plus to ensure that these teams don't have to set up multiple identity providers by using OpenShift OAuth. We also help teams to scale their integration with multiple elastic container registries across multiple accounts by supporting assume role using AWS STS in order to ensure that teams can have a central pattern for authenticating into elastic container registry at scale. And finally, we've shortened our feedback loops greatly. We've done that by scheduling remediation at tasks for vulnerabilities to the appropriate team in a way that can continuously inform users of the most important risks in their environment. And we've also helped machines and notification workflows for incident responders by giving them additional context for runtime notification enhancements by giving their SIM the information that it needs in order to make more informed risk management decisions when someone's manually triaging an alert. Next slide. So we want to go through our team and go through each of the key priorities for Red Hat Advanced Cluster Security. These key priorities are security innovation, cloud services, portfolio integration, and open source. So let's talk a bit about security innovation and Shubhan and Boaz will do just that. First, for SecOps persona. Security posture KPIs are incredibly important. The security individual has about five minutes to go to each of their key stakeholders and inform them what will have an outsized impact on their security posture. They only have a limited amount of time. So we want to bubble up the most important KPIs and show the trends over time so that they can have that conversation, but also go to their board of directors and say, this is the return on investment you've had in your Kubernetes security program. We also want to help teams to identify inactive software components. At runtime, a streamlined remediation workflow can be achieved simply by removing software packages. If a software package isn't used by a runtime process, that means that teams can simply remove that software package to systematically harden their environment, but also to systematically reduce the cost of their vulnerability management program, because they'll never have to go back and triage an alert to patch in a vulnerable package that no longer exists. We're also looking to enhance how we do host vulnerability scanning. We're going to do that by extending vulnerability scanning to more host operating systems and provide a consolidated view of known vulnerabilities across your cluster so that you can extend beyond workloads to a holistic Kubernetes security posture vulnerability management system. And finally, we're looking at image signatures and how image signatures and supply chain play a role in to a security persona. And by validating image signatures, we can help to validate providence of the actual images that are being used to help secure your supply chain more effectively. Next slide. So another bit of feedback that we continuously get is policy management. Policy management is key for every member of the organization. So we want to help teams to scale that policy management. We're looking at investing in reusable policy resource scopes in order to help you scale that so that resource scopes can be easily auditable. But also different policies can be applied to different scopes of resources, whether that be between test and production environments or between multiple tenants and teams within your organization. We're also looking to help developers and platform SREs more effectively scale policy management and collaborate more effectively with the security team. We're doing that by looking at GitOps policy management and providing more intuitive ways and patterns through custom resources in order to scale policy management. We also recognize the value of community and Open Policy Agent has really become a key community contributor in the Kubernetes space. So we're looking to see ways that we can abstract Open Policy Agent, we go, and use our drag and drop policy interface so that we can bridge the skill gap, but also collaborate with the community in order to work to ensure that teams have who already have invested in Open Policy Agent can easily use those and drag and drop them between as they transition to Red Hat Advanced Cluster Security, but also so that Red Hat Advanced Cluster Security can contribute back to that community. And finally, we're looking to enhance our policy management workflows by streamlining that workflow for creation of policies and risks and editing workflows within our policy management system. And I want to hand over to Shuba to ensure that talk about workload vulnerabilities and our investments there. Thank you, Jamie. Now switching gears to vulnerability management, I think we all can agree that vulnerability management is a crucial and an integrated part of DevSecOps. Keeping that in mind, we're constantly innovating in this space and making the ACS features it more rich. One such feature we would like to introduce this year is local image scanning for our developers. In line with industry's shift-left approach to security, we want to enable developers to scan their images on their local systems so that they can eliminate vulnerabilities faster and earlier in the development process. We intend to have a version of ACS scanner that they can install on their local system for local image scanning. The results will be stored locally and then sent to an ACS deployment for vulnerability matching. We are also looking to enhance in the area of ACS registry integration. With the upcoming release of ACS 3.69, ACS now will be able to scan images which are hosted in internal image registry for OpenShift. As you know, OpenShift internal image registry is only accessible from within the OpenShift cluster and there is no external access to it. We are also looking to enhance registry integration with ACR. We want to automate the registry integration process for Amazon Plastic Container Registry for those of you who use AWS. By doing so, we want to improve the scalability as well as achieve a seamless integration. We also want to enhance the remediation guidance to our developers by providing them additional information to triage detected vulnerabilities. For example, if a package is detected vulnerable, we want to be able to tell to the developer whether that package comes from the base image layer or does it come from the application layer. If it comes from the base image layer, the developers can look at the team who maintains those standardized base images for remediation. But however, if the package is in the application layer, then the responsibility for remediation falls on the active teams. And that's all I have. Handing it back to Boaz. Thanks, Juba. The next areas of security innovation are compliance and network policy management. Meeting security and regulatory compliance requirements is a key use case for Red Hat ACS customers. Red Hat Advanced Cluster Security includes out-of-the-box compliance policies for workloads and Kubernetes, and it iterates with the OpenShift compliance operator to extend compliance assessments throughout the stack. We plan to introduce a brand new graphical seamless user experience that better combines the two sets of capabilities. Users will be able to schedule compliance operator scans using an ACS intuitive wizard. Users will be able to customize compliance profiles to meet local and individual regulation needs. And for a better streamlined workflow, the product will present both infrastructure and workload scan results in the same view. Red Hat ACS already provides some compliance scans for EKS, AKS, and GKE, including CIS Docker, PCI DSS, and HIPAA. We will be extending those capabilities by supporting the compliance operator on these three additional Kubernetes distributions, starting with EKS. We will also deliver a profile for the CIS benchmark for Amazon Elastic Kubernetes Service, or EKS clusters. Kubernetes network policies are vital in helping to enable zero trust networking within a Kubernetes cluster. They reduce the impact of network attacks by limiting the opportunity for lateral movement. Applying network policies is a recommended best practice, as is also included in the Kubernetes Hardening Guide published by NSA CISA. Yet, most organizations find it challenging to implement Kubernetes network policies unless they are Kubernetes experts. Red Hat ACS already helps by providing visualizations of pod-to-pod communications and by providing automated recommendations for tightening network policies. This is particularly useful in providing visibility to network security teams. We are continuing to invest in this space to help organizations take advantage of this important technology. First, we plan to ship an ACS policy that will check for proper existence of network policies across all nameshaces. Second, we want to make it easier for users to get started by leveraging a recommended network policy. We plan to complement the runtime live traffic analysis available today with an analysis of declarative resources that can be done prior to development. This will allow developers to benefit from these recommendations during the development stage and to try out recommended network policies during testing. Third, we're planning to add an intuitive point-and-click visual editor side-by-side with YAML editor, allowing users to select, allow and block connections with no need to understand the underlying YAML code. At the same time, this offers an opportunity for developers to get acquainted with network policy YAML when they're interested. Combined, these steps help organizations to shift security left and more easily define, deploy and manage Kubernetes network policies in a collaborative fashion. We're also planning several improvements to the network graph. First, to support large-scale deployments with hundreds of clusters and thousands of applications, users will be able to limit the scope to namespaces they care about and visualize connections relevant to those namespaces only. Next, we're planning to further enhance the user experience by helping users quickly identify problem areas and drill down to isolate and remediate issues. As part of that, we're planning to add visibility of additional information associated with network connections such as which processes listening on what port. And with that, over to you, Dron. Thanks, Boz. So let's talk about cloud services. This year is marked as a year for cloud services in Red Hat. And it's all part of transferring IT services and establish a cloud strategy for the company. The COVID pandemic established the cloud as a strategic tool for providing agile platform to develop solution faster with no capital expansion for the IT infrastructure. The journey to the cloud is even more important for business today as it faced unpredictable operation impact of the pandemic. Based on that, Red Hat decided that we want this year and next years to invest in managed services. And ACS managed services is part of it. So ACS managed services will provide the capability to launch the product, the ACS product, advanced cluster security product within minutes. So you sign up online, you can pay online, you can use any marketplace to buy ACS. And in within minutes, you will have an environment that you can use to protect your Kubernetes environment. With security and resiliency that meet your requirement, the regulatory requirement. ACS cloud services will allow you to start protecting the Kubernetes deployment within minutes. With building Kubernetes native security features that provide insight into critical vulnerabilities and fat vectors, but all the other features that was described earlier by my colleagues. With flexible consumption option, customer will be able to use a pay-as-you-will model or use their committed spend to buy ACS on managed services on Red Hat marketplace, AWS marketplace, and Azure marketplace. Back to Kristin. Thanks so much, Daron. So for those of you who are using Red Hat ACS with OpenShift, we wanted to share a little bit of information about more things that we'll be doing to improve the portfolio, the integration with OpenShift. As noted earlier, of course, you can use ACS with EKS, GKE, or AKS, and we're really looking forward to the as-a-service offering, also making it easier for those of you using those Goob platforms to take advantage of Red Hat ACS. So OpenShift platform plus is an option available to our OpenShift customers. Those of you using OpenShift, you can get OpenShift plus advanced cluster security, advanced cluster management, and Red Hat Quay for your global registry. So when we talk about the portfolio integration, these are the areas of integration that we're looking at. Shuba mentioned earlier that we are actively working or will be releasing soon the ability to scan the OpenShift local registry. We're also working to integrate the experience that our end users have, our customers have, when they're working with both advanced cluster security and advanced cluster management. We anticipate providing a security perspective in the OpenShift console. Jamie mentioned the ability already available to reuse the OpenShift OAuth providers, same identity provider across OpenShift and ACM and ACS. We'll be expanding that to have a UI for ACM and ACS with a security perspective right in the console so that you can see all your compliance policies and postures across the fleet. Similarly, we'll be exploring what we can do for visibility and management of cross cluster networking. Multi-cluster mesh support is on the OpenShift roadmap, and this is a place where ACS will expand its security capabilities as well around network security. And then finally, we're also looking to consolidate the ACS scanner and the Clair scanner so that you have a common experience across ACS and Clair. Next, we wanted to talk a little bit about community projects. By the time you see this, we will likely have announced that StackRocks code is fully open source. The upstream project for StackRocks is in fact StackRocks.io. We'll be putting a lot of energy into that community, looking forward to community support and interaction across our colleagues who care about container and Kubernetes security in the open source community. Again, we'll be consolidating our scanning capabilities into the Clair open source project. Jamie, we will also be focusing on providing more capabilities in the KubeLinter project. This KubeLinter open source project is available to you to use today to analyze Helm charts for access privilege, things like that. We'll be extending the capabilities of that project to Kubernetes operators. Similarly, we're already collaborating with the CNCF Velco project and we'll continue to do additional open source contributions there from the Red Hat ACS code base. Finally, we just have kind of a quick ACS roadmap at a glance just to give you that one-shot overview. And with that, we wanted to say thank you. There's information here about how you can find more information from Red Hat and we look forward to talking with you again.