-
Spike
-
Resolution: Done
-
Critical
-
None
-
None
-
None
-
False
-
None
-
False
-
-
This is an impact statement for OCPBUGS-28231.
Which 4.y.z to 4.y'.z' updates increase vulnerability?
- 4.14 to 4.15 upgrades have a new role requirement (roleAdmin) on the root credential.
Which types of clusters?
- example: GCP clusters mint credentials. Check your vulnerability with:
$ oc get -o jsonpath='{.status.platformStatus.type}{"\n"}' infrastructure cluster GCP
And then this worksheet to determine your credential mode.
Or the following PromQL:
( group by (mode) (cco_credentials_mode{mode="mint"}) or 0 * group by (mode) (cco_credentials_mode) ) * on () group_left (type) ( group by (type) (cluster_infrastructure_provider{type="GCP"}) or 0 * group by (type) (cluster_infrastructure_provider) )
What is the impact? Is it serious enough to warrant removing update recommendations?
- The update will wedge on the CCO ClusterOperator being unable to mint the incoming 4.15 creds.
How involved is remediation?
- To recover clusters that update into the issue, admins would need to expand the permissions associted with the root minting creds. Possibly technically straightforward, but might require negotiating with cloud-IAM teams, and that can take time.
- To protect other clusters from updating into the issue, the CCO 4.14 UpgradableCheck function will need to grow the ability to test when the gcp root credential does not have the new permission and/or block upgrades when this is the case.
Is this a regression?
- Yes. While the permission is part of a new feature, the customer experiences a blocking error in cloud-credential-operator that they didn't previously experience.
- is related to
-
OCPBUGS-28231 Guard mint-mode GCP 4.14 to 4.15 on sufficient creds
- Closed
- links to