The big news this week is the release of two security fixes:
These fixes are released as v1.17.3, v1.16.7, and v1.15.10.
The Kubelet issue is related to a few of the metrics exposed by the Kubelet. Specifically HTTPRequests, HTTPInflightRequests, and HTTPRequestsDuration include the HTTP request path as a time-series label. This means that someone who can send an HTTP request to the Kubelet (even without authentication) can cause an a denial of service by creating an excessive number of time-series.
The kube-apiserver issue is similar, but with the User-Agent header from the client being used as a label. The way the API server records metrics is very different though, so it requires that the attacker be able to authenticate or that authentication be disabled.
Next Deadline: v1.18.0 released, March 24
A big congrats to the whole 1.18 team for what will hopefully be a successful release by the time you read this! As always, check out the 1.18 CHANGELOG for more info on all the great fixes and features.
The release retrospective is planned for April 16th.
Since the dawn of time, Kubernetes has supported a very simple Basic authentication system by pointing it at a CSV file containing users and passwords. This is somewhat limited on both a security and usability point of view, and the user “database” could only be updated by restarting the apiserver. If you are currently using basic auth, there is a similar Token Auth File option that also takes a CSV, the only major difference being that tokens are provided via
Bearer $token instead of the usual base64 blob of basic auth. That said, the static token file shares the limitation of requiring restarts for updates so perhaps look into an authentication webhook instead.
SO_REUSEPORT is a Unix socket feature which allows multiple processes to listen on the same port, effectively creating an in-kernel load balancer. The idea of this change is to allow zero-downtime, in-place upgrades of the API server. You would launch the new version, then let the old version finish any active requests and shut down, with the kernel ensuring no requests end up lost. If you already have a trusted upgrade mechanism this might not be too exciting, but it opens up a lot of possibilities especially with bare-metal deployments.
kubectl config view
Last Week In Kubernetes Development (LWKD) is a product of some members of the Kubernetes project, but is not an official publication of the Kubernetes project or the CNCF. All original content is licensed Creative Commons Share-Alike, although linked content and images may be differently licensed. LWKD does collect some information on readers, see our privacy notice for details.
You may contribute to LWKD by submitting pull requests or issues on the LWKD github repo.