Upwind security monitoring with Edera

7 min read · Intermediate

Security Platform Engineer

Edera works with Upwind Security, a cloud-native runtime security platform, to provide observability into workloads running in Edera protected zones. Upwind uses an eBPF-based Sensor, deployed as a Kubernetes DaemonSet, to detect threats, policy violations, and suspicious activity across your cluster. While Edera mitigates container escapes and access to shared host resources, security observability is a crucial aspect of defense-in-depth.

No Edera-specific configuration is required. Upwind supports Edera using the same Helm deployment model it already supports for other sandboxed runtimes such as Kata Containers. This guide walks you through installing the upstream Upwind Helm chart on an Edera-enabled cluster and verifying that workloads running in zones are visible in the Upwind console.

What you’ll learn

  • How Upwind fits alongside Edera in a Kubernetes cluster
  • How to install the Upwind Operator with Helm on an Edera-enabled cluster
  • How to launch a workload in an Edera zone for testing
  • How to verify that zone workloads appear in Upwind

Prerequisites

Before you begin, make sure you have:

  • Edera Protect installed on your cluster nodes, with the edera RuntimeClass available
  • An Upwind account with access to the Upwind console
  • Upwind client credentials (client ID and client secret) - see Generate Credentials in the Upwind docs
  • Helm and kubectl installed, with your kubeconfig pointing at the target cluster
  • Cluster admin access to create namespaces, secrets, and DaemonSets

How it works

Upwind is deployed with its standard Kubernetes architecture. The Upwind Operator manages two components: the Upwind Sensor, which runs as a DaemonSet on every node, and the Cluster Manager, which collects cluster-level inventory and coordinates scanning. Edera workloads are ordinary Kubernetes pods that request the edera RuntimeClass, so Upwind discovers and tracks them in the same way it does for any other sandboxed runtime.

┌─────────────────────────────────────────────────────────────────────────────┐
│ Kubernetes cluster                                                          │
│                                                                             │
│  ┌──────────────────────────────────────────────────────────────────────┐   │
│  │ upwind namespace                                                     │   │
│  │                                                                      │   │
│  │  • Upwind Operator      (manages Sensor + Cluster Manager)           │   │
│  │  • Upwind Cluster Manager (cluster inventory, scan coordination)     │   │
│  └──────────────────────────────────────────────────────────────────────┘   │
│                                                                             │
│  ┌──────────────────────────────────────────────────────────────────────┐   │
│  │ Node (Edera Protect installed)                                       │   │
│  │                                                                      │   │
│  │  ┌────────────────────────────────────────────────────────────────┐  │   │
│  │  │ Upwind Sensor (DaemonSet pod, standard runtime)                │  │   │
│  │  │                                                                │  │   │
│  │  │  • eBPF-based runtime monitoring on the node                   │  │   │
│  │  │  • Workload and container discovery                            │  │   │
│  │  │  • Streams telemetry to the Upwind platform                    │  │   │
│  │  └────────────────────────────────────────────────────────────────┘  │   │
│  │                                                                      │   │
│  │  ╪══════════════════════════════════════════════════════════════╪    │   │
│  │  │ Hypervisor (Xen)                                             │    │   │
│  │  ╪══════════════════════════════════════════════════════════════╪    │   │
│  │                                                                      │   │
│  │  ┌────────────────────────────────────────────────────────────────┐  │   │
│  │  │ Zone - MicroVM (runtimeClassName: edera)                       │  │   │
│  │  │                                                                │  │   │
│  │  │  • Zone kernel                                                 │  │   │
│  │  │  • Workload (OCI container)                                    │  │   │
│  │  └────────────────────────────────────────────────────────────────┘  │   │
│  └──────────────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────────────┘
                             │
                             │ Telemetry, inventory, detections
                             ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ Upwind platform (console.upwind.io)                                         │
│                                                                             │
│  • Runtime threat detection and alerting                                    │
│  • Workload inventory, vulnerability and posture findings                   │
│  • SIEM and notification integrations                                       │
└─────────────────────────────────────────────────────────────────────────────┘
ℹ️
The Upwind Sensor itself runs in a standard (non-Edera) pod on each node, because it needs node-level privileges to do its job. Only your application workloads should run in Edera zones. If you apply a default RuntimeClass or admission policy that places all pods in Edera zones, exclude the upwind namespace.

Step 1: Add the Upwind Helm repository 

helm repo add upwind https://charts.upwind.io/ && helm repo update

Step 2: Provide client credentials

Upwind recommends storing your client credentials in a Kubernetes Secret rather than passing them inline to helm install. This keeps the client secret out of your shell history and out of the Helm release storage.

Create the upwind namespace:

kubectl create namespace upwind

