 Welcome to this quick tour of Red Hat Advanced Cluster Security, or ACS. We'll use the product interface to explore the six major security use cases that ACS provides for OpenShift and Kubernetes applications. The first use case is Vulnerability Management, a foundational security feature required by many regulatory industry compliance standards. As we look through the data in the UI, you'll see an enormous amount of detail on container images and their components. Managing vulnerabilities at the large scale demanded by modern microservice applications is best tackled through shifting left, surfacing issues early, empowering developers and leveraging automation. ACS can integrate these vulnerability results directly into your CI CD tools and processes to engage directly with the application owners. But ACS isn't limited to vulnerability scanning. To assess true security risk, ACS examines the configuration of every deployment and ranks those deployments based on the presence of vulnerabilities, but also in its configuration. Any open network ports, the various privilege levels of processes and service accounts, the use of resources like storage, isolation or exposure on the network, and the runtime activity that occurs in containers in these deployments. The core philosophy of ACS is taking advantage of these OpenShift and Kubernetes native features to increase resilience against attacks, reduce surface area of applications, and hamstring attackers that gain a foothold. Here in the runtime process section, we see the activities of an attacker based on an initial foothold, progressing to using a package manager to install network utilities, and then use those tools to open up a backdoor. ACS's policy engine identifies threat activity, captures event forensics, and can intervene to stop attacks in their entirety. Risk is linked to the flexible policy engine. Here we see the library of some 84 default policies, which you can use as is or clone and modify to suit your needs. Policies identify security risks and can trigger notifications and enforcement. Every policy is designed to provide a broad audience of developers, app owners, and infosec staff with a clear understanding of the reason for the alert and most importantly, guidance on remediation. The network graph shows us a different view of our world, the relationship between deployments on the network. As with container processes, we can use unusual network activity to identify attackers that are attempting to move laterally or to exfiltrate data. To stop attackers, ideally, traffic between the pods will be restricted to only that which is necessary for the application to function. Kubernetes provides a network policy object as a kind of firewall, but these are difficult to build. ACS provides the tooling to generate suggested policies based on observed traffic, making it easy for application owners to reduce risk by native controls to isolate their services. This generate network policy capabilities, what we mean by Kubernetes native, taking advantage of the platform to its fullest security potential. By using built-in network policies, we push the security configuration into the application code, embedding the security in the application, and making it portable across environments. Lastly, the compliance reporting provides us with the overall assessment of how our usage of Kubernetes native controls maps to higher level standards like PCI, HIPAA, and NIST. On OpenShift, we can assess the stance of our infrastructure by leveraging profiles in the OpenShift compliance operator.