Scope, Defaults, and the HyperConverged Object

Duration: ~15 minutes

Overview

Red Hat OpenShift Virtualization is an extension on top of an already-hardened OpenShift cluster. The OpenShift Virtualization hardening guide (December 2025) tells you what to lock on the hypervisor, not how to STIG the guest OS and not how to replace Compliance Operator profiles for OpenShift and RHCOS.

This module confirms CNV is installed, shows the one object you will audit for the rest of the pathway (HyperConverged/kubevirt-hyperconverged in openshift-cnv), and orients you to the running rhel-webserver VM. Later modules do not reinstall anything; they read and, only when a control has already drifted, remediate.

Why it matters

A VM looks like a pet server. On OpenShift it is a set of CRs (VirtualMachine, DataVolume, NAD) plus privileged node components (virt-handler, virt-launcher). If you only harden the guest, you miss device pass-through, live migration RBAC, and KubeVirt feature gates. If you only harden OpenShift, you still have a hypervisor attack surface.

What does it solve

  • Treating CNV as "just another operator" with no extra baseline

  • Guest-only hardening while HyperConverged still allows insecure registries or jsonpatch experiments

  • Confusing Kata sandboxed pods (201-09) with full VMs on OpenShift Virtualization

Your Mission

Prove CNV is healthy, name the HyperConverged object you will audit from virt-01 onward, and confirm the lab VM is Running. Do not patch HCO in this module.

Prerequisites

  • Cluster-admin (or permission to get CRs in openshift-cnv and VMs in rhel-webserver)

  • OpenShift Virtualization installed (this environment already has it)

  • OpenShift console tab available from the home page

Click each step only if you need a hint.

Confirm the OpenShift Virtualization CSV

You want a Succeeded ClusterServiceVersion in openshift-cnv. If this is empty, stop: the rest of the pathway cannot run.

oc get csv -n openshift-cnv
Look for a CSV whose name includes kubevirt-hyperconverged (or similar) with phase Succeeded.
Get the HyperConverged object

Almost every platform control in this pathway is a field on this single namespaced CR. Operators reconcile from HCO; do not jsonpatch the downstream KubeVirt/CDI objects yourself (virt-01 covers that annotation).

oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv
oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o jsonpath='{.spec.featureGates}{"\n"}'
The CR exists. Feature gates print as JSON (often empty or a short map). Empty is a secure starting point for most gates in virt-01.
Confirm the rhel-webserver VM

This VM is the production-like audit target for virt-04 and virt-05. Do not delete it and do not patch its spec in this pathway.

oc get vm,vmi -n rhel-webserver
oc get vm rhel-webserver -n rhel-webserver -o jsonpath='{.status.printableStatus}{"\n"}'
VirtualMachine and VirtualMachineInstance exist. Status should be Running.
Open VirtualMachines in the console

In the OpenShift console: Virtualization → VirtualMachines. Enable Show only projects with VirtualMachines and select project rhel-webserver. Overview should show one Running VM with guest agent reporting.

VirtualMachines overview for rhel-webserver
Zero alerts and one Running VM is a clean baseline before you start scoring controls.
Know what this guide does not cover

Keep these boundaries in mind for every later module:

  • OpenShift and RHCOS first. Use Compliance Operator supported profiles before you treat CNV as "done."

  • Guest OS separately. RHEL, Windows, or other guests follow their own hardening guides.

  • Level 1 vs Level 2. Level 1 is the expected baseline. Level 2 (KSM, dedicated VLANs, MultiNetworkPolicy) is extra segmentation or anti-side-channel posture.

  • Defaults are often already hardened. Many audits should return empty or false. That is a pass, not a skipped lab.

  • Kata vs CNV. 201-09 isolates a pod with a second kernel. This pathway hardens virtual machines scheduled by KubeVirt.

If Compliance Operator is not scanning the cluster yet, run 101-10 on a different day; do not block this pathway on it.

Debrief

You now have the two objects this pathway keeps returning to: HyperConverged/kubevirt-hyperconverged and VirtualMachine/rhel-webserver. Virt-01 starts with feature gates, insecure registries, and HCO jsonpatch annotations.

What breaks without this orientation:

  • Patching KubeVirt CRs instead of HCO, then losing the change on reconcile

  • Hardening only the guest while pass-through and RBAC stay wide open

  • Assuming Kata completed "virtualization security"

Next is virt-01 — feature gates and trusted HCO config.

Cleanup

This pathway is cumulative. The cleanup script records progress only. It does not delete HCO or rhel-webserver.

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