Let's Play Kyverno
Foreword
“Kyverno is a policy engine designed specifically for Kubernetes."
While this approach makes it very easy to use Kyverno in its intended environment, it is sometimes difficult to explain and present the capabilities when that environment is not available.
To help potential users get started and reduce the effort required to test Kyverno and/or develop new policies, the Kyverno Playground has been developed. This has now been available for 3 weeks, currently in version 0.3.1.
This article explains:
- What is the Kyverno Playground?
- How was the Kyverno Playground created?
- How does the Kyverno Playground work?
- What additional features provides the Kyverno Playground?
Introduction
Having a booth at a conference and having direct contact with current and potential new users provides many opportunities. You can talk about how it works, existing and new features, use cases, and user challenges. However, many conversations often only scratch the surface because there has been no way to quickly and easily present a concrete feature or write a simple policy and demonstrate it right away.
In these situations, the desire for a playground as a simple, independent test environment to reduce these problems arose again. After KubeCon EU 2023, we expanded this idea and started developing a first prototype.
What is the Kyverno Playground?
Kyverno Playground is a web-based and isolated test environment for Kyverno. It is a standalone binary and does not require connection to a real Kubernetes cluster, but is optionally supported.
All the information to simulate a policy execution can be provided as YAML content in the respective panels. For a minimal setup, you only need to specify a resource and the policy you want to apply to it. All other information is optional or provides similar default settings as a real Kyverno installation.
How was the Kyverno Playground created?
Originally, we were going to use the Kyverno CLI under the hood, but then decided to use the Kyverno engine directly and develop everything around it from scratch. This allows us to close some gaps between the CLI and an actual installation, as well as provide more options in configuration and simulation.
We also wanted to decouple the frontend and backend so we could work on features independently and later bring everything together using a simple REST API. This gave us the most flexibility possible in developing and choosing the tools we needed in these two areas.
The frontend is based on Vue3 and uses Vuetify as a Vue component framework that simplifies the creation of a user-friendly and interactive interface. We also use monaco editor, which is also used in Visual Studio Code, to provide the best possible user experience for entering and working with YAML content.
For the backend, we use Go to integrate the Kyverno engine as smoothly as possible. The Gin Framework helps us to provide our API and UI via a file server.
How does the Kyverno Playground work?
Once the backend and frontend were set up, we were able to simulate the first policies on the new playground. To do this, each simulation sends all available information to a single REST API endpoint.
As we simulate the policy, resource, context, and engine configuration, we create a separate engine for each request. This ensures that all requests are independent of each other and that the provided configuration can be applied without having to reconfigure a single engine each time.
Before running the actual engine, the received YAML content must be parsed. To ensure that the provided content is not only valid YAML, but also valid Kubernetes resources, we use tools like kubectl-validate and OpenAPI schemas. This way, we can provide early feedback to the user and avoid misleading error messages.
After parsing and validation, we perform the actual engine operations in the same order as in a real cluster. This means that mutation and image verification are performed before validation of the resource. This behavior ensures that there are no errors due to dependencies of operations within a policy.
At the end, the engine returns a response with all executed rules that can be displayed in the frontend.
What additional features provides the Kyverno Playground?
Besides the basic idea of providing a simple testing environment, the Playground offers several features to further enhance the user experience and exploration of Kyverno.
Let’s take a look at a small selection of these available additional features.
Example Library
In order to give new users an interactive overview of what Kyverno can do and how different use cases can be achieved within the Playground, we decided to include a small sample library based on the extensive Kyverno Policy Repository. The examples provide a set of predefined policies and related resources and configurations for common use cases such as the Pod Security Standards and Best Practices.
The tutorials focus on features and how they can be simulated in the Playground, providing various examples such as upgrade operations, image verification, resource cloning, and more.
Share Functionality
In our daily work in the community, we often have situations where users need help with their policies. The process to get help has often been cumbersome because you need the ability to test the policy yourself. You have to figure out where the problem is and maybe try different things to get it to work. In the end, the user again has to test whether the policy works with their resources.
With the Share functionality, we have created an easy way to share a complete policy setup via the Playground. This includes the policy, an example of a validated resource, context information, and the engine configuration. Since all information is part of the created URL, this functionality is stateless, immutable, and does not expire. This makes it suitable for both short conversations and longer-lasting GitHub discussions and issues.
You want to open the exact same setup as shown in the Screenshot? No problem, we’ll share it with you!
Context (Variables)
Kyverno can run on various operations and uses request information such as usernames, groups, roles, and additional context from provided ConfigMaps, Secrets, and more. How could we provide this information within the Playground? We don’t have a true cluster request or other resources to pull the information from. We decided to take a simple approach and provide the ability to simulate what you need to provision for your policy.
In the advanced section of the Playground, you can change the context of your request and simulate variables that you would normally get from other resources or API calls.
Want to try out an example? Check out the Allowed Pod Priorities or Check ServiceAccount Example.
Conclusion
This article explained the story behind the Kyverno Playground, how it started, and where we are just three weeks later. We are really impressed with the initial feedback from our users and what we can already offer without having thought about it at first. We’re excited to see how these tools evolve and offer in function. We hope to get more feedback to improve and develop it further.