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

Introduction
#

This blog introduces Kyverno, an incubating project under the Cloud Native Computing Foundation (CNCF). We will explore what Kyverno is and how it can be leveraged in Kubernetes clusters to ensure security and governance during application deployments.

Authorization in Kubernetes
#

Before diving into Kyverno, let’s refresh our understanding of how authorization (AuthZ) works internally in Kubernetes. As a Kubernetes administrator, you can customize different authorization modes in the Kube API Server configuration. One such mode is AlwaysAllow (--authorization-mode=AlwaysAllow), but it can be changed to other modes like AlwaysDeny, Node Authorizer, ABAC (attribute-based), RBAC, or WebHook. We are particularly interested in the WebHook mode, where authorization works with the help of third-party engines like Kyverno or OPA.

An Admission Controller is a critical module in Kubernetes that validates incoming requests before granting permissions. It not only handles validation but also implements security measures to protect the cluster.

Kyverno Overview
#

Kyverno is a Kubernetes-native policy engine designed to validate, mutate, and generate configurations for Kubernetes resources. Unlike other enforcement engines like OPA, Kyverno allows you to define policies natively in YAML format, similar to other Kubernetes resources, eliminating the need to learn a new language like Rego.

Operating as an admission controller, Kyverno enforces custom policies during the creation, update, or deletion of resources. It can be used to enforce security best practices, manage resource quotas, apply custom validation rules, or even automate Kubernetes operations.

Architecture
#

Kyverno Policies and Rules
#

A policy in Kyverno is a set of rules, where each rule consists of a match declaration with an optional exclude declaration and one of the following child declarations: validate, mutate, generate, or verifyImages.

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

Application and Testing of Kyverno
#

Below is a sample Kyverno policy, a cluster-level policy (ClusterPolicy), that ensures all deployments created in the cluster are appropriately tagged with the specific label app. If not, it throws an appropriate error message because validationFailureAction=Enforce.

Note: When validationFailureAction=Audit, Kyverno only warns but does not fail the deployment.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-app-deployment-label
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-for-app-label
      match:
        resources:
          kinds:
            - Deployment
      validate:
        message: "The 'app' label is required for deployments."
        pattern:
          metadata:
            labels:
              app: "?*"

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:

First install the Kyverno in your Kubernetes cluster. Your best friend here is the official documentation for installation, head towards this link Apply the policy using kubectl kubectl apply -f enforce-app-deployment-label.yaml 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

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

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/'

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.