Setup and Navigation

1. Module Goals

  • Access the OpenShift, RHACS, and Quay consoles used throughout the roadshow

  • Run the bastion setup script for RHACS CLI access and workshop images (cluster apps are already in GitOps)

  • Build and push workshop images to Quay, then deploy the patient-portal application

  • Complete the Trusted Image Pulls from Quay security exercise

  • Navigate the RHACS dashboard, search, and Platform Configuration

2. Accessing the Workshop Components

2.1. Access the Red Hat® Advanced Cluster Security (RHACS) User Interface

Ensure that you have access to the RHACS user interface using the tab in the right side of the UI or go to https://central-reencrypt-stackrox.{openshift_cluster_ingress_domain}.

Procedure

  1. Log into the RHACS console using the RHACS tab to the right or go to https://central-reencrypt-stackrox.{openshift_cluster_ingress_domain}.

RHACS console

  1. Enter the RHACS credentials:

RHACS Console Username:

admin

RHACS Console Password:

{common_password}
RHACS console

2.2. Access the Red Hat® Quay UI

Red Hat Quay is an enterprise-grade container registry that provides a secure, scalable, and highly available solution for storing and managing container images. It offers integrated security scanning, access controls, and image signing to help ensure the integrity and security of containerized applications across hybrid and multi-cloud environments, including Red Hat OpenShift, AWS, Azure, and Google Cloud.

Let’s ensure that you have access to the Quay User Interface.

Procedure

  1. Log into the Quay console at https://registry-quay-quay.{openshift_cluster_ingress_domain}

Quay Console

  1. Enter the Quay credentials:

Quay Console Username:

admin

Quay Console Password:

{common_password}

3. Lab environment setup

The setup script below is the remaining bastion work: RHACS CLI variables, a local clone of demo-apps (for Dockerfiles), and the Quay image builds. Vulnerable demo apps, Compliance Operator, collector networking, and RHACS Central settings are deployed by OpenShift GitOps.

Variables persisted to ~/.bashrc:

  • TUTORIAL_HOME — cloned demo-apps repository

  • QUAY_USER / QUAY_URL — your Quay registry credentials and hostname

  • ROX_CENTRAL_ADDRESS / ROX_PASSWORD / ROX_API_TOKEN — RHACS Central host, admin password, and generated API token

  • APP_HOME — set when you deploy the patient-portal application (second script step)

3.1. Run the setup script

Procedure

  1. Clone the roadshow repository and run the lab setup script:

git clone https://github.com/rhpds/ocp5-rhacs-showroom.git
cd ocp5-rhacs-showroom
bash setup/lab-environment.sh \
  --quay-user admin \
  --quay-password '{common_password}'
Lab environment setup
Details: /home/lab-user/.acs-roadshow/lab-environment-YYYYMMDD-HHMMSS.log

