Kyverno - Policy Management in Kubernetes

July 23, 2021
Share this post:
Kyverno - Policy Management in Kubernetes

When the PSP policies in Kubernetes are near their deprecation, with this article by Squadcast, you will learn a different approach for governing your Kubernetes cluster security using Kyverno - a policy management tool.

Table of Contents:

    What is Kyverno?

    Kyverno (Greek for “govern”) is a policy engine explicitly designed for Kubernetes.

    It was created by Nirmata and is currently running as a CNCF sandbox project.

    Kyverno can be used to:

    • Enhance cluster security
    • Set default policies and rules
    • Audit or enforce set rules
    • Validate resources
    • Mutate resources before applying
    • Generate policies
    • Manage pod security

    When Kyverno is deployed in a cluster, it will create validating and mutating webhooks and run as an admission controller inside the cluster.

    Meaning any command issued towards the Kubernetes API will first be intercepted and run through Kyverno to check, mutate, or validate the request.

    Image Source: CNCF Kyverno Webinar

    The great thing about Kyverno is that it uses Kubernetes type of custom resource definitions, and every policy can be simply defined in a YAML file. Without learning complex languages or queries.

    Defining the policies in Kyverno is easy, and you will find that it is very much similar to any other Kubernetes object definition.

    Opposite of OPA Gatekeeper, Kyverno is much simpler to use and start with; however, it’s worth mentioning that the OPA Gatekeeper can give you much finer control if that’s what you are after.

    This article will cover all policy types by Kyverno and how to apply them to your cluster. But first, let’s install Kyverno.

    Installing Kyverno

    Installing Kyverno can be done directly by applying the manifests or through the official Helm chart.

    This article will explain the installation steps using Helm.

    Before installing, it’s a good idea to assess and evaluate how you want the security and policy enforcement to be run inside your cluster.

    The two suggested settings to consider before installing are the podSecurityStandard and validationFailureAction.

    The podSecurityStandard is a setting that controls the Pods security profile, based on the existing, but soon to be deprecated Kubernetes Pod Security Standards.

    You can choose from the three options available:

    • Baseline - minimal restriction meant to block common privilege escalation
    • Restricted - much higher security standard, provides further hardening of the cluster
    • Custom - the policies can be customized and adjusted to fit your needs

    By default, if no option is specified when installing Kyverno with Helm, the Baseline profile will be selected.

    The validationFailureAction setting has two options; you can set it in enforce or audit mode.

    When set to enforce, if a policy violation occurs due to the set pod security, the request will be blocked.

    In audit mode, the resource request will be allowed, and the policy violation will be logged. Audit mode is the default setting if not specified otherwise.

    Add the Helm repository and run an update:


    "kyverno" has been added to your repositories


    Hang tight while we grab the latest from your chart repositories...
    ...Successfully got an update from the "kyverno" chart repository

    It’s best to Install Kyverno in its own namespace. And for the pod security options, you can install them based on the level of security you want to achieve.

    From the Helm chart, we will go with the defaults for the policy settings.


    If the install is successful, you will be greeted by the install notes and an output from the policy setup.

    “We have installed the "baseline" profile of Pod Security Standards and set them in audit mode.”

    You can check on the Kyverno pod with:


    kyverno-5567697bf8-745ml 1/1 Running 0 84s

    And the installed baseline profile policies with:

    disallow-add-capabilities true audit
    disallow-host-namespaces true audit
    disallow-host-path true audit
    disallow-host-ports true audit
    disallow-privileged-containers true audit
    disallow-selinux true audit
    require-default-proc-mount true audit
    restrict-apparmor-profiles true audit
    restrict-sysctls true audit

    Policy types in Kyverno

    In Kubernetes, there are two types of webhooks: the Mutating and Validating webhooks.

    However, when Kyverno is installed as an admission controller, it offers one additional option along with the validating and mutating webhooks; it also has policy Generation, which can be used to generate configuration based on some event.

    We will explain all three types for you to understand them better, when they are used, and why.


    When a request is sent, with the validation type of policy, it will first be validated via the admission controller; and based on its binary result status, a response will be sent back either accepted or rejected.

    For example, you can create a policy for configuration validation and set it so that the images in your cluster are downloaded only from allowed registries. The action can be logged on violation in audit mode, or enforced to block the request if it’s against the policy rule.


    When the request is sent towards the Kubernetes API, if the object isn’t conforming to the set policy by Kyverno, it will be mutated and adjusted before getting applied and written to the ETCD database.

    Mutating webhooks can also be validating ones since if a request doesn’t follow the policy rule, it won’t get rejected but modified and fit to the policy. That way, the effective “validation” will return pass, and the object will be stored in the database.

    With the mutation webhook, there are three ways to modify the request.

    It can be done via the JSON patch approach, strategic merge that Kubernetes uses, or by a set conditional for the desired end state.

    Before creating a Deployment in Kubernetes, you may like to have a specific label attached. Even if you forget to add it before applying the configuration, the mutating webhook will add it for you before creating the resource.


    As mentioned before, Kyverno can be used to generate a policy based on some event in the cluster.

    This type of policy is helpful if you like some default configuration to be set based on updates or the creation of other resources.

    Later an example will be given how this type of policy generation can generate Limit Ranges for each created namespace.

    Creating policies in Kyverno

    Enough with the theory. Let’s have a look at each type of the policies and test them out.

    Validating policy

    Consider the following validation policy:


    You’ve already guessed what it does and what the options are, but let’s explain the fields and their values.

    The object kind defines that this is a cluster scoped policy. Meaning every Deployment, from every namespace will be affected.

    For validationFailureAction - the options are audit or enforce. Here, we have it set to enforce. You want the request blocked if the Deployment doesn’t have the proper labeling.

    Under the rules, you define what to match the policy against and what you want to validate.

    In this case, you will be matching a resource of kind Deployment, and the validation will be checking for the label company=squadcast.

    If this label isn’t set, the request will be blocked, and the admission controller will display a message to inform you of the reason.

    Now save the file and apply it to the cluster:

    <p>CODE:</p> created

    Once that is applied, try to create a deployment without specifying a label.

    You can quickly test this using the imperative approach:

    <p> CODE:</p>

    error: failed to create deployment: admission webhook "validate.kyverno.svc" denied the request:
    resource Deployment/default/webhook-test was blocked due to the following policies
      require-deployment-label: 'validation error: Every Deployment object must contain
        the company label. Rule require-deployment-label failed at path /metadata/labels/company/'

    Success! The request didn’t pass since you haven’t specified the required company label.

    Try again, but this time add the company=squadcast label:


    Save it and apply it:


    deployment.apps/webhook-test created

    This time the Deployment passed. Excellent!

    You can take a look at other validating policy examples here.

    Mutating policy

    You can take the above example from the Validating policy and change it, so it mutates the request and adds the required label automatically if it’s missing.

    If you want to append a label to Deployments while applying or updating an object, you can do so with the following policy.


    Notice something missing?

    The validationFailureAction field isn’t needed anymore because if the required label is missing, the webhook will automatically mutate the request and apply it. You’ll also notice that there will be no message displayed as well.

    Under rules instead of validate, we now have the mutate field that describes the patch that will happen if the Deployment doesn’t contain the required label. This type of patching uses the JSONPatch method.

    <p>CODE:</p> created

    Try once again with the previous command to verify that the labeling will be automatically added.


    And verify:


    mutate-test 1/1 1 1 8s app=mutate-test,company=squadcast

    You can also check the Kyverno logs on which action has been taken.


    [other output truncated]
    I0712 20:03:10.113126   1 mutation.go:109] WebhookServer "msg"="mutation rules from policy applied successfully" "action"="mutate" "gvk"="apps/v1, Kind=Deployment" "operation"="CREATE" "resource"="default/Deployment/mutate-test" "policy"="add-deployment-label" "rules"=["add-deployment-label"]

    There it is, there was a successful mutate action on the Deployment - mutate-test, under the policy add-deployment-label.

    Finally, let’s check out the third option that Kyverno offers for policy generation.

    Generating policy

    With the Generating policy, you can generate configurations based on specific object creation or updates.

    Examples would be: setting up default limits or requests on Namespace creation, adding labeling, Quotas, Network Policies, etc.

    In this example, you will create a policy that will automatically generate Limit Ranges on namespace creation.

    In short, Limit Ranges are used to define specific requests and limits that can be tied to namespaces and based on CPU, memory, or storage. The LimitRanger admission controller enforces the specified limits in the policy.

    The Generating policy in Kyverno for Limit Ranges looks something like this:

    It looks a bit lengthy, but there isn’t anything complex about it.


    Some of the fields are already familiar to you, so let’s explain the new ones.

    The rule is now generate, and the policy will apply to Namespaces.

    In the exclude section, you define which namespaces you wouldn’t want to be affected by the policy.

    Under generate, you define your LimitRange object.

    The synchronize field set to true means that the generated object will be protected from direct changes and restored to its original content as long as the Kyverno policy is intact.

    Also, another cool thing with the synchronization option is that any new change to the policy will be automatically propagated to every namespace where the Limit Range object exists.

    There is no need to copy it everywhere. Kyverno will automatically do this for you.

    Deleting the Kyverno policy will also delete the LimitRange object.

    Finally, under, you define the actual Limit Range limits and requests that will apply per container.

    Generate the policy with:

    <p>CODE:</p> created

    And create a new namespace:


    Now check if the limit range is automatically created along with the namespace:


    Name: namespace-limitrange
    Namespace: development
    Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
    Container memory - - 128Mi 2Gi -
    Container cpu - - 100m 1 -

    One more time to verify in the logs:

    I0712 21:13:37.372720   1 generate.go:421] GenerateController "msg"="updated target resource" "apiVersion"="v1" "genAPIVersion"="" "genKind"="LimitRange" "genName"="namespace-limitrange" "genNamespace"="development" "kind"="Namespace" "name"="development" "namespace"="" "policy"="add-namespace-limit"


    With this, you have successfully deployed and tested all three policy types in Kyverno.


    • You have learned about Kyverno and how to increase your cluster security
    • Learned how Kyverno works and how it integrates with Kubernetes
    • Installed and configured Kyverno on a cluster
    • Learned about different webhooks and policy types
    • Deployed and tested the Validating, Mutating, and Generation of policies

    Plug: Keep your K8s clusters reliable with Squadcast

    Squadcast is an incident management tool that’s purpose-built for SRE. Your team can get rid of unwanted alerts, receive relevant notifications, work in collaboration using the virtual incident war rooms, and use automated tools like runbooks to eliminate toil.

    Written By:
    July 23, 2021
    July 23, 2021
    Share this post:
    Subscribe to our LinkedIn Newsletter to receive more educational content
    Subscribe now

    Subscribe to our latest updates

    Enter your Email Id
    Thank you! Your submission has been received!
    Oops! Something went wrong while submitting the form.
    More from
    Kristijan Mitevski
    Traditional vs Modern Incident Response
    Traditional vs Modern Incident Response
    February 24, 2022
    Infrastructure as Code: All you need to know
    Infrastructure as Code: All you need to know
    November 26, 2021
    Implementing Istio in a Kubernetes cluster
    Implementing Istio in a Kubernetes cluster
    October 13, 2021
    Learn how organizations are using Squadcast
    to maintain and improve upon their Reliability metrics
    Learn how organizations are using Squadcast to maintain and improve upon their Reliability metrics
    "Mapgears simplified their complex On-call Alerting process with Squadcast.
    Squadcast has helped us aggregate alerts coming in from hundreds...
    "Bibam found their best PagerDuty alternative in Squadcast.
    By moving to Squadcast from Pagerduty, we have seen a serious reduction in alert fatigue, allowing us to focus...
    "Squadcast helped Tanner gain system insights and boost team productivity.
    Squadcast has integrated seamlessly into our DevOps and on-call team's workflows. Thanks to their reliability...
    Alexandre Lessard
    System Analyst
    Martin do Santos
    Platform and Architecture Tech Lead
    Sandro Franchi
    Squadcast is a leader in Incident Management on G2 Squadcast is a leader in Mid-Market IT Service Management (ITSM) Tools on G2 Squadcast is a leader in Americas IT Alerting on G2 Best IT Management Products 2022 Squadcast is a leader in Europe IT Alerting on G2 Squadcast is a leader in Mid-Market Asia Pacific Incident Management on G2 Users love Squadcast on G2
    Squadcast awarded as "Best Software" in the IT Management category by G2 🎉 Read full report here.
    What our
    have to say
    "Mapgears simplified their complex On-call Alerting process with Squadcast.
    Squadcast has helped us aggregate alerts coming in from hundreds of services into one single platform. We no longer have hundreds of...
    Alexandre Lessard
    System Analyst
    "Bibam found their best PagerDuty alternative in Squadcast.
    By moving to Squadcast from Pagerduty, we have seen a serious reduction in alert fatigue, allowing us to focus...
    Martin do Santos
    Platform and Architecture Tech Lead
    "Squadcast helped Tanner gain system insights and boost team productivity.
    Squadcast has integrated seamlessly into our DevOps and on-call team's workflows. Thanks to their reliability metrics we have...
    Sandro Franchi
    Revamp your Incident Response.
    Peak Reliability
    Easier, Faster, More Automated with SRE.
    Incident Response Mobility
    Manage incidents on the go with Squadcast mobile app for Android and iOS devices
    google playapple store
    Copyright © Squadcast Inc. 2017-2023