# 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](https://docs.edera.dev/guides/validate/#prerequisites) including cloning the learn repo and running `make setup`. All manifests are available in the [learn repository](https://github.com/edera-dev/learn/tree/main/validate/security). ## Test 1: Welcome to Edera Verify that Edera is correctly installed and workloads run in isolated zones. ### Deploy the welcome pod ```bash make welcome ``` Or apply directly: ```bash kubectl apply -f security/welcome-to-edera.yaml ``` ### Verify zone isolation Check that the pod is running on an Edera node: ```bash 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: ```bash 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: ```bash 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:** ```bash 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: ```bash 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: ```text Found vulnerable pod process: 1750178 Secrets stolen: PASSWORD=superSecretPassword SECRET=reallyVeryImportantSecret ``` ### Step 2: Show Edera’s protection Now deploy a secure pod with Edera: ```bash make leaky-vessel-secure ``` This replaces the vulnerable pod with one using `runtimeClassName: edera`. The raider can no longer find or access the process: ```text 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:** | Scenario | Result | |------------------|---------------------------------| | Without Edera | Raider steals secrets via /proc | | With Edera | Raider cannot see the process | **Cleanup:** ```bash 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. ### Install Falco with Edera plugin ```bash 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): ```bash kubectl get pods -n falco -w ``` Expected output when ready: ```text 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](https://docs.edera.dev/guides/observability/falco-integration/). ### Deploy a test pod ```bash make falco-test ``` Or apply directly: ```bash kubectl apply -f security/falco-test.yaml kubectl wait --for=condition=ready pod/falco-test --timeout=120s ``` ### Trigger and verify a Falco alert In one terminal, start streaming Falco logs: ```bash kubectl logs -n falco -l app.kubernetes.io/name=falco -f | grep "Process executed" ``` In another terminal, execute a command inside the zone: ```bash kubectl exec -it falco-test -- cat /etc/shadow ``` You should see an alert in the first terminal: ```text Process executed in zone | zone_id= 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:** ```bash kubectl delete -f security/falco-test.yaml ``` --- ## Cleanup Remove all security test resources: ```bash make clean-security ``` --- ## Summary | 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](https://docs.edera.dev/guides/validate/performance/) - Benchmark network and CPU performance - [Operations integration suite](https://docs.edera.dev/guides/validate/operations/) - Verify observability and automation Last updated on 2026-03-19