Description des services Cyberwatch

La suite logicielle Cyberwatch repose sur l’utilisation d’images Docker. Il est possible d’utiliser Docker swarm ou Kubernetes comme orchestrateur. Les conteneurs proposent un ensemble de services communiquant ensemble et constituant les briques de la suite logicielle.

Cette documentation liste et décrit l’ensemble des services nécessaires au fonctionnement de la suite logicielle Cyberwatch, ainsi que leur état de présence/absence sur les serveurs Cyberwatch en fonction du type d’architecture choisie.

L’état de ces services peut être consulté depuis le serveur Cyberwatch à l’aide de la commande suivante :

sudo cyberwatch status

Dans le cas où tous les services ne sont pas en cours d’exécution, consulter les logs du service.

Description de chaque service

db: Base de données MariaDB dans laquelle sont stockées les données de l’application.
nginx: Serveur web responsable de l’interface entre l’application et l’extérieur. Par défaut, le conteneur expose les ports 80 et 443 sur l’extérieur. Le service redirige les requêtes vers le conteneur approprié (web, kibana, third_parties).
web: Conteneur Olympe responsable du traitement des requêtes web.
sidekiq_master: Conteneur Olympe responsable de l’exécution des jobs en mode asynchrone. Le service traite les tâches qui nécessitent d’être exécutées sur le nœud master. Le service a été ajouté avec le socle en version 5.21.
sidekiq: Similaire à sidekiq_master, à la différence que le service est disponible sur tous les types de nœud. Le service traite les tâches qui ne nécessitent pas d’être exécutées sur un scanner en particulier.
sidekiq_node: Similaire à sidekiq mais utilisé pour exécuter les tâches sur un scanner en particulier. Responsable notamment de la connexion aux machines supervisées en connexion sans-agent.
cron: Planificateur des tâches de l’application. Supprimé sur les socles en version supérieure ou égale à 5.21.
redis: Base de données en RAM utilisée pour la pile des tâches.
cache: Base de données en RAM utilisée pour le cache de l’application.
elasticsearch: Conteneur responsable des indexes Elasticsearch.
kibana: Outil de visualisation permettant la création de dashboards personnalisés.
web-scanner: Navigateur web pour les scans de cible réseau et site web. Il génère aussi les rapports PDF.
container-scanner: Moteur des scans des images Docker.
third_parties: Conteneur contenant le cab file Windows.

Services attendus sur chaque nœud

Service	Nœud maître	Nœud satellite indépendant
db	✓⁽³⁾
nginx	✓	✓
web	✓	✓
sidekiq_master	✓
sidekiq	✓	✓
sidekiq_node	✓	✓
cron	✓⁽¹⁾
redis	✓⁽³⁾
cache	✓	✓
elasticsearch	✓⁽⁴⁾
kibana	✓⁽⁴⁾
web-scanner	✓	✓
container-scanner	✓	✓
third_parties	✓⁽²⁾	✓⁽²⁾

⁽¹⁾ Uniquement sur les versions du socle inférieures ou égales à 5.20.
⁽²⁾ Uniquement sur les nœuds hors-ligne.
⁽³⁾ Absent en cas d’utilisation d’une base de données ou d’un serveur redis externe.
⁽⁴⁾ Absent lorsque la variable CBW_DISABLE_ELK est activée.

Dans un cluster de nœuds indépendants, les services propres au nœud maître (base de données, pile des tâches, Elastic Stack) sont utilisés par les nœuds satellites :

flowchart TB
  U["Navigateur / API"] -- "80 / 443" --> NG
  subgraph MASTER["Nœud maître"]
    NG["nginx"] --> WEB["web-application"]
    NG --> KIB["kibana"]
    NG -. "hors ligne" .-> TP["third_parties"]
    WEB --> DB[("db")]
    SKM["sidekiq_master"] --> REDIS[("redis")]
    KIB --> ES[("elasticsearch")]
  end
  subgraph SAT["Nœud satellite indépendant"]
    direction LR
    NG2["nginx"] --> WEB2["web-application"]
    WRK["sidekiq, sidekiq_node, cache,<br/>web-scanner, container-scanner"]
  end
  SAT -- "TCP 3306" --> DB
  SAT -- "TCP 6379" --> REDIS