Comprehensive Walkthrough: Implementing Kyverno Security Policies in Kubernetes.
Kyverno is a policy engine designed for Kubernetes. It helps to enforce policies in Kubernetes to govern the ways usage of Kubernetes being practices. If we talk from security standpoint, Kyverno provides some amazing policies that helps to significantly improve Kubernetes security and enforce the compliance requirements by leveraging the security specific policies.
Here in this article, I’m going to show the easy step-by-step method of setting up Kyverno in Google Kubernetes Engine(GKE) to help you setup the merely in few minutes. Though this demonstration is being done on GKE, the same steps could be followed to implement Kyverno in AWS, Azure and other Cloud platforms.
Step 1. Set the project in cloud shell.
Open Google cloud console, go to Cloud Shell and shell is set to work with the project where you want to setup Kyverno. If it is not set, run the below command: gcloud config set project [Project Name]
Command 1. gcloud config set project my-kubernetes-project-395111
Step 2. Connect to the Kubernetes cluster.
Click on the triple dot icon and then click on connect.
Copy the command or simply run the below command to create connection with the Cluster.
Command 2. gcloud container clusters get-credentials the-hero-cluster — zone us-central1-c — project [Project-Name]
Run the command in cloud shell to connect to the Cluster.
Step 3. Install Kyverno Helm Chart in your Kubernetes Cluster.
Command 3. helm repo add kyverno https://kyverno.github.io/kyverno/
This command will adds repository named “kyverno” to Helm and the repository’s URL is https://kyverno.github.io/kyverno/. This repository likely contains Helm charts related to the Kyverno project.
I already have it installed thats why receiving the “kyverno already exist” message. You’ll get another message incidacating successful addition.
Command 4. helm install kyverno kyverno/kyverno -n kyverno — create-namespace
This command will the Kyverno Helm chart into a new namespace called “kyverno”.
If you’re able to run all the four command above this, congratulations! you have successfully installed Kyverno in your cluster. Now, let’s go and configure our first policy!
Step 4. Create first Kyverno security policy.
You can refer Kyverno Policies official documentation to get details of all the Kyverno policies. However, here I’m going to implement Restrict Image Registries policy in this demonstration.
The purpose of Restrict Image Registries policy is to ensure the deployment of images should be restricted upto the whitelisted registeries. For instance, here the whitelisted container registry is staging-my-image-repo/* and production-my-image-repo/* and therefore, the deployment must be allowed only from these two container registries.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-image-registries
annotations:
policies.kyverno.io/title: Restrict Image Registries
policies.kyverno.io/category: Best Practices, EKS Best Practices
policies.kyverno.io/severity: medium
policies.kyverno.io/minversion: 1.6.0
kyverno.io/kubernetes-version: "1.26"
policies.kyverno.io/subject: Pod
policies.kyverno.io/description: >-
Images from unknown, public registries can be of dubious quality and may not be
scanned and secured, representing a high degree of risk. Requiring use of known, approved
registries helps reduce threat exposure by ensuring image pulls only come from them. This
policy validates that container images only originate from the registry `eu.foo.io` or
`bar.io`. Use of this policy requires customization to define your allowable registries.
spec:
validationFailureAction: Enforce
background: true
failurePolicy: Fail
rules:
- name: validate-registries
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Unknown image registry."
pattern:
spec:
=(ephemeralContainers):
- image: “staging-my-image-repo/* | production-my-image-repo/*"
=(initContainers):
- image: "staging-my-image-repo/* | production-my-image-repo/*"
containers:
- image: "staging-my-image-repo/* | production-my-image-repo*"Create a Yaml file locally and put this policy. You can use vi command line utility for the same.
Past the policy in the file and save. Please note, as shown in the above image, the name of Yaml file is restrict-image-registeries.yaml as we’ll be using this file further to apply the policy in the cluster.
As the policy gets saved in the Yaml file, the stage of policy creation is over. Now the next action will be to apply the policy.
Step 5. Apply the Kyverno Restrict Image Registries security policy.
Let’s see what happens when we try to deploy image from any random registry.
As shown in the above image, I run command “kubectl create deployment hello-world-rest-api-try1 — image=in28min/hello-world-rest-api:0.0.1.RELEASE” to deploy the image from conatiner registry named “in28min” and it got deployed successfully.
Now let’s apply the policy and post that we’ll run the same command with new deployment name to see if it still allows the deploy the image from any non-whitelisted repository.
Command 5. kubectl apply -f restrict-image-registries.yaml
This command is used to apply policy that was saved in restrict-image-registries.yaml file.
Now let’s try to have a new deployment from the same container repository we used earlier, the one that is not whitelisted by the policy.
Boom! the deployment is failed as the applied policy instructed Kubernetes not to allow deployment of any image from any of the registry that is not whitelisted.
Using the similar way, you can apply multiple other Kyverno security policies as what exactly matches your security requirement. Refer Kyverno Policies official documentation to get details of all the Kyverno policies.
Hope this write-up help you to setup Kyverno, create & implement Kyverno policies in Kubernetes in the GCP from scratch.
Keep on securing!