Injecting the Edera RuntimeClass with Kyverno

Want to automatically inject Edera’s RuntimeClass into your pods? Here’s a Kyverno policy that does exactly that—no manual edits required.

This approach makes it easy to enforce Edera across your clusters with minimal developer friction.

Prerequisites

Before you begin, ensure you have the following tools installed:

Kyverno
kubectl
Nodes must be labeled with runtime=edera (see note below)

Note: Your cluster must have Kyverno installed with CRDs like ClusterPolicy and the Kyverno admission controller running.

Important: The Edera RuntimeClass includes a nodeSelector that requires nodes to be labeled with runtime=edera. Make sure your nodes are labeled before using this policy. See the installation guides for details on labeling nodes.

This policy works for both:

Pod controllers (Deployment, StatefulSet, and DaemonSet)
Standalone Pods

It sets the runtimeClassName to edera, ensuring your workloads run inside Edera zones by default.

When to use this

You’re managing workloads with Kyverno.
You want to automatically apply Edera’s runtime without updating every manifest.
You need a repeatable, policy-based way to enforce Edera across your cluster.

Example Kyverno policy

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: inject-runtimeclass
spec:
  rules:
    # Rule 1: Inject runtimeClassName into pod controllers
    - name: add-runtimeclass-to-pod-controllers
      match:
        any:
          - resources:
              kinds:
                - Deployment
                - StatefulSet
                - DaemonSet
      mutate:
        foreach:
          - list: "spec.template.spec.containers"
            patchStrategicMerge:
              spec:
                runtimeClassName: edera

    # Rule 2: Inject runtimeClassName into standalone Pods (unless it already exists)
    - name: add-runtimeclass-to-standalone-pods
      match:
        resources:
          kinds:
            - Pod
      exclude:
        resources:
          selector:
            matchExpressions:
              - key: "runtimeClassName"
                operator: Exists
      mutate:
        patchStrategicMerge:
          spec:
            runtimeClassName: edera

How it works

Pod Controllers: Mutates their Pod templates to set runtimeClassName: edera.
Pods: Automatically adds the runtime class unless it’s already defined (to avoid conflicts).

Testing the policy out

Create a file called test-pod.yaml with the below yaml and a file called inject-runtimeclass.yaml with the example Kyverno policy above.

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: nginx
      image: nginx

Testing it locally

Make sure you have kyverno installed locally and run:

kyverno apply inject-runtimeclass.yaml --resource test-pod.yaml --policy-report

Example output:

policy inject-runtimeclass applied to default/Pod/test-pod:
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: default
spec:
  containers:
  - image: nginx
    name: nginx
  runtimeClassName: edera

Mutation:
Mutation has been applied successfully.apiVersion: wgpolicyk8s.io/v1alpha2
kind: ClusterPolicyReport
metadata:
  creationTimestamp: null
  name: merged
results:
- message: mutated Pod/test-pod in namespace default
  policy: inject-runtimeclass
  properties:
    process: background scan
  resources:
  - apiVersion: v1
    kind: Pod
    name: test-pod
    namespace: default
  result: pass
  rule: add-runtimeclass-to-standalone-pods
  scored: true
  source: kyverno
  timestamp:
    nanos: 0
    seconds: 1751916566
summary:
  error: 0
  fail: 0
  pass: 1
  skip: 0
  warn: 0

You should see runtimeClassName: edera

Testing in on your cluster

Apply the policy:

kubectl apply -f inject-runtimeclass.yaml

Then apply the test pod:

kubectl apply -f test-pod.yaml

Inspect the applied object:

kubectl get pod test-pod -o yaml

You should see:

spec:
...
  runtimeClassName: edera

Need help customizing this? Contact us—we’re always down to help.

Last updated on 2025-11-24

Claiming devices with Edera Updating your host kernel on Amazon Linux