At Monokle, we care about helping developers like you be more productive while working with Kubernetes. A big part of that mission is helping you spend far less time debugging and fixing common errors early in the deployment process.

You know the type—indentation, typos, misspelled resource names, invalid output from Helm or Kustomize to name a few. With Monokle, we help resolve these pain points straight away by checking off one more annoyance in your pre-deployment workflow on our way to achieve our mission of making your Kubernetes development experience joyful.

But as we work toward our goal of making configuration tasks easier to manage, we are very aware that not all errors are simple annoyances. Your organization likely maintains specific policies and best practices built around issues like cloud costs, security, and data privacy. These might come from internal discussions spearheaded by your CTO or cloud native best practices using an open-source validator tool from the Cloud Native Computing Foundation (CNCF).

These rules (and associated errors) are worthy of your attention and time, but that doesn’t mean that policy enforcement has to be an enormous burden on your productivity.

We believe in validating your work around complex errors before deploying so you spend less time fixing them. So in our Monokle 1.7.0 release we added support forOPA (OPA) to automate how you validate, identify, and fix mission-critical Kubernetes errors.

What is Open Policy Agent?

Open Policy Agent, also referred to as OPA, is an open source general purpose policy engine for building specific policy enforcement across an organization's development stack.

OPA policy allows Kubernetes development teams to define rules on exactly how their systems should behave, but without hardcoding those rules directly into the code itself. Instead, you query OPA with the rules you’re looking to apply and the code you want tested, and it gives you a pass/fail result.

OPA-driven policy decisions are entirely up to your organization. They can cover “simple” rules like requiring labels to complex directives like security, cloud costs, and best practices around availability.

What OPA rules does Monokle include?

We added automatic OPA validation directly into Monokle to keep your development workflows streamlined. No more context switching or worrying about whether you’re violating a cloud native best practice when you’re finally ready to deploy to your cluster.

We implemented rules developed by the DefSec team at Aqua Security—we’re grateful for their hard work and OPA expertise to help Monokle users get up and running with OPA.

The full list of rules can be found in our documentation, but here are some examples and their of various levels of severity:

• SYS\_ADMIN capability added: Processes in your containers can use root-like privileges.
• hostPath volume mounted with docker.sock: Your container can have full root access to its host system.
• Accessto host network: Processes in the pod to communicate with processes bound to the host's loopback adapter.
• CPU notlimited: Can create resource exhaustion during a DDoS attack.

How to enable and use OPA with your Kubernetes configuration files

If you don’t have Monokle yet, install the desktop app! We support macOS, Windows, and Linux, and it only takes a few clicks to see all your Kubernetes resources in Monokle.

Enable OPA policies

Monokle’s OPA features work with your vanilla Kubernetes manifests, the output from Helm charts or Kustomizations, and cluster resources. To integrate OPA into your workflows, start applying and viewing OPA rules by clicking the *Validate Your Resources* button located on the left-hand navigation menu, then the *Configure* button under the Open Policy Agent heading to view the list of available rego policies.

We recommend you enable them all with the *Enable all*button, and then disable those that cause too much headache or don’t work with your team’s policies. You can sort policies by their ID or severity to target your search and enable those most relevant to your organization. Just click the toggle button next to any policy to enable or disable it.

Validate your manifests and resources against OPA policies

Once you’ve enabled a policy, Monokle gets started validating all configuration files and cluster resources in the background—there’s nothing else to enable or configure.

As you develop a vanilla manifest, Monokle marks code that violates a given policy with a red error icon, just as it does with the "simpler" syntax errors mentioned earlier. Hover over that icon to see what OPA policy you’re violating, along with advice on fixing your manifest.

As you make changes, Monokle keeps querying OPA with your code until you meet your organization’s best practices, and poof—the error disappears in real-time!

But Monokle takes the use cases even further. Since OPA validation works with Helm/Kustomize output too, you can test those outputs before you try deploying any generated config files, objects, or resources. Monokle also lets you inspect your existing clusters for OPA errors, which helps you retroactively fix invalid manifests you deployed before implementing OPA policies or having the right tool to identify them quickly and easily.

Now that you can see OPA validation errors directly in Monokle, you don’t have to juggle more development tools, waste time deploying code that ultimately doesn’t meet your organization’s standards, or fret over rolling back a production deployment. Monokle’s OPA capabilities help reduce complexity of pre deployment configuration tasks and maybe even makes working with K8s objects and resources fun—well, easier for sure!

What’s next with Kubernetes configuration workflows?

We’re working non-stop listening to user feedback as we add new features and capabilities to Monokle with the vision of reducing your time working with YAML to a minimum so you can get back to what you enjoy most, coding!

Try Monokle and get our new releases directly to your desktop. Download for macOS, Linux, and Windows. It’s entirely free and open-source complete with an MIT license.

Learn more about how to createYAML Manifestsin Monokle and once you’ve spent some time leveraging Monokle to validate and fix your errors—whether syntax or OPA related—we invite you to stop by our Discord Server to give us feedback.

Our engineers, DevRel, and product team are all active in this space and are happy to discuss implementing more OPA policies, new options for letting you build custom plugins for your organization, or other pains that we can help you resolve in your pre deployment workflows.