The changes to the auto-close workflow have been merged.
The commit bot will stop suggesting
/assign commands as part of its response to
opening a new PR, to encourage authors to seek reviewers
and not go straight to approvers. Leads and owners should boost this by recruiting/mentoring
reviewers. If your SIG or project needs any help with this, please reach out to ContribEx.
Do we need to support 32-bit ARM? Speak up if it’s something you use.
Next Deadline: Enhancement Exceptions Due, March 6th
We are now in Enhancements Freeze and folks are working on the code, docs, and tests for their actual features in prep for Code Freeze on March 14th.
New patch releases are due out this Wednesday, full of backported bug fixes.
kubectl debug allows launching ephemeral containers attached to either a pod’s namespace or the host namespaces. This helps to streamline debugging and allows removing common debugging tools like
strace from your normal runtime images. However, fancy tools like that are sometimes unhelpful if you don’t also have the required capability flags or other security settings to allow enhanced access. In the other direction, folks using the new Pod Security tooling can have problems with debug containers violating the namespace policies.
This PR only, so far, addresses the second issue; adding “general”, “baseline”, and “restricted” (and a backwards-compatible “legacy”) policy options to be applied to the ephemeral container. The KEP also outlines “sysadmin” and “netadmin” profiles to follow later for the privilege-raising side.
Also on the
kubectl debug train, if you have a file with the Pod or Node info in it, you can use that instead of passing the target info on the command line.
Pretty much what it says on the tin, if you use the
code-generator script you will now get ApplyConfigurations for server-side apply as well as the usual clientset libraries. If you are currently distributing clientsets for custom types, consider updating and re-running things. ACs are super helpful for new folks getting started with Apply.
One of the big pushes for KMS v2 has been better integration with external key management layers for our at-rest encryption. This local key-encryption key (KEK) system forms the first layer in what will be a multi-tier encryption system. The data-encryption keys (DEKs) get themselves encrypted with the KEK from the local service, which can itself integrate with things like cloud key management APIs or hardware solutions (or none of the above for most folks). This framework sets us up to build the cloud and HSM layers soon!