Hello and welcome back!  In this new post I’ll be talking about  Kyverno and how to use it to automate the policy creation in Kasten to protect new applications.

Why do we need to automate the policy creation?

In a cloud-native organization is very common to have devops teams deploying new applications using CI/CD pipelines or IaC very frequently, which usually cause that the IT team struggles to provision the required data protection policies in a timely manner.  So, how can we be sure that every new application deployed in Kubernetes is properly protected with backup policy?  How can we automate the backup policy creation and enforce that policy in an efficient way?

Kasten can integrate with Kyverno (a Cloud Native Computing Foundation Sandbox project) to provide “guardrails” for these types of scenarios.  Kyverno implements a custom Kubernetes admission controller, which for instance, can prevent deployments, pods or StatefulSets from being scheduled onto a Kubernetes node when a Kyverno policy is violated.  In addition, Kyverno allows to automate the creation of new Kubernetes resources, including of course Kasten policies.


Installing Kyverno

Installing Kyverno is extremely easy, as you can see in the official documentation, basically using Helm.  If you want to install Kyverno in a high-availability configuration, all you need to do is running the following command:

Copy to Clipboard


Once Kyverno is installed, you can also install an optional chart containing the full set of Kyverno policies which implement the Kubernetes Pod Security Standards.

Copy to Clipboard


How Kyverno works?

Kyverno basically works using Cluster Policies.  In a ClusterPolicy you must do the following using YAML format:


So, for instance, we can have a ClusterPolicy to enforce that any Kubernetes application running in a production environment includes the proper settings to be protected by a Kasten Policy:

  • In the “rules” section, first you select the resources where this policy will be applied.  In this case it will be applied to any resource of type “Deployment
  • Then you define the rule type, in this case “validate“.  In a validation rule, one defines the mandatory properties with which a given resource should be created.
    • When a new resource is created, in this case a new Deployment, the properties of that resource are checked by Kyverno against the validate rule.
    • If those properties are validated, the resource is allowed to be created.
    • If those properties are different, the creation is blocked.
    • In this example, the rule will “validate” that the Deployment includes the following labels:  “dataprotection: k10-?*” and “immutable: enabled”
  • So, if a new Deployment is created, but this resource doesn’t include the labels “dataprotection: k10-?*” and “immutable: enabled”, then Kyverno will prevent this resource from being scheduled in the Kubernetes cluster.


Copy to Clipboard


So, what if now I try to deploy a new application (Deployment) but without including the required labels “dataprotection: k10-?*” and “immutable: enabled”?  Well, we should see an error like this:

So, in order to allow this application to run properly, we must add the required labels as we see in the picture bellow:


After this change, we will be able to create the Deployment and deploy and run the application in the Kubernetes cluster.    Now, at this point, the application is still not protected by Kasten, unless you already have a Kasten policy set to use the Labels defined in the application as a selector.  In the next section we will describe how to use Kyverno to automate the creation of Kasten policies when a new application is created.


Automate the Kasten Policy Creation with Kyverno

So far, we have seen how to use Kyverno to enforce that applications be deployed in Kubernetes includes certain specifications.  But Kyverno allows to do much more, and when talking about Kasten, Kyverno also allows (among other options) to automatically create a backup policy as soon as a new application is deployed in the Kubernetes cluster.

For the following example, I’ve created some Policy Presets in Kasten, which help to simplify the Policy creation process.  This presets are like templates that can be used to create new Policies based on these presets.  Some samples can be found in my github repository: https://github.com/prcerda/K10-Ansible-Install-Configure/tree/main/Ansible_K10TKG/policypresets

So, what will be doing next?  In the previous example we made sure the application included some labels in order to be allowed to be scheduled in the Kubernetes cluster using an “enforce” policy, but nothing more has been done so far, so the application is still not protected by Kasten:

Now, we will create an additional Kyverno ClusterPolicy to automatically create a new Kasten Policy, based on one of the policy presets I’ve already created.  The ClusterPolicy should look like this:

  • In the “rules” section, first you select the resources where this policy will be applied.  In this case it will be applied to any resource of type “Deployment“, which also must include all the required labels.
  • Then, we set “generate” as the rule type, which allows to create a new resource.
  • Finally, we define the Kasten policy settings, in this case using the Policy Preset called “golden-policy-preset”, and selecting the application based on the application’s namespace.


Copy to Clipboard


So, if now we deploy the application, in our case the pacman app, and we are using the proper labels, Kyverno will create the Kasten policy for us, following the settings specified in the Cluster Policy describe above.

As you can see, using Kyverno could be a very good option to make sure every new application is protected by Kasten as soon it is deployed in the Kubernetes cluster.  If you want to get some additional examples of how to use Kyverno with Kasten, you can check the following link: https://kyverno.io/policies/?policytypes=Kasten%2520K10%2520by%2520Veeam