Prérequis
- Un GitHub PAT pour récupérer les images de conteneurs et télécharger les artefacts (voir enterprise-docs/github-token.md)
- Un cluster Kubernetes dédié (voir les exigences ci-dessous)
- Un bucket de stockage pour les sauvegardes de bases de données
- Connectivité réseau : port 443 entrant vers le load balancer du cluster
Étape 1 : Provisionner un cluster Kubernetes dédié
Créez un cluster Kubernetes dédié à AgentEye. Il ne doit pas être partagé avec d’autres charges de travail, afin que l’ensemble de la plateforme (services applicatifs, bases de données, analyses et cache) s’exécute de manière isolée sans impacter votre infrastructure existante.| Exigence | Détails |
|---|---|
| Distribution | Tout Kubernetes conforme : EKS, GKE, AKS ou autogéré |
| Version | 1.27 ou ultérieure |
| Pool de nœuds | Minimum : 3 nœuds, 4 vCPU / 8 Go de RAM chacun (instances standard à usage général) |
| Stockage | Une StorageClass par défaut qui provisionne des volumes bloc (ex. gp3 sur AWS, pd-ssd sur GCP) |
| Load Balancer | Le cluster doit être capable de provisionner des services LoadBalancer cloud (par défaut sur EKS, GKE, AKS) |
Exosphere installe et gère tout le reste à l’intérieur du cluster : contrôleurs d’ingress, certificats TLS, bases de données, cache, supervision et tous les déploiements applicatifs.
Étape 2 : Accorder l’accès à l’équipe AgentEye
Exosphere a besoin d’un accès cluster-admin (ou d’un RBAC étendu équivalent) pour gérer les namespaces, les définitions de ressources personnalisées, les contrôleurs d’ingress et les provisionneurs de stockage.| Exigence | Détails |
|---|---|
| Méthode d’accès | Rôle IAM (recommandé pour EKS/GKE), kubeconfig ou accès SSO |
| VPN / bastion | Si le serveur API Kubernetes est privé, fournissez des identifiants VPN ou un accès bastion à l’équipe opérationnelle Exosphere |
Étape 3 : Configurer la connectivité réseau
Votre équipe réseau doit autoriser le trafic entrant sur le port 443 vers les load balancers du cluster. Le déploiement utilise deux load balancers distincts : un pour l’ingestion d’événements (protégé par mTLS) et un pour le tableau de bord :| Trafic | Source | Destination | Sécurité |
|---|---|---|---|
| Ingestion d’événements | Pods collecteurs dans vos clusters | Load Balancer d’ingestion, port 443 | mTLS (certificat client) + clé API |
| Tableau de bord | Navigateurs des développeurs | Load Balancer du tableau de bord, port 443 | HTTPS sur votre domaine, connexion OTP par email sans mot de passe |
agenteye.votre-entreprise.example) — pointant vers les noms d’hôtes des load balancers fournis par Exosphere. Exosphere provisionne ensuite automatiquement des certificats TLS publiquement fiables pour les deux noms d’hôtes, y compris les renouvellements.
Note sur le port 80 : l’émission et le renouvellement automatiques des certificats s’effectuent via HTTP sur le port 80 de chaque load balancer. Si votre politique de sécurité exige de restreindre le load balancer du tableau de bord à des plages d’IP d’entreprise, informez-en Exosphere au préalable — nous basculons la validation des certificats vers une méthode basée sur DNS (un enregistrement DNS supplémentaire de votre côté) afin que les renouvellements continuent de fonctionner derrière la restriction.
Sortant : les nœuds du cluster ont besoin d’un accès internet pour récupérer les images de conteneurs depuisghcr.io. Si votre réseau restreint le trafic sortant, autorisezghcr.ioou mirrorez les images vers votre registre interne.
Étape 4 : Fournir un bucket de stockage pour les sauvegardes
Les sauvegardes des bases de données sont stockées dans un bucket de stockage cloud qui vous appartient.| Exigence | Détails |
|---|---|
| Service | S3 (AWS), GCS (GCP) ou Azure Blob Storage |
| Accès | Accordez un accès en écriture aux nœuds du cluster via un rôle IAM pour les comptes de service (IRSA sur EKS, Workload Identity sur GKE) ou fournissez des identifiants |
| Rétention | Vous contrôlez la politique de cycle de vie du bucket (durée de rétention, règles d’archivage). Exosphere écrit les sauvegardes ; vous décidez de leur durée de conservation |
Étape 5 : Désigner un point de contact
Désignez une personne ou un canal Slack/Teams de votre côté pour les problèmes au niveau du cluster : santé des nœuds, limites du compte cloud, changements réseau. Les opérations quotidiennes n’impliquent pas ce contact.Ce que nous déployons
Une fois qu’Exosphere a accès au cluster, les composants suivants sont déployés et gérés pour vous :| Composant | Rôle |
|---|---|
| AgentEye Server | API HTTP qui reçoit les événements des collecteurs, exécute les analyses et sert les données au tableau de bord |
| Tableau de bord | Interface web pour visualiser les sessions d’agents, les appels d’outils, les requêtes aux modèles et les erreurs ; héberge l’assistant IA optionnel en lecture seule |
| ClickHouse | Magasin canonique requis pour les événements ingérés, les analyses et les évaluations |
| PostgreSQL | Magasin relationnel pour les organisations, les clés API, les utilisateurs, les tableaux de bord et les requêtes sauvegardées |
| Redis | Cache partagé optionnel et backend de limitation de débit ; la plateforme se dégrade de manière gracieuse en cas d’indisponibilité |
| Assistant IA (optionnel) | Conteneur d’assistant interne en lecture seule ; reste désactivé jusqu’à la configuration d’un point de terminaison LLM |
| Contrôleurs d’ingress | Deux load balancers (un pour l’ingestion protégée par mTLS, un pour le tableau de bord) terminant TLS avec des certificats publiquement fiables et renouvelés automatiquement, et appliquant le mTLS sur le point de terminaison d’ingestion |
| cert-manager | Automatise le provisionnement des certificats TLS et l’émission des certificats client mTLS |
| Supervision des certificats | Une tâche planifiée vérifie l’expiration des certificats et envoie des alertes (ex. vers Slack) à l’approche du renouvellement |
Ce que nous vous fournissons
Une fois le déploiement terminé, vous recevez :| Élément | Détails |
|---|---|
| URL du tableau de bord | Un nom d’hôte sous votre domaine (ex. https://agenteye.votre-entreprise.example), servi avec un certificat TLS publiquement fiable et renouvelé automatiquement. Vous créez un CNAME vers le nom d’hôte du load balancer que nous fournissons ; la connexion est sans mot de passe via OTP par email |
| Point de terminaison du collecteur | Le chemin /events du nom d’hôte d’ingestion (ex. https://ingest.votre-entreprise.example/events), protégé par mTLS |
| Bundle de certificat client | Par cluster : certificat client, clé privée et certificat CA livrés sous forme de manifest Kubernetes Secret. À appliquer une fois par cluster |
| GitHub PAT | Pour télécharger les binaires du collecteur et les packages du SDK Python |
| Clés API du collecteur | Clés à portée limitée avec la permission events:add, une par déploiement de collecteur |
| Guides d’installation | Documentation pas à pas pour le collecteur et le SDK Python |
Ce que vous faites après la mise en place
Votre seul travail continu concerne vos propres machines d’agents, et non le cluster AgentEye :- Installez le collecteur dans chaque cluster Kubernetes exécutant des agents IA : montez le certificat client et configurez l’URL du point de terminaison et la clé API. Voir enterprise-docs/collector-installation.md.
- Intégrez le SDK Python dans votre code d’agent. Voir enterprise-docs/python-sdk.md.
- Ouvrez le tableau de bord dans votre navigateur pour visualiser l’activité des agents.
Sécurité
- Les données restent dans votre compte cloud. Le cluster, le stockage et les bases de données s’exécutent tous dans votre environnement. Aucune donnée ne quitte votre périmètre.
- Vous contrôlez l’accès. Le cluster est dans votre compte. Vous pouvez auditer, surveiller ou révoquer l’accès d’Exosphere à tout moment. Toutes les opérations passent par le journal d’audit de votre cloud (CloudTrail, GCP Audit Logs, etc.).
- mTLS sur l’ingestion d’événements. Chaque requête de collecteur nécessite à la fois un certificat client valide et une clé API. Une clé divulguée est inutilisable sans le certificat ; un certificat volé est inutilisable sans une clé valide.
- Contrôle d’accès au tableau de bord. Le tableau de bord fonctionne sur son propre load balancer, distinct de l’ingestion d’événements, et la connexion est sans mot de passe via OTP par email, restreinte aux adresses e-mail/domaines que vous autorisez. Une liste d’autorisation de plages d’IP sources sur le load balancer est disponible sur demande ; comme le renouvellement automatique des certificats doit atteindre le load balancer, Exosphere associe la restriction à une validation de certificat basée sur DNS afin que les renouvellements continuent de fonctionner.
- Certificats par cluster. Chacun de vos clusters reçoit son propre certificat client. Si un cluster est compromis, ce certificat est révoqué indépendamment sans affecter les autres.
Calendrier de déploiement
| Phase | Durée | Votre implication |
|---|---|---|
| Provisionnement du cluster | 1-2 jours | Provisionner le cluster et accorder l’accès à Exosphere |
| Mise en place de la plateforme | 1 jour | Aucune ; Exosphere installe tous les composants d’infrastructure |
| Déploiement de l’application | 1 jour | Aucune ; Exosphere déploie le serveur, le tableau de bord et crée les clés API |
| Déploiement des collecteurs | 1-3 jours | Installer les collecteurs dans vos clusters (avec l’accompagnement d’Exosphere) |
| Rodage en production | 1 semaine | Aucune ; Exosphere surveille et ajuste |
Support
Pour toute question ou problème, contactez Exosphere à l’adressesupport@exosphere.host.
Prochaines étapes
- Démarrage : parcours complet de bout en bout
- Installation du collecteur : installer et configurer le collecteur
- SDK Python : instrumenter votre code d’agent
- Clés API : gérer les accès et les permissions
- Dépannage : problèmes courants et solutions