fix(catalog): Intel TDX/DCAP operators absent from OpenShift 5.0 operator catalogs (blocks 5.0 on Intel TDX) #167

Summary

On a clean OpenShift 5.0.0 install (Kubernetes v1.36.5), the operator catalogs contain no Intel device/attestation operators, so the pattern's Intel TDX hardware profile cannot be deployed.

Both subscriptions are enabled by default for the intel-tdx hardware profile in values-baremetal.yaml:

• intel-device-plugins-operator (SGX/TDX device plugin) — certified-operators stable 0.37.1 on 4.19/4.22
• intel-tdx-dcap-operator (DCAP/QGS quoting) — certified-operators alpha 0.1.0 on 4.19/4.22

Neither package exists in any catalog on 5.0.0.

Evidence

$ oc get catalogsource -n openshift-marketplace
NAME                  DISPLAY               TYPE   PUBLISHER   AGE
certified-operators   Certified Operators   grpc   Red Hat     ...
community-operators   Community Operators   grpc   Red Hat     ...
redhat-operators      Red Hat Operators     grpc   Red Hat     ...

$ oc get packagemanifests -n openshift-marketplace --no-headers | wc -l
499

$ oc get packagemanifests -n openshift-marketplace --no-headers | grep -iE 'intel|tdx|dcap|sgx'
sap-data-intelligence-observer-operator   Community Operators   ...   # false positive: "intel" inside "intelligence"

$ oc get packagemanifests -n openshift-marketplace \
    -o jsonpath='{range .items[?(@.status.catalogSource=="certified-operators")]}{.metadata.name}{"\n"}{end}' | wc -l
95

All three catalogs report READY; the certified catalog exposes 95 packages and none of them are Intel. The absence was re-checked after a delay and is not a catalog-warmup artefact.

Impact

For an Intel TDX cluster on 5.0.0:

• no intel-device-plugins-operator ⇒ no SGX/TDX device plugin ⇒ no /dev/sgx_* scheduling for quoting workloads
• no intel-tdx-dcap-operator ⇒ no DCAP QGS/PCCS ⇒ no TDX quote generation for attestation

Together these make confidential-containers attestation impossible on Intel TDX under 5.0.0, regardless of Kyverno or any other component.

The sandboxed-containers-operator (1.13.1), trustee-operator (1.2.1), GitOps, ACM/MCE, ESO, cert-manager, LVMS (stable-5.0 → 5.0.0), CNV (5.0.0) and NFD (5.0.0) are all present and installable — the gap is specifically the Intel hardware-attestation chain.

Notes

• ACM and MCE carry olm.maxOpenShiftVersion=5.0, i.e. they explicitly permit 5.0 — so catalog gating is working as designed elsewhere; the Intel packages are simply not published for 5.0 yet.
• The certified catalog for 5.0 is much smaller (95 packages) than 4.x; whether Intel operators are expected to return for 5.0.x or are being renamed/consolidated is the open question for the catalog owners.

Requested resolution

1. Confirm whether intel-device-plugins-operator / intel-tdx-dcap-operator are planned for the 5.0 certified catalog (and under what package names).
2. Until then, document that 5.0 is not supportable on Intel TDX, while it may be supportable on other TEE hardware profiles (AMD SNP uses different components).
3. Consider gating the intel-tdx hardware profile by cluster version so deployment fails fast with a clear message instead of stalling on a missing operator.

Related

• docs/supported-openshift-versions.md — support matrix and per-version gates
• Issue fix(kyverno): vendored Kyverno 1.17.2 requires MutatingAdmissionPolicy API absent on OpenShift 4.19/4.20 #166 — the separate Kyverno/MutatingAdmissionPolicy gate that blocks 4.19/4.20/4.21