Advanced Cluster Security (ACS) 5

ACS 5 extends vulnerability scanning to virtual machines running on OpenShift Virtualization. A roxagent service inside the guest reports installed packages to Sensor over VSOCK, so you get unified CVE visibility across containers and VMs from a single ACS console.

In this exercise you will verify a prebuilt RHEL VM, review its findings in ACS, and optionally onboard a second VM.

Before you verify the prebuilt VM, review what RHACS requires to scan OpenShift Virtualization workloads. These conditions are already met in this lab for rhel9-vm.

For full product details, see the Scanning virtual machines topic in the RHACS 4.11 Operating guide.

RHACS collects, processes, and analyzes VM package data with these components:

OpenShift Virtualization and RHACS must meet the following requirements in your environment:

Each VM to be scanned must meet the following requirements:

You should see rhel9-vm in a Running phase. You can also confirm in the OpenShift console under Virtualization > VirtualMachines.

In this optional path you deploy a second VirtualMachine from a declarative GitOps-style manifest, then confirm ACS scans it alongside rhel9-vm.

File Activity Monitoring watches file access, modification, and rename operations on paths you define, including wildcards, and can combine those events with process context. That gives runtime visibility that image scanning alone cannot provide, and it supports compliance controls such as PCI-DSS.

In this exercise you will confirm FAM is enabled, review the lab policies, and trigger a deployment-scoped violation.

Before you trigger a violation, review what RHACS requires for file activity monitoring. These conditions are already met in this lab.

For full product details, see the Configuring file activity monitoring topic in the RHACS 4.11 Operating guide.

RHACS and the secured cluster must meet the following requirements:

First, confirm FAM is enabled on the SecuredCluster:

You should see the SecuredCluster name and Enabled.

With FAM enabled, this environment contains two SecurityPolicy resources deployed via GitOps:

Review the policies in ACS Central:

Use this path if you want to exercise host-level file activity. Node FAM alerts appear on the Violations page in the RHACS portal, and are also available through the API and notifiers.

The ACS MCP server exposes Vulnerability Management and Configuration Management APIs as MCP tools. AI agents, including OpenShift Lightspeed, can query CVEs, images, deployments, nodes, and secured clusters in natural language instead of clicking through Central page by page.

In this exercise you will verify the preinstalled MCP endpoint and query ACS data through Lightspeed.

The ACS MCP server is based on stackrox-mcp (same approach as the RHACS demo mcp-server-setup). It exposes RHACS Central data to MCP-compatible clients through toolsets such as:

Use this path if you want to connect Claude Code, Cursor, or Claude Desktop the way the RHACS demo documents.

This exercise will walk you through and demonstrate the capabilities in OCP5 and RHACS (5) for the scanning of Init Containers.

Init Containers are standalone containers executed as part of a Kubernetes deployment. They occur before the actual Pods of the deployment are created, and are used to perform various initialisation tasks needed by the Pod, namely operations like file initialisation, DB population and the like.

As such they are an attack vector for exploitation; RHACS now has capabilities for scanning and acting upon exploits.

Unlike Pods, Init Containers are not resident; once executed they are removed, so the runtime policies offered by RHACS focus on process execution and baseline comparisons.

For this exercise we will be using the built-in terminal on the right, the OCP console, and the RHACS interface.

In the OpenShift Lightspeed dialog, enter the following:

The MCP server requires approval, so approve when it asks you.

On the left hand navigation, choose 'Projects' and then rhacs-init-container-test. All of the examples will be executed in this project to allow you to observe the results simply in the ACS console.

In the built-in terminal on the right, run:

Check the project has no workloads using:

In the terminal, run:

This allows Pods, and Init Containers, to switch to Privileged to perform actions.

For the sake of testing we have four specific use-cases represented by different Deployment definitions, each designed to highlight a behaviour now offered within RHACS for the monitoring and actioning of Init Containers. These are:

