Ivan Sim

@Sagar2366 Currently, all the docs are written in [rst](https://docutils.sourceforge.io/rst.html) format. Any idea what porting it over to GH Pages with Hugo looks like, including CI automation etc.?

Will it be acceptable to fall back to using the Kubernetes apiserver trust root? That seems to be the behaviour if the [`caBundle` field](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#webhookclientconfig-v1-admissionregistration-k8s-io) isn't specified in the validating webhook...

I wonder if the webhook can issue a [CSR](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/) to the apiserver and get a signed certificate from it.

Looks like it uses the same K8s CSR API. Just trying to see if we can avoid introducing external components.

Thanks for putting https://github.com/kanisterio/kanister/pull/1369 together. It helps to see what the code looks like :+1:. At this point, we want to keep Kanister unopinionated in regards to cert management solutions....

Sounds like we agree that cert-manager is a more complete solution. Even `kube-webhook-certgen` doc recommends it. Let me know if you are interested in putting together a reference architecture. As...

Won't `kube-webhook-certgen` has the same issue since it relies on the next `helm upgrade` to run the job?

Essentially, what @shuguet describes is how cert-manager and many other cert management solutions work i.e. they generate a K8s secret (of type `kubernetes.io/tls`), and the server (webhook, in our case)...

If user wants to bring their own cert, then the Helm chart won't generate the `caBundle` in the webhook configuration. It becomes a value that is configurable in the chart's...

Still relevant.