Uploaded image for project: 'OpenShift Over the Air'
  1. OpenShift Over the Air
  2. OTA-784

Check PodSecurityViolation behavior on 4.11 to 4.12 updates

XMLWordPrintable

    • Icon: Spike Spike
    • Resolution: Done
    • Icon: Critical Critical
    • None
    • None
    • Update Monitoring
    • 3
    • False
    • None
    • False
    • OTA 225

      4.12.0-ec.3 included cluster-kube-apiserver-operator#1369 tightening pod/container security admission from "warn" to "reject" (I think?). We should test the UX by:

      1. Launching a 4.11 cluster.
      2. Installing a violating workload.
      3. Confirm that PodSecurityViolation starts firing.
      4. Request an update to 4.12.0-ec.3.
      5. See how the workload handles the end-of-update rolling machine-config reboots.

      If the workload continues to have non-fatal admission warnings, that suggests that I'm misunderstanding cluster-kube-apiserver-operator#1369.

      If the workload fails to restart now that the warnings are fatal, we might want a new admin-ack on 4.11.z, similar to the Kube-API-removal OCPBUGS-1251, for "If your cluster, or any idle workloads or tools use...", so that admins are not surprised if non-compliant workloads break post-update.

            trking W. Trevor King
            trking W. Trevor King
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: