Description
For audit logging
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.
I created: https://issues.redhat.com/browse/API-1215
Similar Issue:
In OpenShift 3.11, it is possible to use a webhook backend for audit events:
The recent Kubernetes version still supports webhook backends for audit events:
https://kubernetes.io/docs/tasks/debug-application-cluster/audit/#audit-backends
However, the OpenShift 4.9 docs do not mention webhook backends:
https://docs.openshift.com/container-platform/4.9/security/audit-log-view.html
And the Default policy for the API server appears to require a log backend: