Kubernetes switched over to using EasyCLA for CLA verification on Feb 5. You can tell Prow
/easycla to recheck your CLA status. If that doesn’t work, file an LF ticket and add your report to the tracking issue.
Next Deadline: Exceptions due, March 21st
We are now in Enhancements Freeze, which means if your KEP/feature isn’t already on the tracking sheet you’ll need to file an Exception (before March 21st).
Cherry-pick deadline for this month’s patch releases is this Friday.
With Enhancements Freeze, we’ve got an idea of features on deck for 1.24. As always, an accepted or tracked KEP is not a guarantee the feature will be merged for 1.24 or ever, so treat these as goals not promises.
Kubernetes as a project has always been very clear about the meaning of “alpha” (not production ready, very likely to change), “beta” (not production ready, design relatively solidified), and “GA” (production ready). This has covered many aspects of the project, including feature gates and API versions. Unfortunately beta’s on-by-default nature has frequently lead to much use in production clusters and, more importantly, dependencies in third-party tooling. Overall this has created a lot of upgrade pain for users. SIG-API-Machinery is planning to address this by requiring any new beta API versions to be disabled by default. This won’t affect any existing APIs, but future v1beta1 additions will require manual enabling in the kube-apiserver options.
Since the dawn of time^WKubernetes, we’ve had a pretty simple service account management system. The service account controller would create a JWT and shove it in a secret, and if a pod referenced that service account, it mounted the appropriate secret as a volume. This was simple but especially secure in complex environments. Over the past few years, we’ve slowly added more fully featured token management tools and we’ve now reached a point to switch the original use cases over to them. The overall plan is to migrate the default service account token to the newer BoundServiceAccountToken system (where the JWT is requested directly by the kubelet and never stored back into the API) and have the service account controller clean up any of the old secrets that aren’t directly referenced and appear unused. It will still be possible to request that a specific service account should get a long-lived token in a secret but those cases should be extremely rare. An excellent step forward for security!
A short KEP, but potentially an incredibly useful addition: this proposes adding “Checkpoint” and “Restore” operations to the CRI specification. The initial use case is only around the former, being able to get a checkpoint dump of a running container and then restore that in another environment. The author hopes this can be used as part of a security response, taking a forensic checkpoint of a malicious or exploited container and then restore it in a locked-down environment for further analysis. This is a good, focused starting point but if things work well, many other debugging (or even container migration) flavors might be on the menu later on.