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.
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.
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.
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.
Validate
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.
Mutate
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.
Generate
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.
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.
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:
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:
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.
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.
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 generate.data.spec, you define the actual Limit Range limits and requests that will apply per container.
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.
What you should do now
Schedule a demo with Squadcast to learn about the platform, answer your questions, and evaluate if Squadcast is the right fit for you.
Curious about how Squadcast can assist you in implementing SRE best practices? Discover the platform's capabilities through our Interactive Demo.
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.
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.
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.
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.
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.
Validate
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.
Mutate
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.
Generate
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.
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.
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:
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:
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.
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.
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 generate.data.spec, you define the actual Limit Range limits and requests that will apply per container.
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.
What you should do now
Schedule a demo with Squadcast to learn about the platform, answer your questions, and evaluate if Squadcast is the right fit for you.
Curious about how Squadcast can assist you in implementing SRE best practices? Discover the platform's capabilities through our Interactive Demo.
