InfraFenceInfraFence

Live Security Operations

Get Started

Kubernetes

Protect every node of a Kubernetes cluster with the InfraFence Helm chart and a cluster key - install, values, upgrades, GitOps and what the chart deploys.

Last updated:

The Helm chart runs the agent as a DaemonSet: one agent on every node, control plane included. Each node registers as its own server in the dashboard.

Prerequisites: Kubernetes 1.22 or later and Helm 3.

Create a cluster key

In the dashboard, Settings › Kubernetes › Create cluster key (owners and admins). Unlike an install token, a cluster key registers every node of the cluster. It starts with IFK- and is shown only once: copy it straight away. The list shows only its last four characters afterwards.

Revoking a key stops new nodes from joining with it; nodes already registered keep working. On Starter only one node can register, since Starter covers one server; Basic and higher have no limit and bill one server per node.

Install

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

The dashboard shows the same command with your key and cluster name filled in.

Upgrade and uninstall

bash
helm upgrade infrafence-agent oci://ghcr.io/infrafence/charts/infrafence-agent \
  --namespace infrafence --reuse-values
bash
helm uninstall infrafence-agent --namespace infrafence

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

Values

Value Default Meaning
apiKey "" (required) The cluster key. Stored in a Secret.
serverUrl https://infrafence.com The dashboard.
clusterName "" Nodes are grouped by it in the dashboard; detected from the cluster when empty.
image.repository ghcr.io/infrafence/infrafence-agent The agent image.
image.tag "" The chart's appVersion when empty.
image.pullPolicy Always
autoUpdate.enabled true Lets the agent update its own DaemonSet. Turn it off with GitOps.
ingressFirewall.enabled false RBAC for blocking addresses in the nginx-ingress ConfigMap.
ingressFirewall.namespace ingress-nginx Where nginx-ingress runs.
ingressFirewall.configMapName ingress-nginx-controller Its ConfigMap.
resources requests 50m CPU, 64Mi; limits 500m CPU, 256Mi
tolerations [{operator: Exists}] Every node, control plane included.
nodeSelector {}
priorityClassName ""
extraEnv [] More environment variables, for example WEB_LOG_PATH.
serviceAccount.create true Also serviceAccount.name and serviceAccount.annotations.

Updates and GitOps

With autoUpdate.enabled, an agent that is allowed to update (the Agent updates setting is Install automatically, or you chose Install now) verifies the cosign signature of the new release image and moves its DaemonSet to that image by digest. If ArgoCD or Flux manages the cluster, turn this off and bump the image tag in your repository instead:

yaml
autoUpdate:
  enabled: false

What the chart deploys

  • a DaemonSet with host networking, the host PID namespace and privileged pods, rolled out one node at a time;
  • a ServiceAccount with read-only access to the Kubernetes API, plus the right to patch its own DaemonSet for updates;
  • a Secret with the cluster key;
  • with ingressFirewall.enabled, a Role that can write the ingress ConfigMap.

Host mounts: /var/log (read-only), the Docker and containerd sockets (read-only), and /etc/infrafence (read-write, the node's registration).

Ingress controllers

Bans work at the node's firewall whatever the ingress controller. For web attack detection the agent needs the access logs: with Traefik, turn its access logs on.