1. Proposed title of this feature request

Add SCC history field (or events) to track former SCC assignments

2. What is the nature and description of the request?

Whenever a mutating webhook modifies a pod, the SCC admission plugin
will be run a second time. Therefore, during the admission stage, a pod
can have been assigned to and mutated by several distinct SCCs. Think of
the pod being assigned the restricted SCC before webhooks run and the
restricted SCC mutating the runAsUser field, a webhook modifying the
pod, and then finally the privileged SCC being assigned to the pod.
In order to signal to administrators that a pod was assigned to and
possibly mutated by multiple SCCs during its creation phase, add a new
SCC history field which will store all former SCC assignments.

3. Why does the customer need this? (List the business requirements here)

We ran into a confusing situation where we had to explain the effects of the builtin SCC mutating SCC admission plugin and an Istio webhook. A customer had assigned the privileged SCC to one of their pods which was modified by the Istio mutating admission webhook. After the pod was spawned, it showed up with the "privileged" SCC, but OpenShift had also mutated the "securityContext.runAsUser" field of the pod's containers. In reality, what happend is that the pod was first assigned to the "restricted" SCC which mutated the runAsUser field, then the Istio webhook ran, and then the SCC plugin mutated the pod to the "privileged" SCC. However, there is currently no user facing event, annotation nor log to signal that this is happening.

The full analysis that we did for the customer is here: https://andreaskaris.github.io/blog/openshift/openshift-scc-with-mutating-webhooks/

4. List any affected packages or components.

the OpenShift kube-apiserver, more precisely:
https://github.com/openshift/api
https://github.com/openshift/apiserver-library-go
https://github.com/openshift/kubernetes