Does each node count as a server?

Yes. Each node registers as its own server and is billed as one on Basic and higher. On Starter only one node can register.

What happens when a node is rebuilt?

A node that registers again, after a rebuild or a wiped /etc/infrafence, keeps its server in the dashboard and gets a new token.

Can I run it with ArgoCD or Flux?

Yes. Set autoUpdate.enabled to false so the agent does not change its own DaemonSet, and update the image tag in your repository.

Kubernetes node intrusion detection

Last updated: November 7, 2026

Every Kubernetes node is still a Linux server: it has SSH, a kernel firewall, system files and, often, an ingress controller taking traffic from the internet. The InfraFence Helm chart puts the agent on each node, so each node is watched and defended like any other server in your dashboard.

This page says what the agent covers on a node, and what it does not. It is not a replacement for Kubernetes' own security controls.

How it runs

The chart runs the agent as a DaemonSet: one pod on every node, control plane included, rolled out one node at a time.
One cluster key registers every node. Create it in the dashboard under Settings › Kubernetes; it starts with IFK- and is shown only once. Revoking it stops new nodes from joining; registered nodes keep working.
Each node appears as its own server in the dashboard, grouped by cluster name. Starter covers one server, so only one node can register; Basic and higher have no limit and bill one server per node.

helm install infrafence-agent oci://ghcr.io/infrafence/charts/infrafence-agent \
  --namespace infrafence --create-namespace \
  --set apiKey="IFK-..." \
  --set clusterName="production"

Prerequisites: Kubernetes 1.22 or later and Helm 3. The dashboard shows the same command with your key filled in. Values, upgrades and uninstall are in Kubernetes.

What it covers on a node

Area	What the agent does
SSH and the node itself	Reads the node's logs from `/var/log`, stops SSH brute force and scores SSH sessions for risk. Bans go into the node's iptables, in the agent's own chains.
Ingress traffic	Finds the ingress-nginx and Traefik pods on the node and reads their access logs under `/var/log/pods`, with the same web attack rules as on any server. Traefik writes no access log until you turn it on.
Pods on the node	Reports, through the Kubernetes API with read-only access, the pods on its node and the ingress hosts of the cluster. Crash loops, OOM kills, image pull failures and evictions of pods on its node are sent to the dashboard as events.
Outbound, DNS, files	Watches connections leaving the node, DNS answers, malware and the integrity of system files, like on any Linux server.
Updates	With `autoUpdate.enabled`, an agent allowed to update verifies the cosign signature of the new image and moves its own DaemonSet to it by digest.

What it does not cover

Pod traffic may not cross the node's firewall rules. Bans apply where traffic reaches the node itself (SSH, services of the host, pods on the host network such as an ingress controller with hostNetwork). Traffic that the CNI plugin or kube-proxy forwards to pods may not go through INPUT or DOCKER-USER, where the agent's rules are. The dashboard says so on the node's page.
No rules inside the cluster. The agent does not write NetworkPolicies, ingress deny lists or CNI rules: bans stay in the node's iptables.
Not an admission controller or a runtime syscall monitor. It does not check manifests before they run, and does not trace system calls inside containers. Kubernetes' own controls, such as RBAC and NetworkPolicies, stay yours.
It needs privileged pods with host networking. A managed cluster that forbids them cannot run the chart.
Bans, the whitelist and country blocks apply to IPv4.

What the chart deploys

A DaemonSet with host networking, the host PID namespace and privileged pods, which the agent needs to manage the node's firewall and see its processes.
A ServiceAccount that can read pods, nodes, events, namespaces, ConfigMaps, ingresses and NetworkPolicies, plus get and patch on DaemonSets, which the agent uses only to update its own.
A Secret with the cluster key.
Host mounts: /var/log and the Docker and containerd sockets read only, and /etc/infrafence read-write for the node's registration.

The chart's source is in the agent repository: charts/infrafence-agent. If ArgoCD or Flux manages the cluster, turn self-updates off and bump the image tag in your repository instead:

autoUpdate:
  enabled: false

Each release also publishes infrafence-agent-linux-amd64-k8s and infrafence-agent-linux-arm64-k8s: the agent built with the Kubernetes client, as in the chart's image, signed like every release (Verify releases). Its Kubernetes features turn on only when it runs in a pod. For a single Docker host, see Docker host security.

Questions

Does each node count as a server?: Yes. Each node registers as its own server and is billed as one on Basic and higher. On Starter only one node can register.
What happens when a node is rebuilt?: A node that registers again, after a rebuild or a wiped /etc/infrafence, keeps its server in the dashboard and gets a new token.
Can I run it with ArgoCD or Flux?: Yes. Set autoUpdate.enabled to false so the agent does not change its own DaemonSet, and update the image tag in your repository.

Try it free on 1 server

Starter gives one server full protection, free and with no credit card.

01
Create a free account, then open Servers › Add server to get your install token. It is valid for one hour.
Create the token

Then run this as root on the server:

curl -fsSL https://github.com/infrafence/infrafence-agent/releases/latest/download/install.sh | sudo bash -s -- --token <TOKEN>

Create a free account Read the docs