GUIDE

Architecture de la plateforme

Control Plane, agent cluster, modèle de données et flux Voir / Contrôler / Prouver.

Mis à jour: 2026-05-09

Architecture

Aegis Vetis est composé de deux éléments :

un Control Plane déployé une fois, dans un cluster dédié ou un cluster d’administration ;
un agent cluster déployé dans chaque cluster Kubernetes que l’organisation veut superviser.

L’ensemble vise trois promesses qui structurent toute la plateforme : Voir, Contrôler, Prouver.

1. Vue d’ensemble

Tous les flux entre les clusters et le Control Plane sont sortants depuis les clusters. Aucune connexion entrante n’est requise depuis le Control Plane vers un cluster client. Les sites souverains conservent ainsi le contrôle de leur périmètre réseau.

+---------------------- Control Plane (HQ) ------------------------+
|                                                                  |
|   Vue 3 SPA  ──►  REST API (Gin, JWT/OIDC)                       |
|                            │                                     |
|              ┌─────────────┼─────────────┐                       |
|              ▼             ▼             ▼                       |
|         PostgreSQL    Worker (PDF,   Operator                    |
|                       scoring)                                   |
+───────────────────────────┬──────────────────────────────────────+
                            │ HTTPS sortant depuis le cluster
                            │ (JWT long-terme + mTLS optionnel)
                            ▼
+──────────────────── Cluster client (k3s / rke2 / k8s) ───────────+
|                                                                  |
|   aegis-agent  ──►  Kyverno admission webhook                    |
|        │            (ClusterPolicy enforce / audit)              |
|        ├─►  Kubescape CronJob  (posture cluster)                 |
|        ├─►  Trivy CronJob      (scan images)                     |
|        └─►  PolicyReport scrape (violations admission)           |
+──────────────────────────────────────────────────────────────────+

2. Control Plane

Composant	Rôle
`aegis-api`	REST API : auth JWT/OIDC, gestion clusters, policies, exceptions, rapports, audit. Endpoints `/api/v1/*` + `/healthz` `/readyz` `/metrics`
`aegis-worker`	Jobs asynchrones : recalcul du score de conformité, génération des PDF, expiration des exceptions, gestion des disconnects
`aegis-frontend`	SPA Vue 3 servie par nginx
`aegis-operator`	Contrôleur Kubebuilder qui réconcilie les CRDs côté Control Plane
`aegis-postgres`	Base PostgreSQL 16 (embarquée par défaut, externalisable)

3. Agent cluster

Un seul Deployment aegis-agent par cluster, plus les subcharts :

Kyverno — moteur d’admission. Son webhook valide chaque création ou mutation de ressource Kubernetes contre les ClusterPolicy poussées par Aegis Vetis. failurePolicy: Ignore par défaut, pour ne pas bloquer le cluster en cas d’incident interne du webhook.
Kubescape — CronJob qui scanne la posture du cluster contre les contrôles CIS et NSA-CISA toutes les 6 h.
Trivy — CronJob qui scanne les images des workloads en cours d’exécution toutes les 12 h.

L’agent réalise quatre boucles régulières :

Boucle	Période	Action
Heartbeat	30 s	`POST /api/v1/agent/heartbeat` avec version, état des composants, version Kubernetes
`PolicyReport` scrape	15 s	Lit les `wgpolicyk8s.io/PolicyReport`, pousse les violations nouvelles
Assignment sync	30 s	Récupère les policies assignées, applique/retire les `ClusterPolicy`
Exception sync	30 s	Récupère les exceptions actives, génère les `PolicyException` Kyverno correspondantes

4. Modèle de données

Trois CRDs minimales côté cluster client :

CRD	Scope	Rôle
`AegisCluster`	Cluster	Identité, état (`Pending` / `Active` / `Disconnected`), URL du Control Plane
`AegisPolicySet`	Cluster	Liste des policies appliquées et leur mode (audit / enforce)
`AegisException`	Namespaced	Exception temporaire à une policy : justification, ticket, expiration

Côté Control Plane, le modèle est en PostgreSQL : clusters, policies, policy_assignments, violations, scan_results, compliance_scores, exceptions, reports, audit_events. Voir Conformité pour le détail des champs liés au scoring et aux preuves.

5. Flux Voir / Contrôler / Prouver

Voir

L’agent envoie un heartbeat toutes les 30 s, plus les violations Kyverno au fil de l’eau et les résultats Kubescape / Trivy à chaque scan terminé. L’UI affiche les clusters, namespaces, workloads et leur posture en quasi-temps réel.

Contrôler

Une policy est définie dans Aegis Vetis — choisie dans le bundle baseline (6 policies fournies) ou personnalisée — puis assignée à un cluster en mode audit ou enforce. L’agent traduit l’assignment en ClusterPolicy Kyverno qui bloque, en mode enforce, toute création de ressource non conforme à l’admission.

Prouver

À la demande (UI ou API), un job worker rend un PDF qui consolide : score par référentiel, violations actives, exceptions en cours, top findings Kubescape et Trivy, recommandations. Le PDF est signé Cosign, le SHA-256 stocké en base, le journal d’audit enrichi (actor_id, action, occurred_at).

6. Authentification et autorisation

Authentification

Locale : email + mot de passe (argon2id), pour le compte d’urgence ou les déploiements sans IdP.
OIDC : Keycloak, Azure AD, Okta, Google. Les utilisateurs sont provisionnés à la première connexion ; leur rôle est calculé à partir d’un claim groups mappé en configuration.
Agent : token long-terme par cluster, échange initial via token bootstrap à usage unique, TTL 24 h.

Autorisation

Trois rôles applicatifs :

Rôle	Permissions
`viewer`	Lecture seule de tout
`operator`	Lecture + assignations de policies + exceptions + génération de rapports
`admin`	Tout, y compris gestion utilisateurs et OIDC

Une RBAC scopée par cluster ou par namespace est sur la roadmap.

7. Connectivité

Mode	Description	Supporté
Online	Agent ↔ Control Plane en HTTPS sortant, temps réel	Oui
Air-gap install	Bundle d’images mirror, install offline, exploitation online ensuite	Oui
Air-gap runtime	Cluster client sans Internet, joint le Control Plane sur le réseau privé interne	Oui
Disconnected total	Aucun lien clusters ↔ Control Plane, export manuel	Sur la roadmap

Voir Air-gap pour la procédure complète.

8. Stockage et persistance

Données	Backend	Sauvegarde recommandée
Configuration et état (clusters, policies, violations, audit, scoring)	PostgreSQL 16	Dump quotidien chiffré + offsite, RPO 24 h
Rapports PDF historiques	PVC RWO (5 Gi par défaut)	Snapshot quotidien du PVC, ou sync vers S3 Object Lock
Bundles de policies	ConfigMap par cluster	Re-syncable depuis le Control Plane
Tokens et clés (JWT, Cosign, OIDC)	Secrets Kubernetes (chiffrement etcd activé côté cluster cible)	Sauvegarde hors-cluster dans un coffre-fort

9. Observabilité

Métriques : tous les services exposent /metrics Prometheus. Métriques clés : aegis_clusters_total{state}, aegis_violations_total{cluster_id,severity}, aegis_compliance_score{cluster_id,framework}, aegis_reports_generated_total{framework}.
Logs : JSON structuré sur stdout, agrégeable par Loki / Elastic / Splunk. Champs systématiques : ts, level, service, request_id, tenant_id, cluster_id, actor_id.
Healthchecks : /healthz (process), /readyz (DB + migrations).

10. Sécurité de la plateforme

Voir la page Sécurité pour la posture sécurité Aegis Vetis : threat model, signature de la chaîne d’approvisionnement, checklist de durcissement et limites assumées de la version courante.

11. Aller plus loin

Quick start — première démo en 15 minutes.
Installation et configuration — déploiement production-ready.
Conformité et preuves d’audit — référentiels, scoring, rapport PDF signé.

Toute la documentation Retour à l'accueil