Stay up-to-date on Kubernetes development in 15 minutes a week.
The Community Annual Report is out.
Next Deadline: Code Freeze, July 8th
Code Freeze is staring in a little over a week, which means it’s time to merge those enhancements or punt them to 1.23. Also, don’t forget that Docs wants your placeholder PRs on July 9th. There’s just one open critical-urgent bug in 1.22 right now, so if you know the code, maybe help close it?
Cherry-picks for the next patch release are due July 12th.
While PodSecurityPolicies are being deprecated, there is both demand and desire to provide some level of protection in Kubernetes itself for common use cases and patterns. So we have the new Pod Security system as a very partial replacement. The goal here is to start small so if your use case isn’t exactly covered, you can keep using an out-of-tree validation webhook or use a webhook and this together. I can’t cover the full cross-section of this new system so if you are interested in trying it, please do check out the KEP. But a basic summary:
There are three security profiles:
privileged
: Unconstrained, do anything just like you could without this system.baseline
: Known obvious container escapes are closed off but otherwise normal system access.restricted
: Follows Kubernetes hardening best-practices.Unlike PSPs, these policies are baked in and cannot be changed by users, though they are versioned so updates can be released along Kubernetes itself. What these mean in concrete terms is each policy has a set of Pod fields and the values permitted for them. If you want to start experimenting with these now there are equivalent PSPs provided.
You configure which policies to use where based on labels on the Namespace object. Once configured, the policy will apply to all Pods (and PodTemplate-containing objects in core) in that Namespace. On each Namespace, there are three policy actions that can be configured:
pod-security.kubernetes.io/enforce: <policy name>
- Any Pod that doesn’t match the requested policy will be rejected by kube-apiserver. This will not affect already-running Pods or objects containing a PodTemplate like a Deployment.pod-security.kubernetes.io/audit: <policy name>
- Any Pod or PodTemplate-y object that doesn’t match the requested policy will trigger an annotation on the audit events for the API call. This can be combined with an audit webhook to provide any behavior you want (realtime alerts, logging, etc).pod-security.kubernetes.io/warn: <policy name>
- Any Pod or PodTemplate-y object that doesn’t match the requested policy will send back warning headers in the API server response which some clients (including kubectl
) will display to the user.You can (and probably will) use multiple of these at once to get the desired response behavior. You can also specify a ...-version
label for each of the three actions which controls the version of the policy to use. Versions follow Kubernetes’ own versioning, with a default of latest
which gives you the most current version of the policy.
tl;dr three pre-set security policies, configured using Namespace labels, enforce vs. log vs warn configured per Namespace.
k8s.io/component-base/logs
is reverting registering JSON logging format by default, since JSON logging is not yet GA; this will involve multiple PRs and may break some testsStructured Log log: API registry logs
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.