Getting started

Edera Protect is a next-generation container isolation and resource engine that gives you more control over the security and compute resources over your production containers. Edera Protect has several components, the most important being our type 1 hypervisor that sits below the Linux kernel. The Edera hypervisor is either automatically baked into your Kubernetes nodes or it can be added.

When a pod launches under Kubernetes and specifies an Edera RuntimeClass, the pod is scheduled to the node with the Edera RuntimeClass and our hypervisor creates a virtual machine guest environment for the pod to run.

Getting access

Cloud OS image

If you use a managed Kubernetes provider, for example, EKS, Edera Protect automatically bakes our hypervisor into the cloud OS image (AMI) for AWS. Gaining access to Edera Protect as a customer is as simple as providing the Edera customer engineering team with your AWS account number so we can add the AMI to your account and then launching a new cluster or node pool using the Edera Protect AMI and installing a runtime class.

Once the customer engineering team has added your account, finding the AMIs that are available are as simple as querying AWS. This query shows all the available Edera Protect AWS AMIs sorted by the most recent builds.

aws ec2 describe-images --owners 207567768011 --query 'reverse(sort_by(Images[*].[CreationDate, ImageId, Name, State], &[0]))' --output table

The Edera Protect images specify the version of AWS Linux, Kubernetes version, and build date, respectively.

# The Protect AMI's are named with
# edera-protect-{product version}-{os}-amazon-eks-node-{cluster version}-{build date}
edera-protect-v1.0.2-al2-amazon-eks-node-1.32-v20250411

If you use terraform you can use a data source to access the AMI, for example:

data "aws_ami" "protect_al2" {
  owners      = ["207567768011"]
  most_recent = true

  # The Protect AMI's are named with
  # edera-protect-{product version}-{os}-amazon-eks-node-{cluster version}-{build date}
  #
  # This filters the Edera Protect AMI to pin to the 1.x version stream
  filter {
    name = "name"
    values = [
      "edera-protect-v1.*-al2-amazon-eks-node-${local.cluster_version}-*",
    ]
  }

  filter {
    name   = "state"
    values = ["available"]
  }
}

Custom OS or bare metal

If you run a custom OS or bare metal instance, you can also add the hypervisor to your metal or existing node image via our installer.

Apply Edera Protect Runtime Class

Edera Protect sits at the CRI layer in Kubernetes. Specifically, Edera Protect installs itself as a custom runtime class. Simply kubectl apply the Edera Protect runtime class in Kubernetes, and it will become available for the cluster.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: edera
handler: edera

You can verify the installation by running kubectl get runtimeclass:

kubectl get runtimeclass -o yaml
apiVersion: v1
items:
- apiVersion: node.k8s.io/v1
  handler: edera
  kind: RuntimeClass
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"node.k8s.io/v1","handler":"edera","kind":"RuntimeClass","metadata":{"annotations":{},"name":"edera"}}        
    creationTimestamp: "2025-04-15T15:28:37Z"
    name: edera
    resourceVersion: "6307"
    uid: 2e26ab23-81c3-4da2-8139-119d405ffb7f
kind: List
metadata:
  resourceVersion: ""

That’s it! Now you have the Edera Protect running in your cluster. You can validate the installation by running a pod with the edera RuntimeClassName value in a pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: edera-protect-pod
spec:
  runtimeClassName: edera
  containers: