-
Spike
-
Resolution: Done
-
Critical
-
None
-
None
-
Quality / Stability / Reliability
-
False
-
-
False
-
None
-
1
-
None
-
OTA 278
Impact statement for the OCPBUGS-62861 series:
Which 4.y.z to 4.y'.z' updates increase vulnerability?
Updates into 4.19.(9 <= z < 17) and 4.18.(23 <= z < 27) expose the cluster to this regression. Updates between affected releases (e.g. 4.19.9 to 4.19.10) do not increase the exposure.
Which types of clusters?
HyperShift clusters are exposed. Standalone clusters are not exposed. Traditional PromQL for "HyperShift is exposed" is:
group by (_id, invoker) (cluster_installer{_id="",invoker="hypershift"})
or
0 * group by (_id, invoker) (cluster_installer{_id=""})
What is the impact? Is it serious enough to warrant removing update recommendations?
Prometheus metrics served by the cluster-version operator (cluster_version, cluster_operator_conditions, etc.) fail to scrape.
How involved is remediation?
The only known remediation is updating to a release with the fix (4.20.1 and later OCPBUGS-62867, 4.19.17 and later OCPBUGS-62868, or 4.18.23 or later OCPBUGS-62869).
Is this a regression?
It is a regression, landing in 4.19.9 via OCPBUGS-60168 and 4.18.23 via OCPBUGS-60222. While those pivots to require client authentication were tested on standalone clusters, we neglected HyperShift testing. Since then hypershift#6965 has been opened to provide test-coverage for HyperShift metrics, and once that merges we will catch any future regressions before shipping them.
- blocks
-
OCPBUGS-62861 HyperShift ServiceMonitor for cluster-version-operator metrics: revert client auth
-
- Verified
-
- links to