In the terminal, run:

In the terminal, run:

We will now apply two additional policies specific to this namespace only; in the terminal, run:

While in the terminal, have a look at these two policy definitions. Specifically, for privileged-init-container.yaml note:

And for fixable-important-cve.yaml:

Switch to the RHACS console; select the resources pulldown and click on 'local-cluster' as shown below:

Now click on 'All Namespaces' and select 'rhacs-init-container-test'. There should be no violations (we have no workloads yet).

In the terminal, run:

Switch to the RHACS console. Make sure the 'Resources' is set to 'local-cluster', and select 'rhacs-init-container-test' in the Namespace pulldown.

You should see the dashboard which shows 1 low policy violation; if you examine the 'Active images at most risk' you will see two images displayed. Note that one of the images is 'distroless/base-debian12'.

Switch to the 'Violations' content page. This is a more concise summary of issues, and can be used interchangeably with the Dashboard, based on your preferences.

Switch back to the OpenShift interface. Click on Workloads and then Deployments. Click on the clean-app deployment. Click on Yaml.

Note the definition of the init-container; RHACS has detected and scanned this init-container correctly, and found no issues.

In the terminal, run:

Once the Application has deployed, click on Workloads and Topology. Click on the dirty-app roundel, then click on the Pod name displayed in the right-hand content window.

In the Pod content panel, click on Logs, then click on the pulldown for the Containers; select dirty-init

The log will indicate that the init-container is well-behaved, but it based on image with known CVEs.

Switch to the RHACS console; you should still be on the Dashboard, with the namespace rhacs-init-container-test selected. Refresh the page.

You will now see that RHACS has scanned the init-container as part of the deployment process, and discovered two High violations. Click directly on the 'High' panel.

The following overview specific to the violation detections in the init-container of the deployment will be rendered:

In the terminal, run:

Once this has succeeded, click on Workloads, Topology and make sure the Deployment has been successful (there will be a blue border around the blue-app roundel). As before, click on the blue-app Deployment, then the Pod name, and on the Pod content page examine the logs for the blue-init container (follow the instructions above to select the logs/appropriate container).

Switch to the RHACS interface. Click on Dashboard (or Violations if you wish), select the local-cluster, and then the namespace rhacs-init-container-test as before.

The last scenario is to create a Deployment that behaves as with the blue deployment but performs a prohibited task. For this scenario we will add a specific policy and behaviour for our test namespace.

In the terminal, run:

Once the deployment has completed, click Workloads, Topology, then the roundel for red-app. Click on the running Pod, select the Logs content pane and examine the log output from the red-init container. It should read:

Switch to the RHACS console again. On the Dashboard, assuming you have selected local-cluster and the namespace rhacs-init-container-test you should now see this:

Organizations upgrading from ACS 4.x may want to preserve the previous behavior where init containers were not evaluated by certain policies. ACS provides a utility script that adds a "skip init containers" filter to existing policies, letting you selectively opt out of init container evaluation on a per-policy basis.

The script is interactive — for each eligible policy it prompts you to apply the skip filter, skip it, or apply to all remaining policies. It automatically skips policies that already have evaluation filters, build-only policies, declarative (CRD-managed) policies, and audit/node event policies.

First, generate an API token and set the required environment variables:

Then run the script from the ea5-components directory you cloned earlier:

The script will list all eligible policies and prompt you for each one. Answer yes to add the skip filter, no to leave it unchanged, or all to update all remaining policies without further prompts.

After running the script, navigate to the RHACS console and open Platform Configuration > Policy Management. Policies that were updated by the script will show a "Skips init" indicator next to them. Note that the declarative (CRD-managed) policies we applied earlier (EAP-Init-Test: Privileged Container and EAP-Init-Test: Fixable Important+ CVE) were explicitly skipped by the script — these must be managed separately by adding skipContainerTypes: ["INIT"] to the evaluationFilter in their CRD manifests.