Architecture de référence¶

Vue d'ensemble¶

L'architecture de sécurité runtime repose sur trois composants principaux, chacun couvrant une fonction distincte :

graph TD
    subgraph K8s["Cluster Kubernetes"]
        API["API Server<br/>OPA/Gatekeeper Webhook<br/>(ValidatingAdmissionWebhook)"]
        API --> Nodes
        subgraph Nodes["Noeuds"]
            F1["Falco (DaemonSet)<br/>eBPF probe<br/>Node 1"] --> W1["Workloads"]
            F2["Falco (DaemonSet)<br/>eBPF probe<br/>Node 2"] --> W2["Workloads"]
            F3["Falco (DaemonSet)<br/>eBPF probe<br/>Node 3"] --> W3["Workloads"]
        end
        TrivyOp["Trivy Operator (Deployment)<br/>Scanne les images periodiquement<br/>Genere des VulnerabilityReport CRD"]
        GK["Gatekeeper Controller (Deployment)<br/>Evalue les ConstraintTemplates<br/>Mode audit : detecte les violations"]
    end
    K8s -->|Alertes et rapports| Obs
    subgraph Obs["Stack Observabilite"]
        Loki["Loki<br/>(alertes Falco)"]
        Prom["Prometheus<br/>(metriques Falco/OPA)"]
        Grafana["Grafana<br/>(dashboards securite)"]
    end

Composants et flux de données¶

Falco — Detection eBPF¶

Falco est déployé comme DaemonSet : une instance par nœud du cluster.

Flux de données :

1. Le kernel execute un appel système (ex: execve, open, connect)
2. La sonde eBPF Falco capture l'événement
3. Le moteur de regles Falco evalue l'événement contre les regles chargees
4. Si une regle matche, une alerte est emise (JSON sur stdout)
5. Alloy/Fluentd collecte l'alerte et la pousse vers Loki
6. Grafana affiche l'alerte dans le dashboard sécurité

OPA/Gatekeeper — Admission control¶

Gatekeeper est déployé comme Deployment avec un webhook d'admission.

Flux de données :

1. Un utilisateur ou un contrôleur cree/modifie une ressource Kubernetes
2. L'API Server envoie la requête au webhook Gatekeeper
3. Gatekeeper evalue le manifeste contre les Constraints actives
4. Si une violation est détectée : la requête est rejetee avec un message explicatif
5. Les violations en mode audit sont stockees dans le status de la Constraint

Trivy Operator — Scanning continu¶

Le Trivy Operator est un Deployment qui surveille les workloads et scanne automatiquement les images.

Flux de données :

1. Un nouveau Deployment est cree ou une image est mise à jour
2. Le Trivy Operator détecte le changement et cree un Job de scan
3. Le Job scanne l'image contre la base de vulnerabilites (NVD, GitHub Advisory)
4. Le résultat est stocke comme CRD VulnerabilityReport
5. Prometheus scrape les metriques du Trivy Operator (nombre de CVE par sévérité)
6. Grafana affiche un dashboard des vulnerabilites

Integration SIEM¶

Tous les composants alimentent la stack d'observabilité :

Metriques cles a collecter¶

# Metriques Falco
falco_events_total              # Nombre total d'evenements evalues
falco_alerts_total              # Nombre d'alertes declenchees par regle
falco_drops_total               # Evenements perdus (saturation)
falco_kernel_events_per_second  # Debit du kernel

# Metriques Gatekeeper
gatekeeper_violations           # Violations detectees par contrainte
gatekeeper_request_duration     # Latence d'evaluation des webhooks
gatekeeper_constraint_templates # Nombre de templates charges

# Metriques Trivy Operator
trivy_image_vulnerabilities     # CVE par image et severite
trivy_config_audits             # Non-conformites de configuration
trivy_exposed_secrets           # Secrets exposes detectes

Dimensionnement¶

Falco¶

OPA/Gatekeeper¶

Trivy Operator¶