Intrusion Detection für Kubernetes-Nodes

• Das Chart startet den Agent als DaemonSet: ein Pod auf jedem Node, Control Plane eingeschlossen, ausgerollt Node für Node.
• Ein Cluster-Schlüssel registriert jeden Node. Du erstellst ihn im Dashboard unter Einstellungen › Kubernetes; er beginnt mit IFK- und wird nur einmal angezeigt. Wird er widerrufen, können keine neuen Nodes mehr beitreten; registrierte Nodes laufen weiter.
• Jeder Node erscheint im Dashboard als eigener Server, gruppiert nach Clustername. Starter deckt einen Server ab, also kann sich nur ein Node registrieren; ab Basic gibt es keine Grenze, abgerechnet wird ein Server pro Node.

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

Voraussetzungen: Kubernetes 1.22 oder neuer und Helm 3. Das Dashboard zeigt denselben Befehl mit deinem Schlüssel schon eingesetzt. Values, Upgrades und Deinstallation stehen unter Kubernetes.

• Pod-Verkehr läuft womöglich nicht durch die Firewall-Regeln des Nodes. Sperren greifen dort, wo Verkehr den Node selbst erreicht (SSH, Dienste des Hosts, Pods im Host-Netzwerk wie ein Ingress-Controller mit hostNetwork). Verkehr, den das CNI-Plugin oder kube-proxy an Pods weiterleitet, läuft womöglich nicht durch INPUT oder DOCKER-USER, wo die Regeln des Agents liegen. Das Dashboard weist auf der Seite des Nodes darauf hin.
• Keine Regeln im Cluster. Der Agent schreibt keine NetworkPolicies, keine Sperrlisten im Ingress und keine CNI-Regeln: Sperren bleiben in den iptables des Nodes.
• Kein Admission Controller und keine Überwachung von Systemaufrufen zur Laufzeit. Er prüft keine Manifeste, bevor sie laufen, und verfolgt keine Systemaufrufe in Containern. Die eigenen Mechanismen von Kubernetes, etwa RBAC und NetworkPolicies, bleiben deine Aufgabe.
• Er braucht privilegierte Pods mit Host-Netzwerk. Ein verwalteter Cluster, der sie verbietet, kann das Chart nicht ausführen.
• Sperren, die Whitelist und Ländersperren gelten für IPv4.

• Ein DaemonSet mit Host-Netzwerk, dem PID-Namespace des Hosts und privilegierten Pods, die der Agent braucht, um die Firewall des Nodes zu verwalten und seine Prozesse zu sehen.
• Einen ServiceAccount, der Pods, Nodes, Events, Namespaces, ConfigMaps, Ingresses und NetworkPolicies lesen darf, dazu get und patch auf DaemonSets, die der Agent nur nutzt, um sein eigenes zu aktualisieren.
• Ein Secret mit dem Cluster-Schlüssel.
• Host-Mounts: /var/log und die Sockets von Docker und containerd nur lesend, /etc/infrafence lesend und schreibend für die Registrierung des Nodes.

Der Quellcode des Charts liegt im Repository des Agents: charts/infrafence-agent. Wenn ArgoCD oder Flux den Cluster verwaltet, schalte die Selbst-Updates ab und erhöhe stattdessen das Image-Tag in deinem Repository:

autoUpdate:
  enabled: false

Jedes Release veröffentlicht außerdem infrafence-agent-linux-amd64-k8s und infrafence-agent-linux-arm64-k8s: den Agent, gebaut mit dem Kubernetes-Client wie im Image des Charts, signiert wie jedes Release (Ein Release prüfen). Seine Kubernetes-Funktionen schalten sich nur ein, wenn er in einem Pod läuft. Für einen einzelnen Docker-Host siehe Einen Docker-Host absichern.