-
Task
-
Resolution: Done
-
Critical
-
None
-
None
-
None
-
False
-
None
-
False
-
-
Impact statement for the OCPBUGS-36833 series:
Which 4.y.z to 4.y'.z' updates increase vulnerability?
All 4.15 to 4.16, until the OCPBUGS-36833 series takes mitigations back to 4.16z.
Which types of clusters?
Clusters where any controller attempts to remove the openshift.io/internal-registry-pull-secret-ref annotation from ServiceAccounts.
There is no read-only way to check for exposure in general, and we don't expect the OLM-installed controllers where we have already found this behavior to be exhaustive. But you can manually test a 4.15 cluster by adding that annotation yourself to all ServiceAccounts in the cluster, waiting a while, and going back to see if the annotations are still there. If they are, you're probably safe to update. If they are not, managedFields may point at the over-reaching controller that cleared the annotation, and you'd want that fixed before you update to 4.16 before the OCPBUGS-36833 series takes mitigations back to 4.16z. Either way, you'll want to remove the test annotations before updating to 4.16.
What is the impact? Is it serious enough to warrant removing update recommendations?
Fighting over the annotation between the over-reaching controller and the OpenShift controller manager will leak Secrets into the affected namespace, eventually overwhelming etcd storage and breaking the cluster.
How involved is remediation?
The best remediation is fixing the over-reaching controller, so it leaves the openshift.io/internal-registry-pull-secret-ref annotation alone, instead of deleting it. Failing that, you can:
- Update into an OpenShift release with a fix from the
OCPBUGS-36833series. - Install a ValidatingAdmissionWebook that blocks the over-reaching controller from deleting the openshift.io/internal-registry-pull-secret-ref annotation.
- Possibly set a resource quota on the number of Secrets that can exist in impacted namespaces.
Is this a regression?
Yes. OpenShift 4.15 didn't mind controllers trying to clear annotations from ServiceAccounts. OpenShift 4.16 does mind, and will leak Secrets in that situation until the OCPBUGS-36833 series brings fixes.
- blocks
-
OCPBUGS-36833 4.16 "Bad" reconciliation loops can cause unbounded dockercfg secret creation
- Closed
- links to
-
RHEA-2024:137143 Release of marin3r operator 0.13.1
- mentioned on