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
Important
To gain access to Edera, reach out to the customer engineering team at support@edera.dev to discuss your requirements.
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: