Rules Engine

Kubevious comes with an ability to support organizations needing additional rules beyond the built-in checks (such as label mismatch, missing port, misused or overused objects, etc.). It does that by allowing Kubernetes operators to define their own rules, and allowing organizations to enforce DevOps best practices without changing their existing release processes. The rules in Kubevious are continuously assured to be compliant to company policies and security postulates to be enforced. Rules are defined using a domain-specific JavaScript syntax to allow custom rules to be easily written and understood.

What is the Rules Engine?

The rules engine is a way to extend Kubevious to support organizations needing additional rules beyond the built-in checks that come with Kubevious by default (such as label mismatch, missing port, misused or overused objects, etc.). The rules engine is an extension for Kubevious to allow programmable validation and best practices enforcement for configuration and state objects in Kubernetes. In addition to raising errors and warnings, the rules engine allows for the assigning of custom markers to identify items of particular interest. Examples are: publicly accessible applications, containers that use excessive resources, overprivileged containers, and many more.

The rules engine enables organizations to enforce DevOps best practices without changing their existing release processes. Such rules can also help Kubernetes operators to be efficient day in and day out. Since the rules engine was built with customization in mind, applications can be continuously assured to be compliant to company policies and security postulates to be enforced. Rules are defined using a domain-specific language called Kubik. Kubik follows JavaScript syntax and comes with extensions to allow custom rules to be easily written and understood.

The easiest way to get started is to use a public library of community built rules from Kubevious Rules Library. While this page contains comprehensive documentation on writing custom rules, consider joining the Kubevious Slack Channel for any additional assistance.

Using Rules

Rules are defined against any object and configuration present in Kubevious UI, for example, Deployments, Pods, ConfigMaps, PersistentVolumes, Ingresses, and any other Kubernetes or synthetic configurations.

Rules consist of two parts: target scripts and rule scripts. The target script declares on which nodes of the diagram the validation rule be evaluated. The rules engine then passes along the selected nodes to the rule script, where nodes are validated, and the rules engine triggers errors and warnings, or labels them with custom markers on selected nodes.

Rule Editor UI

Rules are defined in the Rule Editor window of Kubevious. In the screenshot below, the rule latest-tag-check targets all docker images and checks if the latest image tag is used. For such images, an error is triggered.

An optional message can be passed to error to provide a more detailed description of the failure condition and sometimes remediation instructions.

The Affected Objects shows Images that are using the latest tag. Items on the list are shortcuts, and clicking on them would navigate to the diagram.

Clicking on the item in the Affected Objects list navigates to the diagram screen where the Image object is highlighted, with detailed properties and alerts rendered. In this view, operators can check for other relevant configurations such as image being used (the busybox in this case), docker repository and other properties.

Marker Editor UI

Sometimes classifying objects by errors or warnings is not sufficient. The Marker Editor allows assigning arbitrary icons to objects using the rules engine. They can be used for quick access or purposes of better categorization.

Just as in the case of the rule editor window, a list of items that match the condition is listed in the Affected Objects tab.