Getting started

Edera 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 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 automatically bakes our hypervisor into the cloud OS image (AMI) for AWS. Gaining access to Edera 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 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 AWS AMIs sorted by the most recent builds. Note, the customer engineering team will provide you the account ID.

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

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

# The Edera 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      = ["<ACCOUNT_ID>"]
  most_recent = true

  # The Edera AMI's are named with
  # edera-protect-{product version}-{os}-amazon-eks-node-{cluster version}-{build date}
  #
  # This filters the Edera 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 Runtime Class

Edera sits at the CRI layer in Kubernetes. Specifically, Edera installs itself as a custom runtime class. Simply kubectl apply the Edera 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 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: