1. Proposed title of this feature request
OLM Gatekeeper Operator Configuration: Webhook Rules/Resources

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

On the Red Hat OLM Gatekeeper custom resource (gatekeepers.operator.gatekeeper.sh) we would request the ability to configure-separately per validating/mutating webhook-which apiGroups, apiVersions, and resources are evaluated by the Gatekeeper ValidatingWebhookConfiguration ('gatekeeper-validating-webhook-configuration', webhook 'validation.gatekeeper.sh') and MutatingWebhookConfiguration ('gatekeeper-mutating-webhook-configuration' webhook 'mutation.gatekeeper.sh').

Under the current OLM Gatekeeper configuration, all resource requests (to applicable namespaces) will result in calls to the Gatekeeper service--whether or not there is Gatekeeper policy defined for that resource. This is because OLM Gatekeeper sets * apiGroups, apiVersions, and resources on the Gatekeeper webhook configuration resources.

We would like to be able to limit when the Kubernetes API server calls to the Gatekeeper service, based on resource type.

The motivation is to eliminate unnecessary calls to the Gatekeeper service for resources for which there is no Gatekeeper policy defined; and to reduce operational risks-with regard to Kubernetes API service call latency and failure policy-of the Gatekeeper admission webhooks.

Risks:
- Calls to webhook services during the Kubernetes admission process add latency to the overall request to the API server. Too much webhook latency can cause Kubernetes API server requests to fail.
- If the webhook failurePolicy is set to 'Fail' on the Gatekeeper CR, all resource requests to the Kubernetes API will fail (for the applicable verbs and namespaces) if the Gatekeeper service is unavailable or takes too long to respond We would like to be able to define something like:

apiVersion: operator.gatekeeper.sh/v1alpha1
kind: Gatekeeper
metadata:
  name: gatekeeper
spec:
  validatingWebhook:
    enabled: true
    apiGroups:
       - 
       - 
    apiVersions:
       - 
       - 
    resources:
       - 
       -
       - 
  mutatingWebhook: 
    enabled: true
    apiGroups:
       - 
       - 
    apiVersions:
       - 
       - 
    resources:
       - 
       -
       -  

References: https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#timeouts https://open-policy-agent.github.io/gatekeeper/website/docs/customize-admission

3. Why does the customer need this? (List the business requirements here)
Unable to onboard the Red Hat OLM operator for production use

4. List any affected packages or components.
OLM