Deploy Falco on AWS EKS for Kubernetes Runtime Security (2026)

Falco, the open-source runtime security tool for Kubernetes, can detect anomalous activity by analyzing system calls.

Here’s how to get Falco up and running on AWS EKS, focusing on practical deployment and understanding its core mechanics.

Deployment Steps

Install the Falco Helm Chart

The easiest way to deploy Falco is using its official Helm chart. First, add the Falco Helm repository:
```
helm repo add falco https://falcosecurity.github.io/charts
helm repo update
```
Next, create a Kubernetes namespace for Falco (if you don’t already have one):
```
kubectl create namespace falco
```
Now, install the Falco chart. We’ll start with a basic configuration. You can customize this extensively later.
```
helm install falco falco/falco --namespace falco
```
This command deploys Falco as a DaemonSet, ensuring a Falco instance runs on each worker node in your EKS cluster.
Verify Falco Pods

Check if the Falco pods are running:
```
kubectl get pods -n falco
```
You should see pods named falco-xxxxx with a Running status on each of your worker nodes. If a pod is stuck in Pending or CrashLoopBackOff, investigate its logs:
```
kubectl logs <falco-pod-name> -n falco
```
Access Falco Logs and Events

Falco generates security events and logs them. You can view these directly from the Falco pods:
```
kubectl logs -n falco -l app=falco -f
```
This command streams the logs from all Falco pods. You’ll start seeing output as Falco detects activity.

Alternatively, and often more practically for ongoing monitoring, you can configure Falco to output events to stdout and then use kubectl logs to view them, or set up a dedicated output like a webhook, Kafka, or Elasticsearch. The default Helm chart configuration usually streams to stdout.
Testing Falco Rules

To see Falco in action, trigger a rule. A common test is to execute a shell within a container, which often triggers a "shell in a container" alert.

First, get the name of a running pod in your cluster (not the Falco pod itself):
```
kubectl get pods
```
Then, execute a shell inside that pod:
```
kubectl exec -it <your-pod-name> -- /bin/sh
```
Once inside the container, you might see an alert in your Falco logs like:
```
10:00:00.123456789: Warning: Shell in a container (user=root, command=sh, pid=123, container_id=abcdef123456)
```
This demonstrates Falco’s ability to detect potentially suspicious activities like unexpected shell access within your workloads.

Understanding the Mechanics

Falco operates by tapping into the kernel’s system call stream. On Linux systems, every interaction between a userspace process (like your application’s binary) and the kernel goes through system calls. Falco uses either a kernel module or, more commonly now, eBPF (extended Berkeley Packet Filter) to efficiently capture these system calls without significant performance overhead.

Once captured, Falco compares these system calls against a set of predefined rules. These rules are written in a declarative YAML format and define patterns of system call sequences, file access, network activity, or process execution that are considered suspicious. When a pattern matches, Falco generates an alert.

The power of Falco lies in its extensive rule set and its flexibility. You can:

Customize Rules: Modify existing rules or create entirely new ones to tailor detection to your specific environment and threat model.
Configure Outputs: Direct alerts to various destinations like stdout, syslog, Kafka, Elasticsearch, or webhooks for integration with SIEMs or alerting systems.
Integrate with Kubernetes: Falco understands Kubernetes metadata (pod names, namespaces, labels, etc.), enriching its alerts with crucial context. This allows rules to be written that are aware of the Kubernetes environment.

Advanced Configuration (Briefly)

The Helm chart provides many customization options via values.yaml. For instance, you can:

Change priority: Adjust the alert severity levels Falco generates.
Enable ebpf: Ensure eBPF is used if your kernel supports it (highly recommended for stability and performance).
Configure outputs: Define where alerts are sent (e.g., syslog, json_output, webhook).
Set rulesFile: Specify custom rule files to load.

To apply these, you’d typically use helm upgrade:

helm upgrade falco falco/falco --namespace falco -f my-custom-values.yaml

Where my-custom-values.yaml contains your overrides.

The default rules are quite comprehensive, covering common attack vectors like privilege escalation, suspicious file modifications, and network reconnaissance. The eBPF probe, when used, attaches to the kernel and efficiently filters system calls, forwarding only relevant events to the Falco userspace daemon for analysis. This means Falco doesn’t need to process every single system call, making it performant.

When an alert is triggered, Falco packages the event data along with relevant Kubernetes metadata. This context is vital for incident response, allowing you to quickly identify which pod, deployment, or node is involved. For example, an alert might include the kubernetes.pod.name, kubernetes.namespace, kubernetes.labels, and container.id.

The next logical step after basic deployment is integrating Falco with a SIEM or alert management system for centralized monitoring and automated response.