Impact statement for the OCPBUGS-59251 series:

Which 4.y.z to 4.y'.z' updates increase vulnerability?

The behavior was observed in an upgrade from 4.18.19 to 4.19.3 using the candidate-4.19 channel. However, this appears to happen on clusters created prior to 4.14 and upgraded through to 4.19 will have the issue as described here.

Which types of clusters?

AWS clusters that were created prior to 4.14.

What is the impact? Is it serious enough to warrant removing update recommendations?

The update cannot finish because the aws-cloud-controller-manager needs a configmap with the cloud.conf file mounted, but the ConfigMap entry is empty in clusters created prior to 4.14 because the cloud.conf file was not required.

How involved is remediation?

It would be possible for an administrator to create the necessary cloud-conf ConfigMap in the openshift-cloud-controller-manager namespace with the correct values. The resolution to OCPBUGS-59251 should provide a minimal, default configuration in cases where the ConfigMap was not created by the installer.

An appropriate ConfigMap would look like this:

apiVersion: v1
data:
  cloud.conf: |
    [Global]
    DisableSecurityGroupIngress                     = false
    ClusterServiceLoadBalancerHealthProbeMode       = Shared
    ClusterServiceSharedLoadBalancerHealthProbePort = 0
kind: ConfigMap

Is this a regression?

Yes, for clusters born prior to 4.14 that ultimately move to 4.19. Clusters born after 4.14 do not seem to be affected.