[############################] 9/9  Lab environment setup complete

================================================================
  SUCCESS: Lab environment setup completed successfully
================================================================

  ✓ RHACS CLI ready (ROX_CENTRAL_ADDRESS / ROX_API_TOKEN saved)
  ✓ TSSC CLIs on PATH (cosign, oc-mirror, ec in ~/.local/bin)
  ✓ demo-apps cloned for image builds (cluster deploy is GitOps)
  ✓ Quay images ready (golden base + frontend, when image steps ran)
  ✓ Env file: /home/lab-user/.acs-roadshow/env
  ✓ Detailed log: /home/lab-user/.acs-roadshow/lab-environment-....log
Vulnerable demo apps are synced by the roadshow-demo-apps Argo CD Application. PodSecurity warnings on those workloads are expected.

  1. The script prints progress for each phase. When it completes, reload your shell environment:

source ~/.bashrc
echo "TUTORIAL_HOME=$TUTORIAL_HOME"
echo "QUAY_URL=$QUAY_URL"
echo "ROX_CENTRAL_ADDRESS=$ROX_CENTRAL_ADDRESS"
test -n "$ROX_API_TOKEN" && echo "ROX_API_TOKEN is set" || echo "ROX_API_TOKEN is missing"

4. Red Hat Quay

Red Hat Quay is an enterprise-quality registry for building, securing, and serving container images. The setup script already pushed your frontend and python-alpine-golden images. Explore the registry in the UI before deploying the patient-portal application.

4.1. Accessing Quay

Your Red Hat Quay console is available at: https://registry-quay-quay.{openshift_cluster_ingress_domain}

Quay Console Username:

admin

Quay Console Password:

{common_password}

The setup script built and pushed the frontend application image. Before deploying it to OpenShift, browse the repository and make it public.

Procedure

  1. Click the frontend repository in Quay.

00 quay login
00 frontend repo
00 quay sidebar

  1. Under Settings → Repository Visibility, click Make Public and confirm.

00 quay settings
00 quay public
00 quay public yes
The patient-portal deployment pulls from Quay. The repository must be public before running the deploy step below.

4.3. Vulnerability Scanning with Quay

  1. Open the Tags tab for the frontend repository.

00 quay tags

  1. Hover over the Security Scan column for vulnerability details.

00 quay scan hover
The image includes intentionally vulnerable packages for workshop policy exercises. Counts vary by scanner and feed.

  1. Click a vulnerability entry for remediation guidance.

00 quay vuln overview
00 quay vuln detailed

4.4. Verify RHACS and Quay integration

roxctl --insecure-skip-tls-verify -e "$ROX_CENTRAL_ADDRESS:443" \
  image scan --image=$QUAY_URL/$QUAY_USER/frontend:0.1 --force -o table | head -25

4.5. Deploy the patient-portal application

After making the frontend repository public, run the second setup phase:

cd ~/ocp5-rhacs-showroom
bash setup/lab-environment.sh --deploy-skupper-only
[lab-user@bastion ocp5-rhacs-showroom]$ cd ~/ocp5-rhacs-showroom
[lab-user@bastion ocp5-rhacs-showroom]$ bash setup/lab-environment.sh --deploy-skupper-only

==> Deploying patient-portal application (Skupper demo)
------------------------------------------------------------------------
Cloning into 'skupper-app'...
namespace/patient-portal created
deployment.apps/database created
service/database created
deployment.apps/frontend created
route.route.openshift.io/frontend-patient-route created
service/frontend-service created
deployment.apps/payment-processor created
service/payment-service created
NAME                                 READY   STATUS    RESTARTS   AGE
database-758f8f75f7-46ndf            1/1     Running   0          12s
frontend-5c487dcb47-7gsm7            1/1     Running   0          10s
frontend-5c487dcb47-f25hm            1/1     Running   0          10s
frontend-5c487dcb47-z9stn            1/1     Running   0          10s
payment-processor-6644dfc5b7-5vzqh   1/1     Running   0          8s
payment-processor-6644dfc5b7-96jb6   1/1     Running   0          8s
payment-processor-6644dfc5b7-9vl7b   1/1     Running   0          8s

Patient portal deployed. Frontend image: quay-h2xfr.apps.cluster-h2xfr.h2xfr.sandbox2437.opentlc.com/quayadmin/frontend:0.1

Verify the application is running:

oc get pods -n patient-portal
NAME                                 READY   STATUS    RESTARTS   AGE
database-758f8f75f7-46ndf            1/1     Running   0          56s
frontend-5c487dcb47-7gsm7            1/1     Running   0          54s
frontend-5c487dcb47-f25hm            1/1     Running   0          54s
frontend-5c487dcb47-z9stn            1/1     Running   0          54s
payment-processor-6644dfc5b7-5vzqh   1/1     Running   0          51s

5. Security Exercise: Trusted Image Pulls from Quay

You built, scanned, and deployed the frontend image through Quay. Before moving on, verify that OpenShift is running the same image you pushed—not an unexpected registry, tag, or stale pull.

5.1. Scenario

We scanned frontend:0.1 in Quay before go-live. Show me proof the patient-portal pods pulled that exact image from our registry and not something else.
— Morgan
Infosec

5.2. Your task

The steps are there for guidance. If you need help, expand the step and compare your approach to the lab commands.

Step 1 — Confirm the deployment image reference

Variables come from ~/.bashrc.

source ~/.bashrc
oc get deploy frontend -n patient-portal \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
echo "Expected: $registry-quay-quay.{openshift_cluster_ingress_domain}/$admin/frontend:0.1"
Step 2 — Inspect pod pull events

Check where OpenShift pulled the image from.

oc describe pod -n patient-portal -l app=frontend | grep -E 'Image:|Pull|Pulling|Pulled|Failed|Back-off'
    Image:          quay-h2xfr.apps.cluster-h2xfr.h2xfr.sandbox2437.opentlc.com/quayadmin/frontend:0.1
  Normal  Pulling    2m   kubelet  Pulling image "quay-h2xfr.apps.cluster-h2xfr.h2xfr.sandbox2437.opentlc.com/quayadmin/frontend:0.1"
  Normal  Pulled     2m   kubelet  Successfully pulled image "quay-h2xfr.apps.cluster-h2xfr.h2xfr.sandbox2437.opentlc.com/quayadmin/frontend:0.1"
Step 3 — Compare Quay digest to running pods

The imageID on the pod should include the same digest prefix (sha256:…​) as the Quay manifest.

source ~/.bashrc
podman inspect --format='Quay digest: {{.Digest}}' $registry-quay-quay.{openshift_cluster_ingress_domain}/$admin/frontend:0.1
oc get pod -n patient-portal -l app=frontend -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.containerStatuses[0].imageID}{"\n"}{end}'
Step 4 — Cross-check with RHACS

