DEV Community

Cover image for Default Kyverno Policies for OpenEBS.
Nivedita Prasad
Nivedita Prasad

Posted on • Updated on

Default Kyverno Policies for OpenEBS.

Hey folks, In this blog we'll see how OpenEBS uses Kyverno to enforce security and validate policies.
As we know, PodSecurityPolicies(PSP) is being deprecated in Kubernetes 1.21 and will be removed in 1.25. So, the best alternative is Kyverno.

In case you're not aware of OpenEBS, PSP and Kyverno. Let me introduce you to these terms.

Let's begin!

What is OpenEBS?

OpenEBS is the leading open-source project for container-attached and container-native storage on Kubernetes and It adopts Container Attached Storage (CAS) approach, where each workload is provided with a dedicated storage controller.

It implements granular storage policies and isolation that enable users to optimize storage for each specific workload which runs in userspace and does not have any Linux kernel module dependencies.

What is PSP?

A Pod Security Policy is a cluster-level resource that controls security-sensitive aspects of the pod specification.

PSP objects define a set of conditions that a pod must run with in order to be accepted into the system, as well as defaults for their related fields. PodSecurityPolicy is an optional admission controller that is enabled by default through the API, thus policies can be deployed without the PSP admission plugin enabled. This functions as a validating and mutating controller simultaneously.

What is Kyverno?

Kyverno is an Open source policy engine designed specifically for Kubernetes. The word "Kyverno" is a Greek word for "Govern". It was originally developed by Nirmata and is now a CNCF sandbox project.

It can validate, mutate, and generate configurations using admission controls and background scans. Kyverno policies are Kubernetes resources and do not require learning a new language, we can easily define policies declaratively in YAML.

Another, more popular alternative to Kyverno is OPA (Open Policy Agent) /Gatekeeper.

What is OPA/Gatekeeper?

The OPA(Open Policy Agent) is an open-source, general-purpose policy engine that enforces validation of objects during creation, updating, and deletion operations. OPA lets us enforce custom policies on Kubernetes objects without manually reconfiguring the Kubernetes API server.

Want to know more about OPA, you can read this awesome blog!

Gatekeeper is a customizable admission webhook for Kubernetes that dynamically enforces policies executed by the OPA.
OPA Gatekeeper is a specialized project providing first-class integration between OPA and Kubernetes. Because of the relationship between Open Policy Agent with Gatekeeper, the project is often written "OPA/Gatekeeper" to acknowledge these ties.

OPA/Gatekeeper uses its own declarative language called Rego, a query language. You define rules in Rego which, if invalid or returned a false expression, will trigger a constraint violation and blocks the ongoing process of creating/updating/deleting the resource.

For more details, regarding Kyverno vs OPA/Gatekeeper you can read this blog:)

How do we use Kyverno for OpenEBS?

alt text

The Kyverno policies are based on the Kubernetes Pod Security Standards definitions. And, Pod Security Standard policies are organized in three groups:

  • Privileged
  • Baseline
  • Restricted

Kyverno has already defined policies under two categories Baseline and Restricted.

But, while applying these policies in OpenEBS, it blocks the creation of openebs-ndm because ndm requires privilege mode, it requires access to /dev, /proc and /sys directories for monitoring the attached devices and also to fetch the details of the attached device using various probes.

NDM(Node Disk Manager) is an important component in the OpenEBS architecture. NDM treats block devices as resources that need to be monitored and managed just like other resources such as CPU, Memory and Network. It is a daemonset which runs on each node, detects attached block devices based on the filters and loads them as block devices custom resource into Kubernetes.

Fig.1 - screenshot of openebs-ndm error

For that reason, we need policies in the privileged category.

"Privileged" mean here unrestricted policy, providing the widest possible level of permissions.

So, we have written eight privileged policies for OpenEBS.

Control Policy
Capabilities Allow Capabilities
Host Namespaces Allow Host Namespaces
Host Ports Allow Host Ports
Privilege Escalation Allow Privilege Escalation
Privileged Containers Allow Privilege Containers
SELinux Allow SELinux
/proc Mount Type Require Default Proc Mount
User groups Require User Groups

Let's look to our common points of policy specification:

kind: Policy
Enter fullscreen mode Exit fullscreen mode

Here the kind is Policy which means policies will only apply to resources within the namespace in which they are defined.

  validationFailureAction: enforce
  background: true
Enter fullscreen mode Exit fullscreen mode

These lines represent that this policy is going to be of an β€œenforced” nature which means that it will block any incoming resources which will violate this policy.

           - Pod
Enter fullscreen mode Exit fullscreen mode

These lines make sure that the policy only acts upon incoming requests of type Pod.

Now, steps to apply Kyverno policies in OpenEBS:

1.Install kyverno in your Kubernetes cluster.

kubectl create -f
Enter fullscreen mode Exit fullscreen mode

2.Apply Default kyverno policies for OpenEBS using

kubectl apply -f <filename.yaml>
Enter fullscreen mode Exit fullscreen mode

3.Check the default kyverno policies in the Kubernetes cluster using

kubectl get pol
Enter fullscreen mode Exit fullscreen mode

Fig.2 - screenshot of pol detail

4.After that install OpenEBS

kubectl apply -f
Enter fullscreen mode Exit fullscreen mode

Now, you'll see it's successfully installed and you can create any OpenEBS storage engine with kyverno policies.

With all this, kyverno policies for OpenEBS are ready to use!!:)


Kyverno is really awesome! In this blog, we saw how easy it is to create policy with kyverno. As it is Kubernetes-native, it is straightforward to write, operate and no new language is required to learn.
There are a lot of amazing things about Kyverno for detailed information, please refer to the official documentation.

It's an Open-Source Project, wanna contribute?

Go and explore the GitHub repository and make your contributions as well. You can also join the Kyverno slack channel to connect with the maintainers and other Kyverno community members.

That's all, hope you'll find this blog informative:)

If you have any feedback or questions, feel free to reach out to me on Twitter and I will be glad to help:)

Happy Reading!

Top comments (0)