Add AdmissionWebhook Examples

[amouat]

Add examples for ValidatingAdmissionWebhook and MutatingAdmissionWebhook.

It should be possible to use examples from the Kubernetes docs, but please make sure they work standalone.

If you want to pick up this issue, please first read the README.md and CONTRIBUTING.md. Make sure you follow the existing style and standards for other examples.

[Spazzy757]

Question on this, obviously you would need some kind of service to route the webhook to right?
Does that fall into the stand alone bit (would I need to create the configuration for the server part as well)?

[amouat]

Yeah, good question. It's really one for @ianmiell as this is his project.

Personally, I'd lean towards not including the service and documenting this and what the failure scenario is (I think the default is disallow in validating admission webhooks, but this is probably configurable).

Having said that, it would be easy to build a very simple service and put in a deployment. The major advantage is the reader could also see what goes into the service (assuming you link to the code or put it in here if it's small enough). The disadvantage is we're complicating things and arguably expanding the remit of the repo.

[Spazzy757]

I will wait for @ianmiell From the look of the other examples there is no space for explanations or comments in the examples so that would make this a "special case" which I don't think fits. That being said, giant swarm does have a simple example that we could possibly use https://docs.giantswarm.io/guides/creating-your-own-admission-controller/ but then we depend on them.

[ianmiell]

I think the question to ask is: what would a reader make of this if they just read the information in the repo? The lack of comments/explanations etc in the examples is not an ideal for me, it's mostly just project debt, or I've assumed it's "obvious". Examples should be self-standing and usable, ie allow people to implement them on their own clusters to see how they work without having to go elsewhere, hunt things down, or figure things out for themselves. This gets tricky with eg volumes, or anything that specifies a particular node name, so can't always be done cleanly. There are examples of more complex ones, eg: cloud-providers/gcp/https-ready-alb. In this case I think it would be far better to include the service if it helps demonstrate the functionality to a user that wants to experiment with it in a controlled way. Reading the giantswam link makes me wonder if this is a bit involved for this repo.

…

On Tue, Oct 6, 2020 at 9:28 AM Brendan Kamp ***@***.***> wrote: I will wait for @ianmiell <https://github.com/ianmiell> From the look of the other examples there is no space for explanations or comments in the examples so that would make this a "special case" which I don't think fits. That being said, giant swarm does have a simple example that we could possibly use https://docs.giantswarm.io/guides/creating-your-own-admission-controller/ but then we depend on them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVNZTMGCT2CG6PUR6VPUATSJLIJLANCNFSM4RXA32HA> .

[Spazzy757]

@ianmiell I had comments (see 3d550b8) but I then realised none of the other examples had inline comments for the yaml so I removed them. What would be the best way forward here?

[ianmiell]

I'm not sure TBH. I certainly don't want you to waste time on something that might not be suitable for the vision I had for this repo. My original vision was that I was fed up of struggling to find basic examples of things that I needed (like a deployment or a pod, or a mount) so I could cut and paste and quickly get going. Admission Webhooks are far more involved things that require orchestration in themselves to get going with shell commands etc, so if we were to do it I would want there to be some clear path to reproduction. (I think it would be reasonable to assume docker-desktop/similar for this) Even the k8s docs are not easily taken by a newbie and turned into something basic they could build from (IMO). So if you want to pursue it, I'd want a completely unambiguous set of steps (and, ideally, scripts) to get this working on a given environment (eg docker-desktop). A bit like a runbook, in fact. What do you think, Adrian?

…

On Wed, Oct 7, 2020 at 10:22 AM Brendan Kamp ***@***.***> wrote: @ianmiell <https://github.com/ianmiell> I had comments (see 3d550b8 <3d550b8>) but I then realised none of the other examples had inline comments for the yaml so I removed them. What would be the best way forward here? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVNZTLAYK7HJ76AN6GQTTLSJQXN3ANCNFSM4RXA32HA> .

[amouat]

We have a webhook for Trow. I don't remember it being that complicated - what's the shell commands you're thinking of? There is a chicken & egg problem - if you have a deployment for the admission service, it needs to run before the webhook is configured.

I think the project should limit itself to k8s YAML and just assume the webhook service exists. That way if someone uses kubectl example ... they would get a minimal bit of YAML that probably helps them.

[ianmiell]

The shell commands I was thinking of were to do with creating the CA bundle in the examples given. I think I'd like the webhook service to exist in a deployment in the example, so you can implement it fully ('self-standing', 'hello world' principle) without needing to go elsewhere or figure anything out. Chicken and egg is fine - one file with deployment first, then VAW should be fine?

…

On Wed, Oct 7, 2020 at 1:18 PM Adrian Mouat ***@***.***> wrote: We have a webhook for Trow. I don't remember it being that complicated - what's the shell commands you're thinking of? There is a chicken & egg problem - if you have a deployment for the admission service, it needs to run before the webhook is configured. I think the project should limit itself to k8s YAML and just assume the webhook service exists. That way if someone uses kubectl example ... they would get a minimal bit of YAML that probably helps them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVNZTKHHHPIN6XQWJNFDEDSJRMCZANCNFSM4RXA32HA> .