Edera in AWS Bottlerocket

3 min read · Intermediate

Developer Platform Engineer Security
ℹ️
Early Access Feature: Bottlerocket support is an early access feature. It is supported, but its install surface, error messages, and defaults may change before general availability. See Edera Release Stages for details.

AWS’s Bottlerocket is a minimized Linux distribution that is purpose-built for running containers. Users choose to use it because it offers a pre-hardened, immutable, container-optimized platform which can be used as a part of a trusted and verified architecture. Unfortunately, this configuration traditionally precludes the ability to do Type-1 isolation between workloads, despite KVM support in Bottlerocket. You no longer need to choose between Bottlerocket’s security and Edera’s security. You can now get both.

Requirements

  • Edera requires CPU virtualization features which are typically only available on bare-metal instance types or those offering nested virtualization.
  • Although there are a number of Bottlerocket variants, providing FIPS certification or GPU access, we’re only supporting EKS Kubernetes 1.36 today.

How does Edera on Bottlerocket work?

Edera places our stack inside a superpowered Bottlerocket host container, which allows access to /dev/kvm. We configure the Kubelet to send CRI calls to Edera’s socket instead of the default socket. When you ask the Kubelet to launch an Edera workload, Edera launches a KVM-isolated guest with the usual Edera runtime.

Install

Early Access install is via a Bottlerocket-compatible Edera host container image. Please contact support@edera.dev for specifics, including access and what regions are available.

Launch

Edera strives to make things as transparent as possible for you. After a successful install, an Edera-enabled Bottlerocket should look and feel identical to how you’ve been working before. Here’s what we’re actually doing in the background when you launch a workload.

  1. Kubernetes schedules a pod with runtimeClassName: edera

    The runtimeClassName: edera config signals the scheduler to select a node that runs the edera runtime. The API server writes the binding; kubelet on the node picks it up.

  2. kubelet talks to containerd via CRI

    kubelet resolves runtimeClassName: edera and calls the containerd CRI gRPC endpoint.

  3. containerd maps handler and spawns shim

    containerd looks up edera in its config. It spawns the Edera Containerd Shim /usr/bin/containerd-shim-edera-v2. This is the only edera binary that lives directly on the Bottlerocket host OS.

  4. The shim contacts protect-daemon

    The shim uses the /run/edera/daemon.socket that the protect-daemon created inside the edera-runtime host container. Meanwhile, the host container’s entrypoint bound it via /.bottlerocket/rootfs/run/edera/daemon.socket so it appears at the same path on the host.

  5. protect-daemon packs the workload image

    The daemon spawns protect-oci-provider to pull the OCI image layers, pack them into a squashfs, and store it in the image cache. The cache is symlinked through /.bottlerocket/rootfs/ so it persists on the host filesystem across container restarts.

  6. protect-daemon creates a KVM zone

    The daemon launches cloud-hypervisor with the zone kernel, initrd, and the workload squashfs. virtiofsd provides the rootfs to the VM over virtio-fs.

  7. Shim proxies lifecycle back to containerd

    The Edera Containerd Shim continues to translate between containerd’s OCI lifecycle model (start, exec, wait, kill) and the KVM zone managed by protect-daemon. From kubelet’s perspective the pod is indistinguishable from any other container.

Related pages

Last updated on