By Lachlan Evenson, Principal Program Manager, Microsoft
In a world rife with uncertainty, adopting new tooling comes with important questions about security and compliance. The Kubernetes security story can be described as configurable, which means cluster administrators must make careful determinations about defaults and guardrails for their clusters. The complexity matrix for Kubernetes security and compliance has been daunting until recently, but the options have finally matured to allow for the necessary nuance and ease of use in today’s Kubernetes clusters. Let’s look at the Kubernetes policy story and see what’s right for your needs!
What Does Policy Solve?
Enterprises want many assurances, and high on the usual list is for projects to be open source, as open source encourages transparency and interoperability. Meanwhile on the cloud native maturity journey, microservice adoption grows and security teams begin to ask challenging questions: how do we ensure that all container images used on our Kubernetes clusters are from our internal trusted container registry? And how do we make sure all the resources deployed to a Kubernetes cluster are compliant with our Kubernetes security best practices? What do these intersecting needs for open source and security mean for policy on Kubernetes? Happily, the community anticipated this confluence of requirements, and came together to meet it.
Kubernetes Policy: Gatekeeper Origins
In late 2018, Kubernetes had piqued the interest of many organizations who wanted cluster orchestration but needed a solution to their policy and compliance concerns. Given the need for transparency, it was obvious from the outset that this solution needed to be built in open source. When responding to customer requests, the Azure team realized that instead of working in isolation, we could implement this policy controller work independently from any specific cloud provider or Kubernetes distribution, to allow customers flexibility.
In early 2019, Azure donated what became Gatekeeper, a policy controller for Kubernetes, to the CNCF under the Open Policy Agent umbrella of projects. Automating policy enforcement improves developer velocity with policy in mind, without sacrificing compliance. In building and delivering Gatekeeper v2 in collaboration with the community, we saw immediate feedback from the community which expanded the necessary scope for Gatekeeper. Back to the drawing board to build Gatekeeper v3! In mid-2019, the maintainers detailed policy and constraints for the Kubernetes blog; at that point, development on Gatekeeper v3 was just beginning.
How Does Gatekeeper Work?
The essential concept behind Gatekeeper is that two components are needed to define and enforce policy. A security administrator creates a constraint template – defined by Open Policy Agent – listing the fields or resources to constrain. Anywhere an image is defined, it can be reviewed in policy, and then a constraint can be created against that policy to define what is allowed. The constraint and constraint template together can enforce policy. Try Gatekeeper out today to see these concepts in practice; installation and usage examples are available on GitHub.
How does Gatekeeper Differ from Pod Security Policy?
Kubernetes ships with a beta API called Pod Security Policy (PSP) that can be used to enforce security-related concerns. After numerous discussions, the Kubernetes community recently determined it would deprecate Pod Security Policy in favor of solutions like Gatekeeper that allow more flexibility and scalability. A driving reason for the deprecation of PSP is the impossibility of scoping the surface area of the API, which means that there will always be “just another field to add”. Additionally, the scope of PSP does not scale to other resources outside of a Pod, which limits the policy and compliance surface area that PSP can support.
When compared to PSP, the scope of Gatekeeper is much larger than just security, and can be applied to platforms beyond Kubernetes. To simplify adoption of Gatekeeper, the community maintains a list of policies that represent the same functionality that Pod Security Policy provides; ongoing work with mutation will bring Gatekeeper to complete feature parity with PSP. The community anticipates that managed services and packaged solutions will move forward with Gatekeeper.
What’s Next?
Gatekeeper v3 published its first stable release in August 2020, with active development continuing; the current stable release is 3.1.0. Now that Gatekeeper v3 is ready to handle production policy and compliance needs, the maintainer community has set several roadmap goals to expand on the feature set.
- Mutation is a key use-case requested by the community; mutation would allow policy owners to modify resources on-the-fly if they aren’t initially in compliance. A typical example would be the addition of organizational labels to Kubernetes resources.
- Discussion has begun around building a Kubernetes operator for managing Gatekeeper.
- Collaboration has begun on a community-owned policy library that covers the most common policies created by users. This library would allow portability and consistency of policies in the ecosystem and create a repository for best practices and additional tooling to emerge.
To learn more about Open Policy Agent, you can participate in a community call, join the Slack channel, and view these upcoming KubeCon NA 2020 sessions:
- Open Policy Agent Intro – Patrick East, Styra & Rita Zhang, Microsoft
- Secure Policy Distribution With OPA – Ash Narkar, Styra
- Using Open Policy Agent to Meet Evolving Policy Requirements – Jeremy Rickard, VMware
Today, Open Policy Agent is an incubating project in the CNCF and has applied for graduation. Moving forward to CNCF graduation signals to the ecosystem that a project is ready for large-scale adoption. Kubernetes projects needing policy implementations can move forward with confidence, as open source tools like Gatekeeper are purpose-built for the policy and compliance needs in your Kubernetes environment.
##
***To learn more about containerized infrastructure and cloud native technologies, consider joining us at KubeCon + CloudNativeCon NA Virtual, November 17-20.
About the Author
Lachlan Evenson Principal Program Manager, Microsoft
Lachlan is a Principal Program Manager on the Container Compute team at Azure. He has spent the last few years working with Kubernetes and enabling Cloud Native journeys. Lachie serves as a Cloud Native ambassador and TOC contributor, and has deep operational knowledge of many Cloud Native projects. “
