Use the correct kubectl for the cluster

[kfox1111]

This patch updates the hooks to use the correct version of kubectl for the cluster you are running on.

It also enables the hooks to run with a container image that does not contain a shell.

fixes: #247

[marcofranssen]

We recently settled to adopt the chainguard images because they are known for their continuous security patches as well the small size.

[kfox1111]

Will chainguard build kubectl images for every major.minor.micro version of kubectl? Or at last maybe major.minor?

Also, because they don't cut tags, we'd probably have to keep a mapping of which version of latest each major.minor version would need to reference. Would be a lot more work.

I don't think its ever recommended to use a k8s client version that is greater then the cluster api version your running.

So, I'm unsure of the best way to use chainguard for this. Thoughts?

As far as I can tell, the rancher containers are just the kubectl binaries. So they are actually smaller then the chainguard images since there is no shell or other things needing updates. They should not be any less secure then the kubernetes version your running on your own k8s cluster since they match and the binaries are from the same source.

[kfox1111]

It wasn't until I started working on #249 that I noticed their website only mentions they are building 1.27.0 clients.

Though playing with crane, it looks like they have a few more options not documented...

1
1.25
1.25.4
1.25.4-r0
1.25.4-r1
1.26
1.26.0
1.26.0-r0
1.26.1
1.26.1-r0
1.26.1-r1
1.26.1-r2
1.26.2
1.26.2-r0
1.26.3
1.26.3-r0
1.26.3-r1
1.27
1.27.0
1.27.0-r0
1.27.1
1.27.1-r0

What if we looked in that list, and found the closes match? We'd still want to make a map of k8s version to newest rX revision and use that. and if k8s < 1.26.0, then just use 1.25.4-rX?

A version without busybox would still be nice from a size/cve standpoint too.

[kfox1111]

Maybe one other option.... https://kubernetes.io/releases/version-skew-policy/#kubectl says something different then what I remember. We're talking about supporting n-2...n. kubectl supports one back and one forward from a kubectl version. so, we could go with a chainguard kubectl n-1 image from what we support if its still getting updates. It would cover all of the n-2...n releases we officially support.

[marcofranssen]

Maybe one other option.... kubernetes.io/releases/version-skew-policy/#kubectl says something different then what I remember. We're talking about supporting n-2...n. kubectl supports one back and one forward from a kubectl version. so, we could go with a chainguard kubectl n-1 image from what we support if its still getting updates. It would cover all of the n-2...n releases we officially support.

I checked with the project. They will only support the latest supported k8s releases which indeed is the n-2. I asked if I could add a contribution there to support more, bt for security reasons (CVE patching) they won't.

$ crane ls cgr.dev/chainguard/kubectl | grep -v 'sha256' | head -n 23
1
1.25
1.25.4
1.25.4-r0
1.25.4-r1
1.26
1.26.0
1.26.0-r0
1.26.1
1.26.1-r0
1.26.1-r1
1.26.1-r2
1.26.2
1.26.2-r0
1.26.3
1.26.3-r0
1.26.3-r1
1.27
1.27.0
1.27.0-r0
1.27.1
1.27.1-r0
latest

[faisal-memon]

Since we only officially support n-2 is the current chainguard image we are using sufficient?

[faisal-memon]

Overall changes look good to me. Its ok if we cant use chainguard everywhere.

[faisal-memon]

Thanks @kfox1111 for fixing this.

[faisal-memon]

@kfox1111 Some conflicts need to be resolved before we can merge this.