DEV Community

Cover image for Enforcing Kubernetes Deployments: A Deep Dive into Policy as Code with Kyverno
Vinod Kumar
Vinod Kumar

Posted on • Updated on

Enforcing Kubernetes Deployments: A Deep Dive into Policy as Code with Kyverno

Introduction

This is an introductory blog on Cloud Native Computing Foundation's or CNCF’s incubating project called Kyverno (greek word which means ‘Govern’). In this blog, we will learn what Kyverno is and how we can leverage it in our Kubernetes cluster to ensure the security and governs of our application deployments.

Image description

Authorization in Kubernetes

Before heading to Kyverno, just a quick refreshment on how the authorization (or AuthZ) works internally in Kubernetes.
If you are a Kubernetes administrator then you can decide and customize different authorization modes in Kube API Server configuration. It is AlwaysAllow as shown below ( — authorization-mode=AlwaysAllow) however we can always change it to a different mode like AlwaysDeny, Node Authorizer, ABAC (attribute based), RBAC or WebHook. You can read more about each modes here but we are interested with the mode as WebHook where the authorization works with the help of the third-party popular engines like Kyverno or OPA (Open Policy Agent).

Kube API server configuration

An Admission Controller is the most critical module in Kubernetes that decides how an incoming request from a user/machine is validated before it grants the permission. Not just validation, the Admission Controller is also useful to implement the better security measures to protect the cluster.

Admission Controller

The Admission Controller performs ValidatingAdmissionWebHook and MutatingAdmissionWebhook.

Following is the flow when Kyverno is used in the cluster:-

Admission Controller using Kyverno

During these(Mutating/Validating Admission) phases of Admission Controller, we can consult the incoming request with the third-party policy enforcement engines like Kyverno to actually perform the mutation or validation based on the rules (or policies) defined.

Kyverno Overview

Kyverno is a Kubernetes-native policy engine designed to validate, mutate, and generate configurations for Kubernetes resources. Unlike the other popular enforcement engines like OPA, you do not need to learn a different language like Rego to write the policies. You can define the policies (as Code) natively just like another Kubernetes resources in YAML format.

Kyverno operates as an admission controller, enforcing custom policies when a resource is created, updated, or deleted. You can use Kyverno to enforce security best practices, manage resource quotas, apply custom validation rules, or even automate Kubernetes operations.

Architecture

Architecture

Kyverno Policies and Rules

A policy in Kyverno is a set of rule(s) where each rule consists of a match declaration with an optional exclude declaration and only one of validate, mutate, generate or verifyImages as child declarations, as shown below:-

Image description

A Kyverno Policy can be applied at cluster level (with kind as ClusterPolicy) or a namespace level (with kind as Policy). Once a policy has been applied then Kyverno enforces the best practices ensuring the governance in the cluster during the application deployments.

Application and Testing of Kyverno

This sample Kyverno policy is a cluster level policy (as the kind is ClusterPolicy) which ensures that all the deployments created in the cluster will be tagged appropriately with the specific label, app. And if not then it throws an appropriate error message because validationFailureAction=Enforce

Note, when validationFailureAction=Audit then Kyverno only warns but not fails the deployment.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-app-deployment-label
spec:
  validationFailureAction: Enforce 
  rules:
    - name: check-for-label
      match:
        resources:
          kinds:            
            - Deployment
      validate:
        message: "You must have the label, 'app' for all deployments."
        pattern:
          metadata:
            labels:
              app: "?*"
Enter fullscreen mode Exit fullscreen mode

This is just one simple example however you can create complex policies like image pull from authorized source, minimum number of replica count, no latest tag on images, etc. as required, refer to doc for more details.

Applying the Policy

To apply this policy, you need to:

  1. First install the Kyverno in your Kubernetes cluster. Your best friend here is the official documentation for installation, head towards this link
  2. Apply the policy using kubectl kubectl apply -f enforce-app-deployment-label.yaml
  3. Verify if the Kyverno cluster policy has been applied successfully or not
~ » kubectl get clusterpolicy                                                                                                                                                                                                                     
NAME                           ADMISSION   BACKGROUND   VALIDATE ACTION   READY   AGE    MESSAGE
enforce-app-deployment-label   true        true         Enforce           True    107s   Ready
Enter fullscreen mode Exit fullscreen mode

Testing the Policy

Let us now test the policy by creating a Deployment without the required label:-

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: vinod827/myawesomeapp:3.0
        name: my-simple-app
Enter fullscreen mode Exit fullscreen mode

When you try to creating it, the Kube API server will reject the request with an error message because it is missing the required app label:

~ » kubectl create -f deploy.yaml                                                                                                                                                                                                                 
Error from server: error when creating "deploy.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Deployment/default/my-app-deploy was blocked due to the following policies

enforce-app-deployment-label:
  check-for-label: 'validation error: You must have the label, ''app'' for all deployments.
    rule check-for-label failed at path /metadata/labels/'
Enter fullscreen mode Exit fullscreen mode

Conclusion

By using Kyverno for Webhook based admission control, the Kubernetes administrators can easily define and enforce custom policies on Kubernetes resources. It offers an intuitive, Kubernetes-native approach to managing policies like label enforcement, resource validation, and security policies, all while simplifying governance in cloud-native environments.

References

https://kubernetes.io/docs/reference/access-authn-authz/authorization/
https://kyverno.io/docs/installation/

Top comments (0)