Security demonstration suite

4 min read · Intermediate


This suite demonstrates Edera’s core security value proposition: container isolation that prevents escape and lateral movement attacks.

ℹ️
Before you begin: Complete the prerequisites including cloning the learn repo and running make setup.

All manifests are available in the learn repository.

Test 1: Welcome to Edera

Verify that Edera is correctly installed and workloads run in isolated zones.

Deploy the welcome pod

make welcome

Or apply directly:

kubectl apply -f security/welcome-to-edera.yaml

Verify zone isolation

Check that the pod is running on an Edera node:

kubectl get pod welcome-to-edera -o wide

The pod should be scheduled on a node with the runtime=edera label.

Verify the pod is using the Edera runtime:

kubectl get pod welcome-to-edera -o jsonpath='{.spec.runtimeClassName}' && echo

Output should show edera.

Check the pod description to verify it is configured correctly with Edera:

kubectl describe pod welcome-to-edera

Success criteria:

  • Pod runs successfully with runtimeClassName: edera
  • Pod is scheduled on a node with the runtime=edera label
  • Pod operates normally from the application perspective

Cleanup:

kubectl delete pod welcome-to-edera

Test 2: Leaky Vessel demonstration

Demonstrate that Edera prevents process-level attacks. This test shows how a privileged “raider” pod can steal secrets from other containers—unless they’re protected by Edera.

Background

Without proper isolation, a privileged container with hostPID: true can access the /proc filesystem of other containers on the same node, exposing environment variables and secrets. Edera’s zone isolation prevents this attack.

Step 1: Show the vulnerability

Deploy a vulnerable pod (without Edera) and a raider pod:

make leaky-vessel

This will:

  1. Create a vulnerable-pod with secrets in environment variables
  2. Create a raider pod with hostPID access
  3. Show the raider stealing secrets from the vulnerable pod

You’ll see output like:

Found vulnerable pod process: 1750178
Secrets stolen:
PASSWORD=superSecretPassword
SECRET=reallyVeryImportantSecret

Step 2: Show Edera’s protection

Now deploy a secure pod with Edera:

make leaky-vessel-secure

This replaces the vulnerable pod with one using runtimeClassName: edera. The raider can no longer find or access the process:

No process found - the container is secure!

Why it works

With Edera:

  1. The secure pod runs in an isolated zone with its own kernel
  2. The zone’s processes are not visible in the host’s /proc filesystem
  3. The hypervisor boundary prevents any cross-zone process access

Success criteria:

ScenarioResult
Without EderaRaider steals secrets via /proc
With EderaRaider cannot see the process

Cleanup:

kubectl delete pod vulnerable-pod secure-pod raider --ignore-not-found

Test 3: Falco integration (optional)

Hard isolation breaks assumptions that typical observability tools make. Most are built for monitoring processes from a shared kernel. With Edera, observability still exists even with hard isolation—Falco is integrated into Edera’s zones, giving you the ability to monitor workload syscalls just like you would for standard pods.

⚠️
Pods must use zone kernel 6.16 or later for Falco monitoring. Standard Falco cannot see syscalls inside zones because each zone has its own isolated kernel. Contact Edera support if events aren’t appearing.

Install Falco with Edera plugin

make falco-install

This installs Falco via Helm with the Edera plugin configured. The plugin:

  • Mounts the Edera daemon socket and plugin library into Falco pods
  • Configures custom detection rules for zone activity
  • Enables syscall monitoring inside each zone’s kernel

Wait for the Falco pod to be ready (this may take a minute for init containers):

kubectl get pods -n falco -w

Expected output when ready:

NAME          READY   STATUS    RESTARTS   AGE
falco-vhpl4   2/2     Running   0          37s

For more details on the Edera Falco plugin architecture, see the Falco integration guide.

Deploy a test pod

The test pod uses the dev.edera/kernel annotation to specify the 6.16 zone kernel required for eBPF/Falco support:

make falco-test

Or apply directly:

kubectl apply -f security/falco-test.yaml
kubectl wait --for=condition=ready pod/falco-test --timeout=120s

The manifest includes the required annotation:

metadata:
  annotations:
    dev.edera/kernel: ghcr.io/edera-dev/zone-kernel:6.16

Trigger and verify a Falco alert

In one terminal, start streaming Falco logs:

kubectl logs -n falco -l app.kubernetes.io/name=falco -f | grep "Process executed"

In another terminal, execute a command inside the zone:

kubectl exec -it falco-test -- cat /etc/shadow

You should see an alert in the first terminal:

Process executed in zone | zone_id=<zone-uuid> proc=cat cmdline=cat /etc/shadow

Success criteria:

  • Edera Falco plugin successfully monitors zones
  • Process execution alerts are generated for activity inside zones
  • Defense-in-depth: isolation + threat detection

Cleanup:

kubectl delete -f security/falco-test.yaml

Cleanup

Remove all security test resources:

make clean-security

Summary

TestWhat it demonstratesSuccess criteria
Welcome to EderaBasic zone isolationPod runs in isolated zone
Leaky VesselContainer escape preventionEscape attempt fails
Falco integrationSecurity tool compatibilityAlerts generated for suspicious activity

Next steps

Last updated on