[feature]: Specify failurepolicy when MutatingWebhookConfiguration is created

[EdwardCooke]

Is your feature request related to a problem? Please describe.

I'm trying to create a mutator on a pod, which works only while my operator is running. When the operator dies, for example, restarting the deployment, the pods can't be created because the failurePolicy is set to Fail, the default. When the pod starts up after changing it manually it gets reset to Fail.

Describe the solution you would like

Have a method called on the webhook that will allow us to configure the webhook and other objects that get installed in the cluster.

Additional Context

No response

[erin-allison]

I don't think having further configuration would be bad, though for your specific situation, I would not necessarily allow items to fall through the webhook when pods the operator gets redeployed (unless that's a non-issue for you).

What you can do is have the webhook configured to exclude mutating anything in a select few namespaces (kube-system and whatever namespace you would be deploying your operator into), by applying a label to them (such as "IgnoreMutate") and then filtering on that:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
  - name: my-webhook.example.com
    namespaceSelector:
      matchExpressions:
        - key: IgnoreMutate
          operator: NotExists
    rules:
      - operations: ["CREATE"]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["pod"]
        scope: "Namespaced"

[EdwardCooke]

Thanks for the suggestion, I would still need a way to customize the mutating webhook configuration when the init container runs. I can create a PR with this feature, along with the bug I filed, and a fix for #525. I had to fix both those bugs and add this feature in a locally modified version in order to continue my project. Would you be open to accepting that PR?

[buehler]

Hey @EdwardCooke
Of course, submitting a PR is appreciated!
I'm currently "under water" with work, so reviewing / responding takes its time.

[EdwardCooke]

Awesome. I'll try and get a PR up in the next couple of days. I was thinking of a new interface that could optionally be implemented that would be called. Should be pretty easy to follow.

[ecooke-macu]

A pull request is created. It also addresses #525, something that was also causing me pains. I implemented that as an opt-in feature since it would delete the existing webhooks and recreate them on startup to guarantee an expected state.