Introducing Kyverno 1.4.2: Trusted And More Efficient!

Introducing Kyverno 1.4.2: Trusted And More Efficient!

We are pleased to officially announce the release of the newest version of project  “Kyverno”, a popular policy engine for Kubernetes. Kyverno v1.4.2, is a version consisting of over a month of dedication and hard work from the maintainers and contributors to Kyverno.

This version contains a few bug fixes, improved features and performance to the Kyverno project. Version 1.4.2 has several core utilities improved, providing a more polished and satisfactory experience for users adopting Kyverno.

Compared to v1.4.1, this version offers advanced solutions for users writing Kyverno policies. 

Release Highlights:  

DurationOperator that regulates duration comparison

With the current updates so far, Kyverno can be used to enforce that the requested lifetime does not exceed a specific value that the user requests. Kyverno now makes this possible without additional codes. As seen below you can now create Pods with a duration of less than 8 hours.

apiVersion: kyverno.io/vi
kind: Cluster Policy
metadata:
  name: pod-lifetime
  annotations:
    policies. kyverno.io/title: Enforce pod duration
    policies. kyverno.io/category: Sample
    policies. kyverno.io/minversion: 1.4.2
    policies. kyverno.io/subject: Pod
    policies. kyverno.io/description: >-
      This validation is valuable when annotations are used to define durations,
      such as to ensure a Pod lifetime annotation does not exceed some site specific max thresh
      Pod lifetime annotation can be no greater than 8 hours.
spec:
  background: false
  validationFailureAction: audit
  rules:
  - name: pods-lifetime
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Pod lifetime exceeds limit of 8h"
      deny:
        conditions:
        - key: "{{ request.object.metadata.annotations. \"pod. kubernetes.io/lifetime\" }}"
          operator: DurationGreaterThan
          value: "8h"

Kyverno now supports the Kubernetes Connect operation

This means you can now have a policy that prevents Pod execs in many different ways. Just as it appears in the example below which blocks exec by label. In fact, Kyverno provides FIVE samples just around this ability to help you be more productive.

apiVersion: kyverno.io/v1
kind: cluster Policy
metadata:
  name: deny-exec-by-pod-label
  annotations:
    policies, kyverno.io/title: Block Pod Exec by Pod Label
    policies. kyverno.io/category: Sample
    policies. kyverno.io/minversion: 1.4.2
    policies. kyverno.io/subject: Pod
    policies. kyverno.io/description: >-
      The 'exec' command may be used to gain shell access, or run other commands, in a Pod's co
      be useful for troubleshooting purposes, it could represent an attack vector and is discou
      This policy blocks Pod exec commands to Pods having the label 'exec=false'.
spec:
  validationFailureAction: audit
  background: false
  rules:
  - name: deny-exec-by-label
    match:
      resources:
        kinds:
        - PodExecOptions
    context:
    - name: podexeclabel
      apicall:
        urlPath: "/api/v1/namespaces/{{request.namespace}}/pods/{{request.name}}"
        jmesPath: "metadata. labels.exec"
    preconditions:
  - key: "{{ request.operation }}"
    operator: Equals
    value: CONNECT
  validate:
    message: Exec'ing into Pods protected with the label 'exec=false' is forbidden.
    deny:
      conditions:
        - key: "{{ podexeclabel )}"
          operator: Equals
          value: "false"

Alpha support for Cosign project

Kyverno now has alpha support for #Cosign project giving you the privilege of to sign images and push to OCI registries. Kyverno can verify those signatures prior to allowing any image to be pulled into the cluster!

apiVersion: kyverno.io/v1
kind: clusterPolicy
metadata:
  name: verify-image
  annotations:
    policies.kyverno.io/title: Verify Image
    policies. kyverno.io/category: Sample
    policies. kyverno.io/severity: medium
    policies. kyverno.io/subject: Pod
    policies. kyverno.io/minversion: 1.4.2
    policies.kyverno.io/description: >-
      Using the Cosign project, OCI images may be signed to ensure supply chain
      security is maintained. Those signatures can be verified before pulling into
      a cluster. This policy checks the signature of an image repo called
      gher.io/kyverno/test-verify-image to ensure it has been signed by verifying
      its signature against the provided public key. This policy serves as an illustration for
      how to configure a similar rule and will require replacing with your image(s) and keys.
spec:
  validation FailureAction: enforce
  background: false
  rules:
    - name: verify-image
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
      - image: "gher.io/kyverno/test-verify-image:*"
        key: |-
          -----BEGIN PUBLIC KEY-----
          MEKWEWYHKOZIZ) OCAQYIKOZIZJODAQDQCAE8nXRh9501ZbR8Ra/N9sbqoPZrEM
          5/KAQNO/KjHcorm/J5yctvd7iEcnessRQjU917hMKO6JWVGHPDguIyakZA==
          -----END PUBLIC KEY-----

​​

Metrics redesign to deal with cardinality growth

This fix ensures that the infinite-ness cardinality associated with Kyverno’s metrics is taken care of.

Add special variable substitution logic for preconditions 

Kyverno now supports 80 sample policies making it by far the most comprehensive sample library of any Kubernetes policy engine out there.

More details regarding these latest enhancements can be found in the release notes

The enhancements in this release enable more flexibility when writing Kyverno policies while allowing you to address more complex use cases without increasing your learning curve. Test drive this new release and please share your feedback with the team. You can reach out to the Kyverno team on the #kyverno Slack channel or mailing list.

Learn lots more about Kyverno, its features and benefits, by visiting this page.

Common Ways to Optimize Kyverno Policy Engine
Kubernetes Supply Chain Policy Management with Cosign and Kyverno
No Comments

Sorry, the comment form is closed at this time.