Week Ending March 22, 2020

Developer News

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.

Release Schedule

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.

Featured PRs

#89069: Remove support for basic authentication

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.

#88893: kube-apiserver: use SO_REUSEPORT when creating listener

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.

Other Merges

Remove the already-deprecated hyperkube and debian-hyperkube-base images
Ensure the NoExecute node taint is reconciled correctly when manually removed
Don’t display auth tokens from kubectl config view

Version Updates

Last Week In Kubernetes Development (LWKD) is a product of multiple contributors participating in Kubernetes SIG Contributor Experience. 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.