Docker

L'agent fonctionne aussi dans un conteneur qui protège son hôte. L'image est multi-architecture (amd64 et arm64), publiée à chaque version et signée avec cosign.

• ghcr.io/infrafence/infrafence-agent:latest, ou une étiquette de version comme ghcr.io/infrafence/infrafence-agent:<version>
• la même image sur Docker Hub sous le nom infrafence/infrafence-agent

docker run#

docker run -d --name infrafence-agent --restart unless-stopped \
  --privileged --network host --pid host \
  -v /var/log:/var/log:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v infrafence-config:/etc/infrafence \
  -e INFRAFENCE_TOKEN=<YOUR_TOKEN> \
  ghcr.io/infrafence/infrafence-agent:latest

Pourquoi chaque élément est nécessaire :

• --privileged, --network host : l'agent gère le pare-feu de l'hôte (iptables et ipset) et lit l'état réseau de l'hôte.
• --pid host : il voit les processus de l'hôte, pour la détection des processus malveillants et l'attribution des requêtes DNS.
• /var/log en lecture seule : les journaux qu'il analyse.
• le socket Docker en lecture seule : pour trouver les conteneurs dont il faut protéger les ports et les journaux.
• /etc/infrafence dans un volume nommé : l'enregistrement survit aux mises à niveau du conteneur. Le jeton n'est utilisé qu'une fois ; les démarrages suivants réutilisent l'enregistrement stocké.

Variables d'environnement#

Toutes les variables propres à l'agent (voir Configuration), comme WEB_LOG_PATH, peuvent aussi être passées avec -e.

Sans jeton, fichier de jeton ni clé de cluster au premier démarrage, le conteneur s'arrête avec [infrafence] ERROR: No credentials provided for registration.

Docker Compose#

Chaque hôte a besoin de son propre jeton d'installation, comme n'importe quel autre serveur.

services:
  infrafence-agent:
    image: ghcr.io/infrafence/infrafence-agent:latest
    container_name: infrafence-agent
    restart: unless-stopped
    privileged: true
    network_mode: host
    pid: host
    environment:
      - INFRAFENCE_TOKEN=${INFRAFENCE_TOKEN}
    volumes:
      - /var/log:/var/log:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - infrafence-config:/etc/infrafence

volumes:
  infrafence-config:

INFRAFENCE_TOKEN=<YOUR_TOKEN> docker compose up -d

Conteneurs sur l'hôte#

Sur un hôte où Docker tourne, l'agent saute aussi vers sa chaîne de pare-feu depuis DOCKER-USER, si bien que les bannissements couvrent aussi les ports publiés par vos conteneurs. Un agent installé avec install.sh sur l'hôte trouve aussi les journaux d'accès des conteneurs web (images nginx, Apache et OpenResty ; pour Traefik et Caddy, voir plus bas) et lit ces labels sur vos conteneurs :

La découverte des conteneurs utilise l'outil en ligne de commande docker, que l'image de l'agent ne contient pas : à l'intérieur du conteneur, indiquez plutôt les journaux à l'agent avec WEB_LOG_PATH.

Domaines derrière un reverse proxy#

Depuis l'agent 1.0.35, l'agent liste aussi les domaines de vos conteneurs en cours d'exécution à partir des labels que lit leur reverse proxy, via le socket Docker ou Podman (en lecture seule, actualisés toutes les 2 minutes, aussi dans le conteneur de l'agent) :

• Règles de routeur Traefik, traefik.http.routers.<nom>.rule : chaque Host(...) de la règle. HostRegexp et les règles de chemin sont ignorés.
• Adresses de site Caddy, caddy et caddy_0, caddy_1...
• infrafence.domain.

C'est ce que Coolify écrit pour son proxy (coolify-proxy, Traefik ou Caddy) : un serveur Coolify n'a donc besoin d'aucun label. Les domaines apparaissent dans Surveillance › Badge de surveillance, où ils se vérifient avec un enregistrement DNS TXT, puisque le site n'a pas de racine sur l'hôte : voir Badge de surveillance. L'agent n'exécute jamais rien dans le conteneur du proxy ; il ne lit pas les journaux d'accès JSON de Traefik ou de Caddy.

Autres commandes#

L'image exécute toute commande de l'agent que vous lui passez, par exemple la vérification en lecture seule :

docker run --rm --privileged --network host --pid host ghcr.io/infrafence/infrafence-agent:latest preflight