kras99 - stock.adobe.com
A CNCF policy-as-code project has emerged among the tools IT pros can fall back on as upstream Kubernetes security begins a significant transition.
Kubernetes Pod Security Policies (PSP), implemented via a built-in admission controller, were used in earlier versions of the container orchestration platform to limit Pod access to authorized users. However, the utility had languished in beta for years, and was deprecated as of the container orchestration platform's 1.21 release in April.
With version 1.22 this month, a new project, Pod Security Admission, was introduced in alpha that will be a partial successor to Pod Security Policies. Pod Security Policies will be fully removed from upstream Kubernetes in version 1.25 next year.
PSP's replacement, Pod Security Admission, still uses an admission controller, but it will have a more limited scope than PSP.
"[Pod Security Admission] replace[s] PodSecurityPolicy without compromising the ability for Kubernetes to limit privilege escalation out of the box," according to the project's documentation. "Specifically, there should be a built-in way to limit ... pod permissions so they are not equivalent to root-on-node (or cluster)."
In the meantime, cloud-native application security is under intense scrutiny as enterprises struggle to implement DevSecOps practices and major security breaches continue to make headlines. Against this backdrop, IT teams that need advanced admission controller functions, such as resource quotas, role-based access to pods, identity-based authentication and authorization, and network policies, must turn to one of several external admission controller projects before PSPs disappear in Kubernetes 1.25.
Kyverno emerges among PSP alternatives
While pod security policies got stuck at the beta phase, separate open source admission controller projects emerged, including Gatekeeper, based on the Open Policy Agent; open source alternatives such as k-rail and magtape; and as of last year, a Cloud Native Computing Foundation (CNCF) sandbox project called Kyverno.
The rise of these externally developed admission controllers was among the factors that led to the deprecation of pod security policies and the decision to start over with a simpler replacement, according to a Kubernetes maintainer's blog post.
"Since there is a robust ecosystem of external admission controllers already available, PSP's replacement doesn't need to be all things to all people," wrote Tabitha Sable, co-chair of the Kubernetes SIG-Security group, in April.
Open Policy Agent (OPA), which quickly rose to prominence among large enterprises two years ago, uses a language called Rego to create policy code. Alternatives such as k-rail are written in Golang. Kyverno, which was donated to CNCF in October 2020, uses YAML, the same language used by Kubernetes itself.
A platform engineering team at retailer Williams-Sonoma Inc. is among the early adopters of Kyverno, which it chose over OPA a year ago because Kyverno uses commands already familiar to Kubernetes operators.
Gregory MayInfrastructure Architect, Williams-Sonoma Inc.
"Before Kyverno, we had our own custom abstraction layer where [development] teams could self-provision a [Kubernetes] environment," said Gregory May, an infrastructure architect at Williams-Sonoma. "All of the components we used for policy-based namespace provisioning sat outside the container platform and were cobbled together from different open source tools like Terraform and Jenkins."
Kyverno's Kubernetes-based admission controller eliminated an intermediate API the custom abstraction layer had used, streamlining the container provisioning process for May's team.
Replacing PSP wasn't the motivation for May's team to deploy Kyverno, since PSP deprecation came later. However Kyverno will minimize the impact of the transition to Pod Security Admission upstream, he said.
"It's nice to already have this deployed," May said. "We wouldn't have a solution for [PSP deprecation] otherwise."
Proponents of OPA tout the fact that its policies can be applied to IT resources both within Kubernetes and well beyond it. Kyverno, meanwhile, is optimized for use within Kubernetes, a relatively limited scope, but without the complexity of the Rego policy language. Both approaches have their fans.
"Kyverno has all we need," May said. His team is also evaluating VMware's Tanzu Mission Control, which builds on OPA, but as of now plans to stick with Kyverno for automating namespace deployments.
Nirmata Inc. banks on Kyverno
Kyverno emerged from a policy module developed by a Kubernetes hosting vendor, then called Nirmata Container Solutions, in early 2018. Later that year, the company rebranded as Nirmata Inc. and created a version of that policy module based on Kubernetes custom resource definitions in 2019. This project, dubbed Kyverno, was donated to the CNCF in October 2020.
Kyverno's growth in the open source community prompted another shift in direction for Nirmata, which now markets the Nirmata Policy Manager (NPM) for Kyverno alongside its eponymous Kubernetes management platform. This month, Nirmata received $3.6 million in pre-series A funding to explore a new go-to-market strategy focused on NPM and the Kyverno project.
This is a smart move for a small vendor in a Kubernetes platform market already dominated by large IT vendors such as Red Hat and VMware, according to Jay Lyman, an analyst at S&P Global's 451 Research, in a 2021 Market Insight Report on Nirmata.
"Nirmata's work with open source software such as Kyverno and communities such as Cloud Native Computing Foundation (CNCF) working groups will likely pay off in the form of broader use and deeper integrations and partnerships," Lyman wrote. "The company will have to fully leverage those because it is among the smaller players in a Kubernetes market landscape populated by the public cloud behemoths and deeply established enterprise vendors."
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.