Detección de intrusiones en nodos Kubernetes

• El chart ejecuta el agente como un DaemonSet: un pod en cada nodo, control plane incluido, desplegado nodo a nodo.
• Una clave de clúster registra todos los nodos. Créala en el panel de InfraFence en Ajustes › Kubernetes; empieza por IFK- y solo se muestra una vez. Revocarla impide que se unan nodos nuevos; los ya registrados siguen funcionando.
• Cada nodo aparece como un servidor propio en el panel, agrupado por nombre de clúster. Starter cubre un servidor, así que solo puede registrarse un nodo; Basic y superiores no tienen límite y facturan un servidor por nodo.

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

Requisitos: Kubernetes 1.22 o posterior y Helm 3. El panel muestra el mismo comando con tu clave ya puesta. Los valores, las actualizaciones y la desinstalación están en Kubernetes.

• El tráfico de los pods puede no pasar por las reglas del firewall del nodo. Los bloqueos se aplican donde el tráfico llega al propio nodo (SSH, servicios del host, pods en la red del host como un controlador de ingress con hostNetwork). El tráfico que el plugin CNI o kube-proxy reenvía a los pods puede no pasar por INPUT ni por DOCKER-USER, donde están las reglas del agente. El panel lo indica en la página del nodo.
• Ninguna regla dentro del clúster. El agente no escribe NetworkPolicies, listas de denegación del ingress ni reglas del CNI: los bloqueos se quedan en el iptables del nodo.
• No es un admission controller ni un monitor de llamadas al sistema. No revisa los manifiestos antes de que se ejecuten ni traza las llamadas al sistema dentro de los contenedores. Los controles propios de Kubernetes, como RBAC y las NetworkPolicies, siguen siendo cosa tuya.
• Necesita pods privilegiados con red del host. Un clúster gestionado que no los permita no puede ejecutar el chart.
• Los bloqueos, la lista blanca y los bloqueos por país se aplican a IPv4.

• Un DaemonSet con red del host, el espacio de nombres PID del host y pods privilegiados, que el agente necesita para gestionar el firewall del nodo y ver sus procesos.
• Un ServiceAccount que puede leer pods, nodos, eventos, namespaces, ConfigMaps, ingresses y NetworkPolicies, más get y patch sobre DaemonSets, que el agente usa solo para actualizar el suyo.
• Un Secret con la clave de clúster.
• Montajes del host: /var/log y los sockets de Docker y containerd en solo lectura, y /etc/infrafence en lectura y escritura para el registro del nodo.

El código del chart está en el repositorio del agente: charts/infrafence-agent. Si ArgoCD o Flux gestionan el clúster, desactiva las actualizaciones automáticas y sube la etiqueta de la imagen en tu repositorio:

autoUpdate:
  enabled: false

Cada versión publica además infrafence-agent-linux-amd64-k8s e infrafence-agent-linux-arm64-k8s: el agente compilado con el cliente de Kubernetes, como en la imagen del chart, firmado como todas las versiones (Verificar una versión). Sus funciones de Kubernetes solo se activan cuando se ejecuta en un pod. Para un único host Docker, consulta Seguridad de hosts Docker.