Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-6683

[4.11]Improve Pod Admission failure for restricted-v2 denials that pass with restricted

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • None
    • 4.11.z
    • apiserver-auth
    • None
    • Important
    • None
    • Proposed
    • False
    • Hide

      None

      Show
      None

      This is a clone of BZ https://bugzilla.redhat.com/show_bug.cgi?id=2117374 which fixed 4.12

       
      Description of problem:
      OCP 4.11 introduced the `restricted-v2` SecurityContextConstraint as the default binding for all authenticated users. When a Pod that would have normally be admitted successfully using the `restricted` SCC, but cannot be admitted using a `restricted-v2` SCC, it's not clear to the customer that the problem is related to the default SCC changing from restricted to restricted-v2.

      Suggestion is to generate an additional message for this specific use case that makes it clear to customers that they have a workload that is not compatible with restricted-v2.

      Example message:
      Error creating: pods "nginx-ingress-controller-75bffcfdf8-" is forbidden: the pod fails to validate against the default `restricted-v2` security context constraint, but would validate successfully against the `restricted` security context constraint.

      The goal of such a message is to give the customer a breadcrumb that the `restricted-v2` SCC is activated and set as the default, which they may have not been aware of. This would give them a way to find alternatives, such as changing the global default, fixing the application or assigning the `restricted` SCC to the Namespace or ServiceAccount.

      Version-Release number of selected component (if applicable):
      4.11

      How reproducible:
      Always

      Steps to Reproduce:
      1. Install OCP 4.11.0
      2. Create a deployment with a podtemplate with .spec.containers[*].securityContext.allowPrivigeEscalation = true in a new namespace

      Actual results:
      The pod will fail to be admitted with an error such as:

      Warning FailedCreate 27m (x25 over 76m) replicaset-controller Error creating: pods "nginx-ingress-controller-75bffcfdf8-" is forbidden: unable to validate against any security context constraint: [provider "anyuid": Forbidden: not usable by user or serviceaccount, spec.containers[0].securityContext.allowPrivilegeEscalation: Invalid value: true: Allowing privilege escalation for containers is not allowed, provider "restricted": Forbidden: not usable by user or serviceaccount, provider "nonroot-v2": Forbidden: not usable by user or serviceaccount, provider "nonroot": Forbidden: not usable by user or serviceaccount, provider "noobaa": Forbidden: not usable by user or serviceaccount, provider "noobaa-endpoint": Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid": Forbidden: not usable by user or serviceaccount, provider "machine-api-termination-handler": Forbidden: not usable by user or serviceaccount, provider "hostnetwork-v2": Forbidden: not usable by user or serviceaccount, provider "hostnetwork": Forbidden: not usable by user or serviceaccount, provider "hostaccess": Forbidden: not usable by user or serviceaccount, provider "rook-ceph": Forbidden: not usable by user or serviceaccount, provider "node-exporter": Forbidden: not usable by user or serviceaccount, provider "rook-ceph-csi": Forbidden: not usable by user or serviceaccount, provider "privileged": Forbidden: not usable by user or serviceaccount]

      Expected results:
      Add an additional or replacement error message when there is no SCC assignment other than `restricted-v2` AND `restricted` would have worked:

      Error creating: pods "nginx-ingress-controller-75bffcfdf8-" is forbidden: the pod fails to validate against the default `restricted-v2` security context constraint, but would validate successfully against the `restricted` security context constraint.

      Additional info:

              slaznick@redhat.com Stanislav Láznička (Inactive)
              slaznick@redhat.com Stanislav Láznička (Inactive)
              ying zhou ying zhou
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: