Securing Edera

6 min read · Advanced

This guide walks through the steps required to harden an Edera deployment for production. It covers Kubernetes admission policies, network policies, RBAC, secrets management, and Edera-specific configuration.

All manifests are available in the learn repository.

For design rationale behind these requirements, see the Security reference architecture.

Test on EKS

If you want to run the full end-to-end hardening test on a real cluster before applying to production, the learn repository includes a complete EKS setup with hardening wired in:

git clone https://github.com/edera-dev/learn.git

# Deploy EKS cluster with Edera nodes (~15 min)
cd learn/getting-started/eks-terraform
cp terraform.tfvars.example terraform.tfvars
# edit terraform.tfvars with your Edera account ID
make deploy
make test

# Apply and verify hardening policies
make harden

# When done
make harden-clean
make destroy

make harden installs Kyverno, applies the admission policies and network policy, and runs the verification tests against the cluster. See the EKS install guide for prerequisites and configuration options.

Prerequisites

• Edera installed on your cluster nodes
• kubectl access with cluster-admin permissions
• Kyverno installed for admission policies (or OPA Gatekeeper, or PodSecurity admission)
• Familiarity with Kubernetes NetworkPolicy resources

Step 1: Enforce pod security admission

Apply admission policies to deny configurations that weaken zone isolation. These must be in place before tenant workloads are deployed.

Using Kyverno

Clone the learn repository and apply the hardening policy:

git clone https://github.com/edera-dev/learn.git
cd learn/harden
make apply-policies

Or apply directly:

kubectl apply -f https://raw.githubusercontent.com/edera-dev/learn/main/harden/policies/kyverno-edera-hardening.yaml

The policy enforces these controls:

Using Kubernetes PodSecurity admission

As an alternative to Kyverno, label tenant namespaces to enforce the built-in restricted profile:

kubectl label namespace <tenant-namespace> \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest

Verify enforcement

make verify

This runs dry-run tests to confirm hostPath and hostNetwork are denied.

Step 2: Apply network policies

Zones can reach other pods and node services by default. Apply a default-deny egress policy to each tenant namespace, then add explicit allow rules for required destinations only.

make apply-network-policy NAMESPACE=<tenant-namespace>

Or apply directly:

kubectl apply -f https://raw.githubusercontent.com/edera-dev/learn/main/harden/policies/network-policy-default-deny-egress.yaml

Ports that must not be reachable from zones:

Step 3: Lock down RBAC

Disable default ServiceAccount token mounting

kubectl patch serviceaccount default \
  -n <tenant-namespace> \
  -p '{"automountServiceAccountToken": false}'

Create workload-specific ServiceAccounts

Do not reuse the default ServiceAccount. Create one per workload with minimum required permissions:

kubectl create serviceaccount <workload-name> -n <tenant-namespace>

Audit for privilege escalation paths

Check whether any ServiceAccount can create pods with elevated permissions:

kubectl auth can-i create pods \
  --as=system:serviceaccount:<namespace>:<serviceaccount>

Step 4: Harden secrets management

Audit mounted credentials

Find existing workloads with mounted secrets:

kubectl get pods -n <tenant-namespace> -o json | \
  jq '.items[].spec.volumes[] | select(.secret != null) | .secret.secretName'

Replace mounted credentials with runtime-fetched secrets:

Scope ServiceAccount tokens

For workloads that need Kubernetes API access, use audience-scoped tokens:

kubectl create token <serviceaccount-name> \
  --audience=<your-service> \
  --duration=1h \
  -n <namespace>

Step 5: Configure Edera-specific settings

Pin zone kernels

Set the zone kernel annotation on workload pods to track the latest patched kernel:

kubectl annotate pod <pod-name> dev.edera/kernel=ghcr.io/edera-dev/zone-kernel:latest

Or add it directly to the pod spec:

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

AI agent workloads

Deploy the hardened AI agent example from the learn repository:

make apply-ai-agent

The example manifest configures:

• automountServiceAccountToken: false – agent does not need Kubernetes API access
• privileged: false and capabilities: drop: ALL – minimal in-zone attack surface
• readOnlyRootFilesystem: true – prevents in-zone persistence
• restartPolicy: Never – prevents automatic restart of a potentially compromised agent

Step 6: Deploy monitoring

Install Falco with the Edera plugin

Standard Falco cannot see inside zones because each zone has its own kernel. The Edera plugin bridges this.

See the Falco integration guide for setup instructions.

Key alerts to configure

Step 7: Verify your configuration

Work through this checklist before moving tenant workloads to production.

Admission policies

• hostPath volumes denied in all tenant namespaces
• hostNetwork denied
• hostPID denied
• hostIPC denied
• Privileged pods denied by default
• ALL capabilities dropped by default
• automountServiceAccountToken: false on tenant namespace default ServiceAccounts

Network policies

• Default-deny egress applied to tenant namespaces
• Node ports (10250, 10255, 22, 10249, 6443) not reachable from zones
• Cross-namespace traffic denied by default
• Internet egress restricted to required destinations only

Secrets management

• No long-lived credentials mounted as volumes
• Cloud IAM using IRSA or Workload Identity
• Database and API credentials fetched at runtime
• ServiceAccount tokens scoped and short-lived

Edera configuration

• Zone kernels set to :latest or actively managed version
• Falco deployed with Edera zone-aware plugin
• Dom0 access restricted to infrastructure operators only

Monitoring

• Falco rules deployed for Xen device access
• Zone crash and restart frequency monitored
• Network connections to node ports logged and alerted
• Xenstore write pattern alerts configured

Next steps

• Security reference architecture – design rationale and multi-tenancy architecture details
• Incident response procedures – zone compromise and XSA response playbooks
• Falco integration – detailed Falco setup and rule configuration
• Security validation suite – hands-on tests to verify isolation is working