Validating Webhook Hardening

[ihcsim]

The validating webhook should be deployed as its own workload, in order to decouple its lifecycle, operation and maintenance from that of the controller. This decoupling will allow us to scale the controller and (future) webhooks separately.

The webhook should definitely not share the same endpoint as the controller's health check and metrics endpoint, to ensure that its probe failures don't cause K8s to restart the controller, and vice versa.

The webhook should be made a required component so that no bad inputs can be passed to the Kanister controller. To accommodate for CI testing or downstream variations, the ValidatingWebhookConfiguration YAML manifest can be updated with the failurePolicy property set to Ignore.

[github-actions]

Thanks for opening this issue 👍. The team will review it shortly.

If this is a bug report, make sure to include clear instructions how on to reproduce the problem with minimal reproducible examples, where possible. If this is a security report, please review our security policy as outlined in SECURITY.md.

If you haven't already, please take a moment to review our project's Code of Conduct document.

[muffl0n]

Thanks for opening this issue!

I would like to add #1345 to the list of things we should fix.
We currently deactivated the webhook cause the way the certificate is generated atm breaks our CD by reporting a chance on every run.

[ihcsim]

@muffl0n how do you normally deploy Kanister? Like helm upgrade --install, or do you helm template first?

[muffl0n]

We use Helmfile and do automatic runs on git changes:

• diff for branches
• apply for main

So there is a pseudo change reported for the certificate for branches and there is a change of the certificate for every run for main.

[github-actions]

This issue is marked as stale due to inactivity. Add a new comment to reactivate it.

[pavannd1]

Valid