Another new Kubernetes release is upon us. Kubernetes v1.25 introduces a number of updates that are relevant to security, including some big changes in the world of admission control. It also includes several smaller (but still very useful) changes that can help cluster operators keep their environments secure. In this post, we'll take a closer look at these changes and explore their implications for Kubernetes security.
PodSecurityPolicy → Pod Security Admission
PodSecurityPolicy has been an important security feature of Kubernetes for a long time. It was designed to provide a means of limiting the rights of pods on cluster nodes, allowing Kubernetes operators to reduce the risk of container breakout attacks. However, in v1.21, it was deprecated due to usability problems with its design. Now, in v1.25, it’s being removed entirely.
The in-tree replacement for this feature is Pod Security Admission, which is now generally available. This feature takes a different, simpler approach to applying restrictions on pods. Instead of hinging on user-defined policies, it allows cluster operators to apply one of three levels of Pod Security Standards on a namespace-by-namespace basis.
While Pod Security Admission will simplify the application of policies in some use cases, this less flexible design is likely unsuitable for cluster operators who have more complex requirements. In those cases, operators will need to replace or supplement Kubernetes' built-in controls with external admission control software. Fortunately, there are a wide range of strong open source projects in this field, including Kyverno, OPA Gatekeeper, jsPolicy, and Kubewarden.
Of course, implementing new external security functionality does bring its own risks, and admission control is no exception. To help cluster operators ensure that they’re deploying and maintaining admission controllers securely, Kubernetes SIG-Security released an admission controller threat model earlier this year.
Identifying Windows pods at admission
Kubernetes v1.25 also includes an important change related to Windows container security: the ability to definitively identify them during the admission process. The security settings that can be applied vary by each pod's operating system, so it’s important to know whether the containers in any given pod run Linux or Windows. With this feature enabled, pods can set the spec.os.name field to Windows, and this information will be passed to any admission webhooks used by the cluster.
Automatic CVE feed for Kubernetes
Another change in Kubernetes v1.25 isn’t so much a feature in the product as a useful addition to the security ecosystem: the alpha release of an auto-refreshing feed of Kubernetes CVEs. This should be very handy for ensuring that cluster operators and tool authors can easily access a definitive list of vulnerabilities, without having to monitor and scrape GitHub issues or Google Groups posts.
Network port ranges in network policies
Support for port ranges in network policies is landing in this release. Previously, Kubernetes network policies could only apply to single ports, which meant that cluster operators were forced to create a lot of entries if they needed to configure access to a range of ports. This is a useful enhancement that will help simplify the creation and maintenance of network policies that apply to wider ranges of ports.
User namespaces
An interesting feature landing in alpha with this release is support for user namespaces. This feature has been available in Docker for quite some time. Essentially, it allows processes to run as the root user (uid 0) inside a container, while from the host’s perspective, they are running as an unprivileged user.
The goal is to allow contained processes to carry out activities that require root privileges (e.g., package installation) without the risk of giving them excessive privileges to the underlying host.
While, in theory, this is purely a benefit to security, the implementation of user namespaces for unprivileged Linux users does introduce some concerns, as Linux kernel security issues could be more easily exploited when this feature is used (see CVE-2022-0815 for more details).
Conclusion
Any Kubernetes user knows that keeping up to date with the flow of changes is a perennial challenge—and this release is no different. Hopefully, most cluster operators have already started the process of moving on from Pod Security Policies, but this release should prompt them to seriously consider whether Pod Security Admission will meet all of their requirements—and, if not, determine which external admission controller would work best for their environments.
Beyond that, this release demonstrates that the world of container and Kubernetes security is still rapidly evolving, and cluster operators and software developers will need to keep a close eye on new features to ensure that their environments remain as secure as possible.
