Implement the admission server

[tokers]

We should implement an admission server in the apisix ingress controller to validate configurations like plugins. But for now, we don't have a way to validate each plugins unless we have the json schema data.

[fgksgf]

I'm working on this, assign it to me, please.

[fgksgf]

I did a research and found three ways to implement this:

1. The hand-crafted solution：implement the server with net/http or gin, verbose and time-consuming, but most flexible.
2. openshift/generic-admission-server: it is simpler to set up but more opinionated (e.g. you can’t select the server framework). It is worth noting that the framework uses TLS authentication and authorization mechanisms which are built into the Kubernetes aggregated API server library, which means that webhooks are secure by default. Using this library allows you to avoid the complication of creating and maintaining a client key and certificate for each webhook server; you only need to maintain a server key and certificate for each webhook server. And by using this library your webhook will also perform authorization which uses Kubernetes' own SubjectAccessReview and RBAC mechanisms.
3. kubewebhook: the setup code at the beginning is longer, but writing the actual business logic is much easier. More flexible than openshift/generic-admission-server.

Reference: https://banzaicloud.com/blog/slok-webhook/

Could you give some advice that which way should I take ? Thanks.

[tokers]

I did a research and found three ways to implement this:

1. The hand-crafted solution：implement the server with net/http or gin, verbose and time-consuming, but most flexible.
2. openshift/generic-admission-server: it is simpler to set up but more opinionated (e.g. you can’t select the server framework). It is worth noting that the framework uses TLS authentication and authorization mechanisms which are built into the Kubernetes aggregated API server library, which means that webhooks are secure by default. Using this library allows you to avoid the complication of creating and maintaining a client key and certificate for each webhook server; you only need to maintain a server key and certificate for each webhook server. And by using this library your webhook will also perform authorization which uses Kubernetes' own SubjectAccessReview and RBAC mechanisms.
3. kubewebhook: the setup code at the beginning is longer, but writing the actual business logic is much easier. More flexible than openshift/generic-admission-server.

Reference: https://banzaicloud.com/blog/slok-webhook/

Could you give some advice that which way should I take ? Thanks.

I look through these two packages, I like the features provided by kubewebhook like the metrics integration, I'd like to vote for it. BTW, do you know which admission server frameworks are used by other famous ingress controllers or service mesh control plane?

[tokers]

kubewebhook: the setup code at the beginning is longer, but writing the actual business logic is much easier. More flexible than openshift/generic-admission-server.

It's not a problem as we already have a HTTP server managed by go-gin.

[fgksgf]

I look through these two packages, I like the features provided by kubewebhook like the metrics integration, I'd like to vote for it.

Ok, I will use it.

BTW, do you know which admission server frameworks are used by other famous ingress controllers or service mesh control plane?

I just look through go.mod files of ingress controllers mentioned in this file and find neither of these frameworks is being used.

[tao12345666333]

This feature has been implemented #573, and I will close this issue. Feel free to reopen it, if you have any question.