Kubernetes security reaches maturity milestone with v1.25

Kubernetes Pod Security Policies were officially removed from version 1.25 this week in favor of the now-stable, slimmed-down Pod Security Admission. 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, has been in the works since late 2020. But this week's release finally carried out the removal of the former 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 graduate to stable or be removed.

Pod Security Policies were hobbled by a lack of clear scope for the project's API and the dual-policy enforcement mechanism it created by tying Pod access policies to user or Kubernetes service accounts.

Pod Security Policies have been replaced with Pod Security Admission, first introduced in version 1.22 last year, which graduates to stable status in version 1.25 this week. Pod Security Admission is an admission controller -- a Linux container that 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 Pod Security Standard namespace configuration labels developed by Kubernetes maintainers. These default 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 best practices for hardening security in Pod.

"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's security defaults comes with tradeoffs. Some of the more advanced features available through 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.

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.

"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 made available since Pod Security Policies were created that better handle advanced Pod authorization features. This includes 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' 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 the core project -- and supplemental tools surrounding it -- matures.

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 will be maintained separately by storage providers. This will mean simpler, faster feature development for both core Kubernetes and storage plugins, 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, she said. "Separating that capability will make it easier for new providers to adopt."

Rob Strechay

Kubernetes has now been in development for more than six years and attained industry domination as a standard for container infrastructure orchestration. Version 1.25 reflects Kubernetes maintainers' willingness to cede some territory to the third-party projects and vendors that sprung up around it, said Rob Strechay, an analyst at Enterprise Strategy Group, a division of TechTarget.

"It kind of boxes in Kubernetes to really focus on the core infrastructure layer," he 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.