Security demonstration suite
This suite demonstrates Edera’s core security value proposition: container isolation that prevents escape and lateral movement attacks.
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 welcomeOr apply directly:
kubectl apply -f security/welcome-to-edera.yamlVerify zone isolation
Check that the pod is running on an Edera node:
kubectl get pod welcome-to-edera -o wideThe 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}' && echoOutput should show edera.
Check the pod description to verify it is configured correctly with Edera:
kubectl describe pod welcome-to-ederaSuccess criteria:
- Pod runs successfully with
runtimeClassName: edera - Pod is scheduled on a node with the
runtime=ederalabel - Pod operates normally from the application perspective
Cleanup:
kubectl delete pod welcome-to-ederaTest 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-vesselThis will:
- Create a
vulnerable-podwith secrets in environment variables - Create a
raiderpod with hostPID access - Show the raider stealing secrets from the vulnerable pod
You’ll see output like:
Found vulnerable pod process: 1750178
Secrets stolen:
PASSWORD=superSecretPassword
SECRET=reallyVeryImportantSecretStep 2: Show Edera’s protection
Now deploy a secure pod with Edera:
make leaky-vessel-secureThis 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:
- The secure pod runs in an isolated zone with its own kernel
- The zone’s processes are not visible in the host’s
/procfilesystem - The hypervisor boundary prevents any cross-zone process access
Success criteria:
| Scenario | Result |
|---|---|
| Without Edera | Raider steals secrets via /proc |
| With Edera | Raider cannot see the process |
Cleanup:
kubectl delete pod vulnerable-pod secure-pod raider --ignore-not-foundTest 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.
Install Falco with Edera plugin
make falco-installThis 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 -wExpected output when ready:
NAME READY STATUS RESTARTS AGE
falco-vhpl4 2/2 Running 0 37sFor 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-testOr apply directly:
kubectl apply -f security/falco-test.yaml
kubectl wait --for=condition=ready pod/falco-test --timeout=120sThe manifest includes the required annotation:
metadata:
annotations:
dev.edera/kernel: ghcr.io/edera-dev/zone-kernel:6.16Trigger 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/shadowYou should see an alert in the first terminal:
Process executed in zone | zone_id=<zone-uuid> proc=cat cmdline=cat /etc/shadowSuccess 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.yamlCleanup
Remove all security test resources:
make clean-securitySummary
| Test | What it demonstrates | Success criteria |
|---|---|---|
| Welcome to Edera | Basic zone isolation | Pod runs in isolated zone |
| Leaky Vessel | Container escape prevention | Escape attempt fails |
| Falco integration | Security tool compatibility | Alerts generated for suspicious activity |
Next steps
- Performance validation suite - Benchmark network and CPU performance
- Operations integration suite - Verify observability and automation