In this blog we will be discuss best practices to handle Kubernetes security by implementing Kyverno policies. We’ll be using a KIND cluster to demonstrate our use cases.
What is Kyverno:
Kyverno is a policy engine (controller) which applies policies to Kubernetes resources. It helps to verify if deployments are adhering to defined standards, and to implement best practices by defining certain conditions (policies). It includes many features, and some of the benefits (not an exhaustive list) are listed below:
- Define policies as Kubernetes resources (no new language to learn!)
- Validate, mutate, or generate any resource
- Verify container images for software supply chain security
- Inspect image metadata
- Match resources using label selectors and wildcards
- Validate and mutate using overlays (like Kustomize!)
- Synchronize configurations across Namespaces
- Block non-conformant resources using admission controls, or report policy violations
- Test policies and validate resources using the Kyverno CLI, in your CI/CD pipeline, before applying to your cluster
- Manage policies as code using familiar tools like git and kustomize
How it Works:
Kyverno runs as an admission controller within the Kubernetes cluster. When Kyverno policies are applied to the cluster and someone tries to deploy any of the resources in that cluster, Kyverno receives the request, validates via mutating admission webhook HTTPS callbacks from the kube-apiserver, and applies matching polices to return results that enforce admission policies or reject requests.
Here is the overall workflow –
Installation: Kyverno can be installed using either helm or yaml file.
Option1:
kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/main/definitions/release/install.yaml
Option2:
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno-policies kyverno/kyverno-policies -n kyverno
Use Cases:
We will walkthrough the following examples:
- Disallow the creation of pods in default namespaces
- Restricting the pods if they are not labeled during deployment
- Adding default labels as part of any resource that gets created
- Disallow the creation of pods in default namespaces
We will define restrict-default.yaml as below
Next, we will apply this policy
Kubectl apply -f restrict-default.yaml
In the below screenshot you can see the steps on how to validate that the appropriate Kyverno policy was applied to the deployment.
Note:
- If you notice the policy is not in an active state, try again with setting the action state to enforced.
- Deleting the policies:
- Kubectl delete cpol –all
- Ref: https://kyverno.io/docs/introduction/
- Restricting the pods if they are not labeled during deployment:
We will define require-labels.yaml as follows
kubectl apply -f require-labels.yaml
Adding default labels as part of any resource that gets created:
To configure a mutate policy of our KIND Cluster’s ClusterPolicy, and add labels such as env: prod on pods and other resources creation, create default-label.yaml as per below:
- Apply the policy
Kubectl apply -f default-label.yaml
