Détection d'intrusion sur les nœuds Kubernetes

• Le chart lance l'agent en DaemonSet : un pod sur chaque nœud, control plane compris, déployé un nœud à la fois.
• Une seule clé de cluster enregistre tous les nœuds. Créez-la dans le tableau de bord sous Paramètres › Kubernetes ; elle commence par IFK- et n'est affichée qu'une fois. La révoquer empêche de nouveaux nœuds de rejoindre le cluster ; les nœuds déjà enregistrés continuent de fonctionner.
• Chaque nœud apparaît comme un serveur à part entière dans le tableau de bord, regroupé par nom de cluster. Starter couvre un serveur, donc un seul nœud peut s'enregistrer ; à partir de Basic, il n'y a pas de limite et chaque nœud est facturé comme un serveur.

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

Prérequis : Kubernetes 1.22 ou ultérieur et Helm 3. Le tableau de bord affiche la même commande avec votre clé déjà renseignée. Les valeurs, les mises à jour et la désinstallation sont décrites dans Kubernetes.

• Le trafic des pods peut ne pas traverser les règles du pare-feu du nœud. Les bannissements s'appliquent là où le trafic atteint le nœud lui-même (SSH, services de l'hôte, pods sur le réseau de l'hôte comme un contrôleur ingress en hostNetwork). Le trafic que le plugin CNI ou kube-proxy transfère vers les pods peut ne pas passer par INPUT ni par DOCKER-USER, où se trouvent les règles de l'agent. Le tableau de bord le signale sur la page du nœud.
• Aucune règle à l'intérieur du cluster. L'agent n'écrit ni NetworkPolicies, ni listes de refus d'ingress, ni règles CNI : les bannissements restent dans l'iptables du nœud.
• Ni admission controller, ni surveillance des appels système à l'exécution. Il ne vérifie pas les manifestes avant leur exécution et ne trace pas les appels système dans les conteneurs. Les contrôles propres à Kubernetes, comme RBAC et les NetworkPolicies, restent de votre ressort.
• Il a besoin de pods privilégiés avec le réseau de l'hôte. Un cluster managé qui les interdit ne peut pas faire tourner le chart.
• Les bannissements, la liste blanche et les blocages par pays s'appliquent à l'IPv4.

• Un DaemonSet avec le réseau de l'hôte, l'espace de noms PID de l'hôte et des pods privilégiés, dont l'agent a besoin pour gérer le pare-feu du nœud et voir ses processus.
• Un ServiceAccount qui peut lire les pods, nœuds, événements, namespaces, ConfigMaps, ingresses et NetworkPolicies, plus get et patch sur les DaemonSets, que l'agent n'utilise que pour mettre à jour le sien.
• Un Secret contenant la clé de cluster.
• Montages de l'hôte : /var/log et les sockets Docker et containerd en lecture seule, et /etc/infrafence en lecture-écriture pour l'enregistrement du nœud.

Le code source du chart se trouve dans le dépôt de l'agent : charts/infrafence-agent. Si ArgoCD ou Flux gère le cluster, désactivez les mises à jour automatiques et faites évoluer le tag de l'image dans votre dépôt :

autoUpdate:
  enabled: false

Chaque version publie aussi infrafence-agent-linux-amd64-k8s et infrafence-agent-linux-arm64-k8s : l'agent compilé avec le client Kubernetes, comme dans l'image du chart, signé comme toutes les versions (Vérifier une version). Ses fonctions Kubernetes ne s'activent que lorsqu'il tourne dans un pod. Pour un seul hôte Docker, voir Sécurité d'un hôte Docker.