Kubernetes Version 1.22: Security Features You Need to Know
Even with Kubernetes’ new, longer release cycle in place, it doesn’t seem long since the last version came along with all its new features, but 1.22 is upon us. As ever, there’s an interesting mix of new features that are starting their maturation process as alpha releases and other features that are graduating to beta or stable. Here are some of the highlights, from a security perspective, of this release.
PodSecurity admission controller
After the PodSecurityPolicy feature was deprecated in the Kubernetes 1.21, its in-tree replacement has arrived as an alpha feature in this release. Although it’s not recommended for production use at the moment, having it available as an alpha will let users test it to see whether it will meet their needs for security admission control. The current design of this new feature is less complex than the PSP feature it replaces, but as a result it’s not quite as flexible, which might mean that external options are a better fit for complex policy requirements.
Unprivileged port sysctl marked as “safe”
One of the main reasons that containers run as the “root” user is so they can bind ports below 1024, which used to be regarded as privileged and required additional permissions. A change in this version of Kubernetes will allow pods to be configured to let unprivileged users bind these low ports, making it easier for application developers to move to using non-root user accounts for their containers.
With version 1.22 you should be able to change the sysctl in the security context of your pod manifests, allowing containers that are running as unprivileged users to bind low ports.
- name: net.ipv4.ip_unprivileged_port_start
NetworkPolicyEndPort moves to beta
Allowing Kubernetes network policies to target a range of ports has been a common enhancement request for a while, as it will allow for single rules to be used to cover a set of services on adjacent ports.
In 1.22 this feature is moving to beta, which means it will be enabled by default. However, your Container Network Interface (CNI) will need to support this for it to be effective.
Default seccomp profile
A feature to add support for a default seccomp profile per node has been added as alpha in this version. This helps to address a long-standing weakness in Kubernetes’ default security posture caused by Docker’s default seccomp policy being disabled when containers were run under Kubernetes.
Seccomp is an important layer in the security of Linux containers, helping to block attackers from doing things like accessing secrets from the Linux kernel keyring, as shown in Mark Manning’s keyctl-unmask research. A standard Docker container with the seccomp filter running will block around 60 specific syscalls.
Support for rootless containers
Another feature being introduced as alpha in this version is support for the kubelet and other node components to run on cluster nodes in a user namespace. With this change implemented, it could allow for all Kubernetes node components and containers to run as non-root users, significantly reducing the risk of container breakout attacks compromising the underlying cluster nodes.
Most of the key security features in this release are in the alpha phase, but it’s great to see all the ongoing efforts to improve the security of Kubernetes for users and administrators. As ever, it’s also important to watch the smaller changes, like the new sysctl support in this release, as they can provide incremental improvements and help make it easier to implement changes to more secure practices.