Confirm the scanned image matches what you deployed.

source ~/.bashrc
roxctl --insecure-skip-tls-verify -e "$ROX_CENTRAL_ADDRESS:443" \
  image scan --image=$registry-quay-quay.{openshift_cluster_ingress_domain}/$admin/frontend:0.1 --force -o table | head -15
Earlier in this module you had to make the Quay repository public before the deploy succeeded. If the repository were private and no imagePullSecret were configured, frontend pods would stay in ImagePullBackOff—a common production misconfiguration.
Quay frontend repository tags

5.3. What you learned

  • OpenShift records the full image reference and pull events on each pod—useful for supply-chain audits.

  • Tag names alone are not enough; digest comparison proves the cluster runs the same bits you scanned in Quay.

  • Registry visibility (public vs private) and pull secrets directly affect whether workloads can start securely.

  • RHACS ties vulnerability data to the exact image URI your deployments pull from Quay.

6. RHACS Basics

RHACS provides the tools and capabilities to address the security needs of a cloud-native development approach on Kubernetes. These security features represent any developer or administrator’s primary work across various environments, including multiple datacenters, private clouds, or public clouds that run Kubernetes clusters.

6.1. RHACS features

Using Red Hat Advanced Cluster Security for Kubernetes, you can gain comprehensive Kubernetes security that includes the following use cases:

  • Visibility: See your entire landscape of images, registries, containers, deployments, and runtime behavior.

  • Vulnerability Management: Identify and remediate vulnerabilities in container images and Kubernetes across the entire software development life cycle.

  • Compliance: Audit your systems against CIS Benchmarks, NIST, PCI, and HIPAA, with interactive dashboards and one-click audit reports.

  • Network Security: Visualize existing connections and enforce tighter segmentation using Kubernetes-native controls to reduce your blast radius.

  • Security Policy Guardrails: See all your deployments ranked by risk level, using context from Kubernetes' declarative data, to prioritize remediation.

  • Configuration Management: Apply best practices for Docker and Kubernetes to harden your environment for a more secure and stable application.

  • Threat Detection: Use rules, automated allow lists, and baselining to identify suspicious activity in your running applications accurately.

  • Incident Response: Take action, from failing builds and blocking deployments to killing pods and thwarting attacks, using Kubernetes for enforcement.

7. Introduction to the RHACS Console

This section focuses on navigation and search. Later labs go deep on each use case—do not spend time walking every menu here.

7.1. Navigating the RHACS Console

