The Issue

A while ago I was chatting to Michael Cade, and we pondered the question “How do we ensure Kasten is protecting a newly deployed application in our Kubernetes environment”.

We chatted about how one of the best ways to make your Kasten protection policy flexible is by using metadata labels.

We came up with the simple idea: “What if something forces a known label on the metadata of any applications deployed by our developers in the future?”

This blog post covers this use case using Tanzu Mission Control with custom policies.

The Solution

One of the products we can use to enforce labels on a Kubernetes resource is Open Policy Agent Gatekeeper. Which is an external admission controller which allows you to create policies for the admission of resource creation/changes/updates based on a criteria.

• OPA policies are expressed in a high-level declarative language called Rego. (Pronounced “ray-go”.)

Tanzu Mission Control, the fleet management SaaS tool for managing your Kubernetes platforms, provides you the ability to create policies of various types to manage the operation and security posture of your Kubernetes clusters and other organizational objects, implemented by using the OPA Gatekeeper.

Implementing The Solution

For this solution “art of the possible” blog post, we are going to keep it really simple, and implement a policy which covers the following:

• For any Namespaces deployed by our developers which have the label “app: production” we also want to ensure that there is a label with the key value “kasten”
• Our Kasten protection policy will be configured to protect resources identified with the label key “kasten” and a specified value.

First let’s create our Kasten protection policy first, I won’t go through this step by step but here you can see it is created to protect resources with the label “kasten: backup-default”

In Tanzu Mission Control, I am going to create a custom policy against my TKG cluster (other Kubernetes clusters will also work).

• Click Policie
• Custom Policies tab
• You can select to create the policy at either: organisation level, cluster group level, or cluster level
• Click to create the custom policy

Handily, Tanzu Mission Control provides you an out of the box “Require labels” example to use. However, under the Templates sections on the left hand navigation pane, you can create your own OPA Rego templates to be used for any type of custom policy you need.

• Select the custom policy “tmc-require-labels”
• Provide a name for the policy
• Set the targeted resource as necessary
  • For my example I’ve used the namespace
  • Make sure you click the “Add Resource” button

• Under Parameters
  • Set the Labels you expect to be present
  • An associated value is optional
• Select which Namespaces to include or exclude from the policies
  • In my test, I just wanted to include label selectors which identified my production applications
• Click to create the policy

On my Kubernetes cluster I can see the deployed gatekeeper under the namespace “gatekeeper-system”.

And I can run “kubectl get constraints” to see the configured constraints on my cluster.

Testing The Solution

With this custom policy configured, any namespace that I create with a label of “app: production” will not be created unless it also as a label where the key is “kasten”.

In the below example outputs, I’m using this test application, I have altered it slightly to create the namespace as part of the YAML. Below is my first attempt.

You can see when I deploy the YAML file, it fails due to the missing expected label key in the metadata, and the error output from the admission controller is quite detailed as well.

Error from server ([denied by tmc.cp.kasten-label-required] You must provide labels with keys: {"kasten"}): error when creating "yelb.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by tmc.cp.kasten-label-required] You must provide labels with keys: {"kasten"}

If I now alter my YAML file, to add in the additional label, the creation of the application will be successful.

Now if I go into my Kasten dashboard and run the protection policy, it will be successful capturing the components under the Yelb namespace, identified from the label.

I can also see the webhook failures for trying to create the application in my logs on vRealize Log Insight Cloud, so these items can be captured centrally as well.

Wrap Up

This was a simple idea to concept “how can we ensure Kasten is protecting our applications”. But hopefully it shows you some of the power of TMC custom policies, and you can also achieve the same outcome by running OPA on your Kubernetes cluster, however you don’t get the nice UI.

From a Kasten perspective, it ensures your developers are aligning resource deployments to match your backup selection policies as well.

Some resources you might find useful:

• Kasten
  • Application Selections and Exemptions
• Tanzu Mission Control Documentation:
  • Blog Series – Getting started with Tanzu Missing Control
  • Policy-Driven Cluster Management
  • Creating Custom Policies
• Open Policy Agent Documentation:
  • OPA introduction
  • Understanding OPA Policy Language
  • Rego Playground

• Blogs:
  • 5 tips for using the Rego language for Open Policy Agent (OPA)
  • Introducing Policy As Code: The Open Policy Agent (OPA)
  • Blog Series – Open Policy Agent, Part I — The Introduction
  • OPA Rego in a nutshell
  • 5 Things You Didn’t Know About Open Policy Agent

Regards

Follow @Saintdle

Dean Lewis