-
Spike
-
Resolution: Done
-
Critical
-
None
-
None
-
False
-
None
-
False
-
-
-
0
-
0
Which 4.y.z to 4.y'.z' updates increase vulnerability?
4.13.(z<9) to 4.13.9.
4.12 to 4.13.9 are not affected, because folks expect cred bumps for minor updates, https://docs.openshift.com/container-platform/4.13/authentication/managing_cloud_provider_credentials/cco-mode-mint.html#manually-removing-cloud-creds_cco-mode-mint:
Prior to a non z-stream upgrade, you must reinstate the credential secret with the administrator-level credential. If the credential is not present, the upgrade might be blocked.
Which types of clusters?
AWS clusters in mint mode where the aws-creds Secret has been removed.
Also AWS clusters in mint mode where the aws-creds Secret is in place, but is unable to mint the new credential because of service control policies (SCPs) or similar. But we currently have no way to automatically detect this exposure, and also lack a procedure to manually check until a delta in permissions is detected, triggering an attempted update of AWS policies.
What is the impact? Is it serious enough to warrant removing update recommendations?
The update to 4.13.9 will not complete, although OCPBUGS-17733 doesn't include the exact ClusterOperator condition that blocks its completion. No other in-cluster degradation is expected.
How involved is remediation?
You can recover by restoring the aws-creds Secret for long enough for the cloud-credentials operator to mint new ingress credentials.
Alternatively, you can update to a later 4.13.z release, where OCPBUGS-17733 has been fixed.
Is this a regression?
Yes, from 4.13.(z<9) to 4.13.9.
- blocks
-
OCPBUGS-17733 Backported credential request breaks some upgrades to 4.13.9
- Closed
- links to