Implement "CustomPolicy" policy

RFE https://issues.redhat.com/browse/RFE-520 and https://issues.redhat.com/browse/API-990 implemented what's documentedin https://docs.openshift.com/container-platform/4.7/security/audit-log-policy-config.html

That caused a change of behavior starting with OCP 4.6:

# OCP 4.7
[root@openshift-jumpserver-0 ~]#  oc get kubeapiservers.operator.openshift.io/cluster -o yaml | egrep audit-policy-file -A1
      audit-policy-file:
      - /etc/kubernetes/static-pod-resources/configmaps/kube-apiserver-audit-policies/default.yaml

The definitions of the 3 supported audit profile policies can be found here:
https://github.com/openshift/cluster-kube-apiserver-operator/blob/release-4.7/bindata/v4.1.0/kube-apiserver/audit-policies-cm.yaml

Further looking at the code, even in the latest master revision, only the 3 provided profiles are permitted:
https://github.com/openshift/api/blob/517b8a7697503a7502e50b2f87d6857099880504/config/v1/types_apiserver.go#L61

We do have another RFE in the works:
https://issues.redhat.com/browse/RFE-1448
https://issues.redhat.com/browse/API-1133
https://github.com/openshift/cluster-kube-apiserver-operator/issues/1026

However, this will only add a 4th policy profile and will not give you any further control over the policies.

We have a customer who would like to log the following:

      rules:
      - level: RequestResponse
        nonResourceURLs:
        - /login*

I do not see that covered by the existing policies. I don't know if this will be covered by https://issues.redhat.com/browse/RFE-1448

It should be trivial to add a "CustomPolicy" policy by extending:

const (
	// "Default" is the existing default audit configuration policy.
	AuditProfileDefaultType AuditProfileType = "Default"

	// "WriteRequestBodies" is similar to Default but it logs request and response
	// HTTP payloads for write requests (create, update, patch)
	WriteRequestBodiesAuditProfileType AuditProfileType = "WriteRequestBodies"

	// "AllRequestBodies" is similar to WriteRequestBodies, but also logs request
	// and response HTTP payloads for read requests (get, list).
	AllRequestBodiesAuditProfileType AuditProfileType = "AllRequestBodies"

        // new
        AuditProfileCustomType AuditProfileType = "CustomPolicy"
)

Then, check if a configmap with a custom name exists, e.g. "CustomPolicy". Admins are then responsible to create their own "CustomPolicy" configmap. If that configmap exists, load its configuration (perhaps after making sure that the configmap matches some sanity checks). Then, apply the CustomPolicy configmap. If the configmap does not exists or does not match the sanity checks, log this as an event and apply the default policy.

From a technology standpoinit this should be really easy to implement. However, I suspect that there's a reason why we are not implementing such a feature? If so, feel free to close this RFE but I'd like to give customers who ask for such a feature an explanation for why we would be opposed to this.