Kubernetes security reaches maturity milestone with v1.25
Kubernetes Pod Security Admission has reached stable status, replacing Pod Security Policies, as the core Kubernetes framework delegates advanced features to the wider community.
Kubernetes Pod Security Policies were officially removed from version 1.25 this week in favor of the now-stable, slimmed-down Pod Security Admission -- and security isn't the only area where core Kubernetes is delegating advanced features to external community projects and vendor products.
The deprecation of Pod Security Policies, which had languished in beta since Kubernetes version 1.3 in 2016, had been in the works since late 2020. But this week's release finally carried out the removal of the erstwhile Kubernetes security defaults. The removal was prompted by a new project policy as of version 1.19 limiting how long features could stay in beta before they must be graduated to stable or removed. Pod Security Policies were hobbled by a lack of clear scope for the project's API and the fact that it created a dual-policy enforcement mechanism within the framework by tying Pod access policies to user or Kubernetes service accounts.
Now, Pod Security Policies have been replaced with Pod Security Admission, first introduced in version 1.22 last year, which graduates to stable status with version 1.25 this week. Pod Security Admission is an admission controller -- a Linux container which intercepts requests to the Kubernetes API Server and governs how a cluster operates.
The new admission controller applies access restrictions to Kubernetes Pods based on three default Pod Security Standard namespace configuration labels developed by Kubernetes maintainers. These standard labels are privileged, baseline and restricted. Privileged is an unrestricted policy; baseline is minimally restrictive, but prevents privilege escalations that create security risks. Restricted follows the Kubernetes community's Pod security hardening best practices.
"Pod Security Admission was designed to make it easier to enforce Pod Security Standards without users having to understand each and every security-related field [within the] pod specification," said Cici Huang, a software engineer at Google and the release lead for version 1.25.
Simplifying Pod security defaults comes with tradeoffs -- some of the more advanced features available with Pod Security Policies are no longer included in Pod Security Admission, such as the ability to make changes to Pods before validating their access. Pod Security Admission also doesn't enforce policies in finer detail than the namespace level.
"Even if Pod Security Admission does not meet all of your needs, it was designed to be complementary to other policy enforcement mechanisms, and can provide a useful fallback running alongside other admission webhooks," Kubernetes documentation stated (emphasis in the original).
There are several tools that have become available since Pod Security Policies were created that better handle advanced Pod authorization features, including separate open source admission controllers such as Kyverno, Kubewarden and OPA Gatekeeper. All three projects are mentioned by name in Kubernetes documentation for users looking to replace Pod Security Policies' more advanced features.
"For people who really want all the more powerful features, there are already a lot of external admission controllers available in the Kubernetes ecosystem which are well-maintained and supported," Huang said. "But there are also benefits to the built-in defaults being maintained by the community. ... In the future, you'll get built-in updates to policies for free whenever a new feature is added to Kubernetes."
Streamlined core Kubernetes strips out CSI plugins
Overall, the balance is shifting between core Kubernetes and the surrounding ecosystem as mainstream enterprises put containers into production, and both the core project -- and the supplemental tools that surround it -- mature.
Another example of this in Kubernetes 1.25 is a separate, years-long effort to break out integrations between Kubernetes and external data storage systems from the core framework, dubbed Container Storage Interface (CSI) Migration. CSI Migrations are among 14 features that reached stable status with this week's release, for Google Cloud Persistent Disk and Amazon Elastic Block Store volumes. These migration mechanisms will move storage driver specifications from the main Kubernetes API, and they will be maintained separately by storage providers instead.
This will mean simpler, faster feature development for both core Kubernetes and storage plugins in the future, Huang said.
"If a new [storage] provider wants to come in and support Kubernetes [under the previous model], it's a little bit harder because they have to put their code inside the core code base," and wait for the core code base's quarterly release schedule, Huang said. "Separating that capability will make it easier for new providers to adopt."
Kubernetes has now been in development for more than six years and has attained industry domination as a container infrastructure orchestration standard. The version 1.25 release reflects Kubernetes maintainers' willingness to cede some territory to the third-party projects and vendors that have sprung up around it, said Rob Strechay, an analyst at ESG, a division of TechTarget.
"It kind of boxes in Kubernetes to really focus on the core infrastructure layer," Strechay said. "They can focus on making it simpler, and on being proactive about the features they build in."
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.
