+++ This bug was initially created as a clone of Bug #1806568 +++ In 4.4, the SCC is maintained by the CVO. This means that the ratchet logic of "reconcile-scc" has been lost. Overall this is good (we documented that nothing should change the bootstrap SCC), but practically, anyone who has changed needs to handle the situation before they upgrade and have the resources stomped. We can make a change to 4.3.z which prevents upgrades (upgradeable=false) on fairly complicated predicates and provide links and help for dealing with the situation *before* it goes bad.
Above PR is from cluster-kube-apiserver-operator instead of openshift-apiserver. The bug's title has typo. Verified in 4.3.0-0.nightly-2020-03-15-112942: $ oc edit scc # remove "- projected" under anyuid and restricted Then found Upgradeable becomes False: $ oc get co kube-apiserver -o json | jq -r '.status.conditions[] | select(.type == "Upgradeable")' { "lastTransitionTime": "2020-03-16T10:31:07Z", "message": "DefaultSecurityContextConstraintsUpgradeable: Default SecurityContextConstraints object(s) have mutated [anyuid restricted]", "reason": "DefaultSecurityContextConstraints_Mutated", "status": "False", "type": "Upgradeable" } $ oc edit scc # add the removed stuff back Then Upgradeable becomes True.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0858
*** Bug 1806568 has been marked as a duplicate of this bug. ***