The "Dashboard" or RHACS home page has 3 sections:

  1. Navigation bar

  2. Navigation drawer

  3. Dashboard

01 acs dashboard 00

7.2. 1. Navigation Bar

The top bar contains the following functionality:

  • Global search

  • Command-line tools

  • Cluster health

  • Documentation

  • API reference

  • Enable dark/light mode

  • Logged-in user account

01 acs top bar

7.3. Global Search

The ability to instantly find resources is essential to safeguard your cluster. Utilize the RHACS search feature to find relevant resources faster. For example, you can use it to find deployments exposed to a newly published CVE or all deployments with external network exposure.

7.3.1. A search query

A search query consists of two parts:

  • An attribute that identifies the resource type you want to search for.

  • A search term that finds the matching resource.

For example, to find all violations in the frontend deployment, the search query is select Deployment THEN frontend.

In this search query, Deployment is the attribute, and frontend is the search term.

The search field in RHACS requires each attribute to be entered fully as a search term. Enter your first attribute, and hit the <tab> key to move along to the following attribute you would like to enter. Watch the video below for a demonstration.
RHACS maintains a library of searchable assets to help you search faster. They will appear in a drop-down list, and you can click on them to enter them as well. If a specific CVE or deployment cannot be found, please confirm the spelling of the asset name or that it is correctly deployed in the cluster.

You can also search using REGEX-like capabilities. Add an r/ before the search term—for example, Namespace:r/st.*x matches stackrox and stix.

7.3.2. Common Search Queries

Here are some common search queries you can try in the RHACS search bar if you’d like to test its functionality.

Query

Example

Purpose

CVE:<CVE_number>

CVE:CVE-2018-11776

Finding deployments that are affected by a specific CVE

Privileged:<true_or_false>

Privileged:true

Finding privileged running deployments

Exposure Level:<level>

Exposure Level:External

Finding deployments that have external network exposure
RHACS, like Kubernetes, works on a key:value system primarily due to its flexibility and power in organizing, selecting, and managing resources, but also because of the ability to set selectors and match objects based on a set of values (e.g., 'in', 'not in', 'exists', 'does not exist').
01 acs search cve

7.3.3. Local Page Filtering

Each RHACS view also supports local filtering with the same syntax as global search (including r/ regex). Attributes are limited to what is relevant on that page—for example, filtering violations by namespace.

Local filters apply only to the current view; global search spans the entire RHACS inventory.

7.4. Navigation Menu

01 acs nav

The left-hand navigation menu provides access to each of the security use cases, as well as product configuration to integrate RHACS with your existing tooling:

  • Dashboard: Summary view of your environment

  • Network Graph: Network flows, listening endpoints, and policy simulation — 06 Network and Runtime Security

  • Violations: Policy violation events and enforcement status — acs-06

  • Compliance: CIS, PCI-DSS, and STIG coverage — 04 Compliance

  • Vulnerability Management: Workload, platform, and node CVE views — 01 Vulnerability Management

  • Configuration Management: Misconfiguration and standards reporting — 02 Policy and Risk

  • Risk: Prioritized workloads — 02 Policy and Risk

  • Platform Configuration: Clusters, policies, collections, integrations, access control, and system settings

7.5. Dashboard

The RHACS dashboard provides at-a-glance counters, cluster/namespace filtering, and customizable widgets for risk, compliance, violations, and CVEs.

01 acs dashboard 01

The dashboard has three sections: the status bar, the dashboard filter, and actionable widgets.

01 acs dashboard 02

7.5.1. The Status Bar

The status bar provides at-a-glance numerical counters for critical resources. The counters reflect what is visible with your current access scope, defined by the roles associated with your user profile.

These counters are clickable, providing fast access to the desired list view pages as follows:

Counter

Destination

Clusters

Platform Configuration → Clusters

Nodes

Configuration Management → Applications & Infrastructure → Nodes

Violations

Violations Main Menu

Deployments

Configuration Management → Applications & Infrastructure → Deployments

Images

Vulnerability Management → Dashboard → Images

