¶ Architecture
La solution Arkhn inclut un puit de log, une interface de visualisation et un SIEM (Security Information and Event Management) intégré permettant une traçabilité complète. Les technologies utilisées sont standard et OpenSource, et s'appuient sur :
- FileBeat : pour la récolte des logs et le transfert sécurisé dans ElasticSearch ;
- ElasticSearch : pour le stockage des données ;
- Kibana : pour la visualisation, l'exploitation de ces logs (recherche et export limités) et la partie SIEM définissant les alertes de sécurité de la plateforme.
⚠️ L'outillage et les procédures actuelles s'appuie sur la stack ELK qui possède des limitations entre autre autour de l'authentification unifiée, dans le courant de l'année 2026 est prévu la migration de cette stack sur très probablement OpenSearch avec OpenSearch Dashboards en remplacement de Kibana et Fluentbit en remplacement de FileBeat.
¶ Procédures d'exploitation
¶ Ouverture des accès aux logs
💡 En attendant la migration vers un système d'authentification centralisé, l'ouverture des accès se fait nominativement avec des identifiants viewer indépendants de la plateforme standard. Ils seront créé sur demande à votre CSM.
¶ Analyse des logs
L'ensemble des traces récoltées au sein du puit de log sont exploitable directement via l'interface Kibana mise à disposition au sein de la plateforme via l'URL https://<fqdn>/kibana
Ces logs sont structurés avec chaque source importante ayant ses données mises à plat sous un espace de nom dédié, par exemple pour Clickhouse, Vault ou Arkhn Admin. La première étape est de se connecter à l'interface de Kibana et d'aller dans la partie "Discover" :
De là il est possible de sélectionner en haut à droite la fenêtre temporelle intéressante (ici "Last 15 Minutes"), et à gauche le champ intéressant sur lequel filtrer les données ou visualiser la distribution des valeurs possibles sur cette plate temporelle :
L'estimation de la volumétrie de ces logs est ~1.5Gb par jour d'historique avec une durée de rétention configurée à 12 mois.
¶ Export des logs
💡 Le personnel habilité à opérer sur les logs est de type administrateur ou devops, et demande à avoir les droits de connection root directement à une machine du cluster
Selon le volume des données, deux procédures existent :
Dans le cadre d'un export de taille limité (\<150 Mo)
L'accès aux données se fait via Kibana, en se connectant sur l'url https://eds.\/kibana :  Une fois connecté, la selection se fera via l'interface de Discover : TODO Il suffira, une fois les périmètres définis (temporellement et en termes de critères), de lancer une opération d'export en CSV : TODO Le suivi de cette opération se fera dans la partie Stack Management \> Reporting TODO Il sera téléchargeable une fois l'export terminé : TODODans le cadre d'un export massif de données
Dans le cas où les données sont trop importantes faire l'export directement dans Kibana, une procédure technique nécessitant un accès SSH à une machine du cluster est possible. Tout d'abord, il faut télécharger l'outil elasticdump mis à disposition sur notre serveur [nexus.arkhn.io](http://nexus.arkhn.io) : ```bash > wget https://nexus.arkhn.io/repository/public/tools/elasticdump-linux-amd64 ``` Pour permettre l'extraction des données, il faut identifier l'adresse IP interne au cluster exposant le cluster ElasticSearch de logs ainsi que le login/mot de passe à utiliser : ```bash > kubectl -n arkhn get svc logs-es-internal-http NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE logs-es-internal-http ClusterIP 10.43.44.62 9200/TCP 54d ``` Ainsi que pour le secret : ```bash > kubectl -n arkhn get secret logs-es-elastic-user -o yaml apiVersion: v1 data: elastic: kind: Secret metadata: ... name: logs-es-elastic-user namespace: arkhn ... type: Opaque ``` Il faut décoder ce secret avec : ```bash > echo "" | base64 -d | xargs ``` Enfin, en se positionnant dans un dossier pouvant stocker l'ensemble des données - le volume estimé pour 1 mois de logs bruts est de l'ordre de \~200 Go - il suffit de lancer la ligne de commande suivante, permettant de sélectionner une plage de date : ```bash ./elasticdump-linux-amd64 TODO ```Croiser les logs coder et keycloak pour un user:
On remarquera que le username dans keycloak correspond à l'email dans coder. ```bash coder.fields.actor.email: or keycloak.event.username : ``` ## Events non ingérés dans Elasticsearch et Kibana Seul les signaux utiles à l'audit client sont ingérés dans ElasticSearch (logs).
Kibana est principalement destiné pour les administrateurs de la plateforme et permet d'auditer les actions utilisateurs sur la plateforme. Nous filtrons donc ce qui est trop verbeux ou trop orienté applicatif: - trop de volume à ingérer et à stocker. Ce qui nécessiterait une grande quantité de stockage, et donc un coût d'infrastructure plus élevé. - Cela peut polluer la recherche audit utilisateur. - Les logs applicatifs restent visibles dans les pods, mais ne sont pas faits pour être conservés et peuvent disparaître au redémarrage du pod. Ces autres logs sont principalement intéressants pour l'équipe Arkhn, afin de comprendre des possibles indisponibilités de service, erreurs ou autre. - MongoDB + Vault Secrets Operator - TODO - ClickHouse : logs Trace/Debug non liés à un utilisateur - Condition: container clickhouse-pod ET clickhouse.level ∈ \{Trace, Debug\} ET (clickhouse.user_id vide/absent OU clickhouse.user_id == clickhouse_operator) - Raison: Trace/Debug génèrent de gros volume de logs qui ne font pas partie des access logs.
L'absence de user_id ou user clickhouse_operator indique que ce n'est pas une action utilisateur. - Coder : - Condition: app coder ET (coder.msg manquant OU coder.msg != audit_log) - Raison: nous ne gardons que les événements explicitement marqués comme "audit_log" par coder lui même, le reste des logs étant plus applicatif, servant à savoir quel template appelle coder, les logs de créations de workspace, etc. - Vault : lectures automatiques du service account "kubernetes-arkhn-default" - Condition: app vault ET vault.auth.display_name: kubernetes-arkhn-default ET vault.request.operation: read - Raison: ce sont des lectures automatisées, qui sont nombreuses, et ne sont pas utiles pour l'audit utilisateur.