LFX Mentorship: My Personal Experience with Kyverno

Hello everyone!

I recently had the incredible opportunity to work as an LFX Mentee for Term 1 2024, and I'd love to share my experience with you all.

Making contributions in the open source landscape can be quite difficult and intimidating especially when you are still a student. LFX Mentorship is a 12 week opportunity that allows folks to contribute to real world open source software while being guided by the project maintainers.

Background

While writing this blog, I am in my 3rd year pursuing Bachelors in Computer Science & Engineering. I started writing code in my 11th grade as part of the college curriculum and I had no clue how everything worked. I knew I had to learn outside of college hours to be able to unravel the mystery of programming. So, I started watching YouTube videos on programming and slowly became comfortable with it. I developed an interest for game development and played with the Unity game engine for a while until Engineering started.

When Engineering started, I'd spend my time solving questions on CodeChef & LeetCode. I didn't focus on the development side of things and I felt I lacked something.

During my 3rd semester, I started exploring DevOps and found it interesting. There were a lot of tools to be learnt, and I liked the fact that it requires one to be flexible when it comes to learning new things.

I wanted to gain real world knowledge on actual software development and I found out that open source is the best place to do so. I started contributing to the Kyverno project which focuses on Kubernetes. The project has an active community out there to help you, which made it all the more fulfilling to contribute!

Kyverno regularly participated in the mentorship, and I applied for Term 1 of 2024 and got selected! 🎉

What is Kyverno?

Kyverno is a policy engine designed for Kubernetes which helps users validate, mutate, generate resources and verify images by writing policies declaratively. It is Kubernetes-native and is easy to get started with if you have experience working with Kubernetes YAML files.

Here's a very simple example of a validate policy that denies Pod creation if any of its container images use the :latest tag

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: validate-image-tag
    # match block helps us target resources to
    # which the policy must be applied
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Using a mutable image tag e.g. 'latest' is not allowed."
      # We define an overlay pattern here that will be compared
      # against the incoming resource
      pattern:
        spec:
          containers:
          - image: "!*:latest" # Ensure the image does not use latest tag

We apply this policy in the Kubernetes cluster. Now, when we try to create the below pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: busybox
    image: busybox:1.35
  - name: nginx
    image: nginx:latest # latest tag won't be allowed!

The pod will be blocked with the following error:

Error from server: error when creating "pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request: 

resource Pod/default/my-pod was blocked due to the following policies 

disallow-latest-tag:
  validate-image-tag: 'validation error: Using a mutable image tag e.g. ''latest''
    is not allowed. rule validate-image-tag failed at path /spec/containers/1/image/'

This example shows a simple use case, but Kyverno is much more powerful and has many other capabilities to explore.

Work During The Mentorship

Task: Convert Kyverno validate policies to Kyverno CEL policies.

Kubernetes had introduced a feature called ValidatingAdmissionPolicy that allowed validation of resources directly in the Kubernetes API server with the help of CEL(Common Expression Language). This feature was introduced to help users avoid having to install a webhook for policy enforcement for simple validation checks. CEL is quite straightforward and easy to pick up.

Kyverno, being Kubernetes-native, has adapted to using CEL expressions in its validate policies. Users can now perform validation checks using CEL too. Usage of CEL applies to simple cases, and for more complex cases involving API calls etc, CEL won't be applicable and Kyverno's syntax must be used.

Kyverno can also optionally generate ValidatingAdmissionPolicies from CEL policies! It can help in cases where the admission webhook is down and we need policy enforcement to take place. This repository contains all the Kyverno policies that users can check out. I had to convert the validate policies that are present.

Example Conversion

Here's the CEL policy for the policy that we saw previously.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: validate-image-tag
    # match block helps us target resources on 
    # which the policy must be applied
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      # We write CEL expressions under this cel subrule
      cel:
        expressions:
          - expression: "object.spec.containers.all(container, !container.image.contains(':latest'))"
            message: "Using a mutable image tag e.g. 'latest' is not allowed."

object is a keyword that allows us to access the incoming resource. We iterate over all the containers present in the pod by using the all macro. Inside all we use container to refer to each item. !container.image.contains(':latest') checks that the latest tag is not present in the image. If any of the images contain the latest tag, then all will return false causing the resource to be rejected.

This was a simple example to showcase what CEL looks like. CEL policies can get a bit more complex if we use features such as parameter resources.

Experience

Contributions prior to the mentorship made it easy for me to get started quickly.
I've had the greatest experience in my career so far while contributing during the mentorship. Navigating through documentation, checking for references, testing changes, asking questions etc got me into the flow of a development process. This experience has been invaluable and will certainly carry forward to the future.

Achievements

The policy library consists of around 220 validate policies. Approximately 40% of these policies do not have an equivalent CEL representation. I am thrilled to have converted 120+ policies!

Conclusion

There would be no mentorship without my mentors Mariam Fahmy and
Anusha Hegde. Thank you so much for your time and patience in resolving my doubts and reviewing my PRs. The support you've shown made my mentorship experience truly fulfilling. Also, thanks to all the members of the community who helped me contribute to this amazing project. The efforts of the Linux Foundation and the Cloud Native Computing Foundation to help folks contribute through the mentorship are greatly appreciated. Thank you very much.