Secrets

Configuration Management → Applications & Infrastructure → Secrets

7.5.2. The Dashboard Filter

The dashboard includes a top-level filter that applies simultaneously to all widgets. You can select clusters and one or more namespaces within selected clusters. Any change to the filter is immediately reflected by all widgets, limiting the data they present to the selected scope.

The dashboard filter does not affect the status bar. When no clusters or namespaces are selected, the view shows All.
01 acs dashboard 03
01 acs dashboard 04

7.5.3. Actionable Widgets

Customize widgets and filters to highlight the data most relevant to your deployments.

7.6. Platform Configuration

Platform Configuration is where you manage clusters, policies, collections, integrations, access control, and system health.

01 pc 1

7.6.1. Policy Management

01 pc 2

Clone, edit, and create policies. RHACS ships with many defaults; this is where you tailor enforcement for your environment.

7.6.2. Collections

01 pc 3

Group deployments into collections and attach policies, reporting, or compliance workflows to those groups.

7.6.3. Integrations

01 pc 4

Connect image registries, notifiers, backup targets, cloud sources, and API tokens. You will configure notifiers and API tokens in 05 Notifications, API, and Integrations.

7.6.4. Access Control

01 pc 6

Configure authentication providers, roles, permission sets, and access scopes.

7.6.5. System Configuration and Health

01 pc 7

Manage data retention, cluster settings, and platform configuration.

01 pc 9

Monitor sensor upgrades, credential expiration, and generate diagnostic bundles from System Health.

Other Platform Configuration areas include Exception Configuration and Administration Events—useful for vulnerability exceptions and platform troubleshooting.

8. Security Exercise: ACME Incident Response

You are participating in the ACME Financial Services security incident workshop. Sarah, a senior OpenShift Platform Engineer, and Morgan from Infosec are responding to a breach in the payment-gateway production namespace. An attacker used a compromised CI/CD service account to exec into the payment-gateway pod, deploy a hidden toolkit (/tmp/.hidden_toolkit/exfil.sh), and beacon outbound to a command-and-control server.

Each ACS module ends with a hands-on exercise that advances this incident response story using RHACS and OpenShift platform tools.

8.1. Scenario

We have irregular egress traffic from payment-gateway on the production cluster. Sarah, use RHACS to locate the deployment and assess its risk before we touch the pod.
— Morgan
Infosec

8.2. Your task

The steps are there for guidance. If you need help, expand the step and compare your approach to the lab commands.

Step 1 — Open RHACS and switch to your namespace
Use your assigned workshop namespace suffix 1.

  • Payment gateway (breached workload): payment-gateway-1

  • Vulnerable Socket.IO demo: vulnerable-workload-1

Switch to your payment gateway namespace before running commands:

oc project payment-gateway-1

If your administrator has not yet provisioned the environment, ask them to run ./setup/deploy-incident-env.sh from the roadshow repository (see setup/README.adoc).

Incident call

  1. Log in to the RHACS console at https://central-reencrypt-stackrox.{openshift_cluster_ingress_domain}.

Step 2 — Search for payment-gateway in Risk

  1. Use Risk in the left navigation and search for payment-gateway.

Step 3 — Open the deployment

  1. Select the payment-gateway deployment in namespace payment-gateway-1.

Step 4 — Review risk factors

  1. Review the risk factors: external exposure, suspicious processes, and configuration issues.

Use global search with the query:

Deployment:payment-gateway Namespace:payment-gateway-{workshop_user_suffix}

8.3. What you learned

  • RHACS Risk view consolidates vulnerability, configuration, and runtime signals for a compromised deployment.

  • Locating a workload quickly is the first step when responding to an active incident.

  • The payment gateway shows elevated risk due to external connectivity and anomalous runtime behavior.

9. Summary

Setup is done and you can navigate the RHACS console. Next: Vulnerability Management.

giphy

10. Cleanup

Before moving to the next module, run the lab cleanup script to reset transient resources from this module.

cd ~/ocp5-rhacs-showroom
bash setup/lab-cleanup.sh --module acs-00