Create the Secret. The leading space before each export keeps the credentials out of your shell history:

 export UPWIND_CLIENT_ID="<your-client-id>"
 export UPWIND_CLIENT_SECRET="<your-client-secret>"

kubectl create secret generic upwind-secret -n upwind \
  --from-literal=clientId="$UPWIND_CLIENT_ID" \
  --from-literal=clientSecret="$UPWIND_CLIENT_SECRET"

Step 3: Install the Upwind Operator

Install the Upwind Operator using the upstream Helm chart. No Edera-specific values are needed.

helm install upwind-operator upwind/upwind-operator \
  --namespace upwind \
  --set credentials.create=false \
  --set credentials.name=upwind-secret
ℹ️

By default, Upwind components connect to the US region. If your Upwind tenant is in another region, add --set region=eu (or --set region=me) to the install command.

For production clusters, Upwind recommends running its survey tool first, which checks your cluster size and connectivity and generates a tailored install command, including Cluster Manager resource sizing. See the Upwind Kubernetes installation guide for the full set of options, including Terraform, operatorless Helm, and managed Kubernetes add-ons.

Step 4: Verify the Upwind components are running

Confirm that the Upwind Sensor and Cluster Manager are installed and healthy:

kubectl get agent,clusteragent --namespace upwind
kubectl get pods --namespace upwind

Both resources should show READY as True and STATUS as Installed, and every pod should be Running with all containers ready. There should be one Sensor pod on each node, including your Edera nodes.

Step 5: Launch a workload in an Edera zone

Deploy a test nginx workload that runs in an Edera zone by setting runtimeClassName: edera:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-edera
  labels:
    app: nginx-edera
spec:
  runtimeClassName: edera
  containers:
    - name: nginx
      image: docker.io/library/nginx:alpine
      ports:
        - containerPort: 80

Save this as nginx-edera.yaml and apply it:

kubectl apply -f nginx-edera.yaml

Confirm the pod is running:

kubectl get pod nginx-edera -o wide

Step 6: Verify the workload in Upwind

Open the Upwind console and navigate to your cluster’s workload inventory. Within a few minutes, you should see:

  • Your cluster listed with a connected Sensor on each node
  • The nginx-edera pod and its container in the workload inventory
  • Runtime activity and any detections for the workload as it runs

To generate some activity to look for, open a shell in the workload and run a few commands:

kubectl exec -it nginx-edera -- sh -c 'cat /etc/passwd; wget -qO- http://example.com > /dev/null'

Clean up

Remove the test workload:

kubectl delete -f nginx-edera.yaml

Unset the credential environment variables so they don’t linger in your shell:

unset UPWIND_CLIENT_ID UPWIND_CLIENT_SECRET

Troubleshooting

Upwind pods are not running

Check the Upwind components for errors:

kubectl get agent,clusteragent --namespace upwind
kubectl describe pods --namespace upwind

Check that the Sensor pods are not running in Edera zones. The Sensor requires node-level access and must run with the default runtime:

kubectl get pods -n upwind -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.runtimeClassName}{"\n"}{end}'

The runtimeClassName column should be empty for all Upwind pods. If it shows edera, check for a default RuntimeClass, mutating webhook, or admission policy that is applying the Edera runtime to the upwind namespace, and exclude it.

Verify the credentials Secret exists in the upwind namespace:

kubectl get secret upwind-secret -n upwind

Zone workloads don’t appear in Upwind

Confirm the workload is running in an Edera zone:

kubectl get pod nginx-edera -o jsonpath='{.spec.runtimeClassName}'

The output should be edera.

Confirm a Sensor pod is running on the same node as the workload:

kubectl get pod nginx-edera -o wide
kubectl get pods -n upwind -o wide

Check the Sensor logs on that node for errors:

kubectl logs -n upwind <sensor-pod-name> --all-containers

If the Upwind components are healthy but zone workloads still don’t appear, see the Upwind troubleshooting guide or contact Edera support with:

  • Output of kubectl get pods -n upwind -o wide
  • Sensor logs from the affected node
  • Zone/workload information

Next steps

  • Configure detections and policies - Tailor Upwind’s runtime policies to your security and compliance requirements
  • Integrate with SIEM - Forward Upwind alerts to your SIEM or logging platform
  • Set up notifications - Send Upwind alerts to Slack, PagerDuty, or other notification channels
  • Review Upwind docs - Learn more about Upwind Sensor configuration options
  • Explore Falco - If you also want syscall-level rules evaluated inside zones, see Falco security monitoring with Edera

Summary

You’ve deployed the Upwind Sensor on an Edera-enabled cluster using the standard upstream Helm chart. By combining Edera’s hypervisor-based isolation with Upwind’s runtime security platform, you get visibility into the workloads running in your protected zones, without any Edera-specific configuration.

Happy threat hunting.

Last updated on