Passer au contenu principal
Exécutez votre application et le collector AgentEye dans le même Pod Kubernetes afin que la télémétrie ne traverse jamais une frontière réseau pour être collectée. Le SDK de votre application et le collector partagent une file d’événements in-pod unique, ce qui garantit un transfert de télémétrie à faible latence, en mémoire partagée — sans port localhost à exposer, sans service mesh à traverser, et avec le cycle de vie du collector directement lié au workload qu’il observe. Le certificat client mTLS que présente le collector est injecté directement dans votre pod depuis AWS Secrets Manager, de sorte que la rotation des credentials ne nécessite aucune manipulation manuelle de fichiers de votre côté. Le modèle sidecar + file partagée décrit ici est agnostique au cloud ; deux conteneurs partageant un emptyDir comme file d’événements fonctionnent sur n’importe quelle distribution Kubernetes. Seul le chemin de livraison des certificats dans ce guide (AWS Secrets Manager + le Secrets Store CSI Driver + IRSA) est spécifique à AWS / EKS. Si vous déployez ailleurs, conservez la disposition du pod et de la file, et substituez le mécanisme de montage de secrets de votre plateforme aux phases 2 et 3.
Quand utiliser ce pattern. Choisissez le single-pod lorsque votre application ne doit pas traverser une frontière réseau pour atteindre le collector (IPC in-pod à faible latence, couplage fort du cycle de vie, isolation par pod et par tenant). Pour les flottes multi-applications partageant un seul collector par nœud ou par cluster, consultez plutôt enterprise-docs/kubernetes-deployment.md.

Vue d’ensemble

Deux flux de données, deux volumes :
  • Événements (in-pod) : le SDK de votre application écrit des fichiers .jsonl dans l’emptyDir partagé sous $AGENTEYE_HOME/events/ ; le sweeper du collector les lit et les envoie. Pas de port localhost, pas de loopback — un transfert purement basé sur le système de fichiers partagé.
  • Certificat mTLS (pod ← cloud) : le Secrets Store CSI Driver monte le bundle de certificats depuis Secrets Manager dans un volume en lecture seule sous /etc/agenteye/tls/, limité au conteneur collector.
Deux parties indépendantes :
PartieResponsabilité
ExosphereÉmet le certificat client mTLS et livre le bundle dans le Secrets Manager de votre compte AWS sous un nom stable. Republié le bundle renouvelé dans le même secret avant expiration.
VousInstallez le Secrets Store CSI Driver, accordez au ServiceAccount du pod un accès en lecture au secret via IRSA, et appliquez le manifeste Pod. C’est tout.

Prérequis

Dans votre compte AWS / cluster EKS

  • Un cluster EKS avec un fournisseur OIDC associé. Vérifiez avec :
    Si la commande retourne une URL https://oidc.eks.…, OIDC est activé. Sinon, associez-en un :
  • Le Secrets Store CSI Driver et le fournisseur AWS installés dans le cluster (voir § Phase 2).
  • AWS CLI v2 et kubectl sur votre poste de travail.

Coordination avec Exosphere

Avant de déployer, Exosphere livre le bundle client mTLS dans le Secrets Manager de votre compte AWS et vous fournit :
  • Le nom du secret (convention : agenteye/mtls-client/<your-cluster>)
  • La région AWS dans laquelle réside le secret
  • L’URL du backend AgentEye à configurer pour le collector
  • Votre clé API du collector (voir enterprise-docs/api-keys.md)

Phase 1 : Ce que livre Exosphere

Vous ne générez pas vous-même le certificat client mTLS. Exosphere l’émet et livre le bundle directement dans le Secrets Manager de votre compte AWS, de sorte que le seul matériel de credentials qui arrive dans votre environnement est le secret terminé, prêt à être monté. Ce qui arrive dans votre compte :
PropriétéValeur
Nom du secretagenteye/mtls-client/<cluster-name> (stable entre les renouvellements)
RégionLa région AWS que vous avez désignée pour votre cluster EKS
ContenuUn secret JSON unique avec trois clés (client.crt, client.key et ca.crt), chacune contenant le matériel encodé en PEM
TagAgentEyeCluster=<cluster-name>
Lors du renouvellement, le même secret est mis à jour sur place avec une nouvelle version, de sorte que l’ARN et le nom ne changent jamais ; votre SecretProviderClass et votre politique IAM continuent de fonctionner sans modification. Pour le cycle de vie du certificat (validité, cadence de renouvellement, alertes d’expiration), consultez enterprise-docs/kubernetes-deployment.md.

Phase 2 : Installer le Secrets Store CSI Driver + le fournisseur AWS

Ignorez cette étape si vous faites déjà tourner un autre workload qui monte des secrets AWS via CSI.
Vérification :
Résultat attendu : Running pour chaque pod.
Pourquoi rotationPollInterval=1h ? Lorsqu’Exosphere publie un certificat renouvelé, Secrets Manager est mis à jour sur place. Le CSI Driver relit le secret à cet intervalle et réécrit les fichiers montés. Le collector lit les fichiers de certificats une seule fois au démarrage, donc il commence à présenter le certificat renouvelé uniquement après un redémarrage du processus ; voir § Rotation des certificats pour savoir comment en déclencher un.

Phase 3 : Accorder au pod l’accès en lecture au secret (IRSA)

3.1 Créer la politique IAM

Enregistrez sous agenteye-mtls-reader-policy.json :
Remplacez <region>, <account-id> et <cluster-name>. Le -* final correspond au suffixe aléatoire de six caractères qu’AWS ajoute à chaque ARN de secret. Créez la politique :

3.2 Créer le rôle IAM et le lier au ServiceAccount du pod

Cette commande crée un ServiceAccount nommé agenteye-pod avec l’annotation eks.amazonaws.com/role-arn pointant vers le nouveau rôle.

3.3 Récapitulatif des permissions IAM requises

PermissionPérimètrePourquoi
secretsmanager:GetSecretValuearn:aws:secretsmanager:<region>:<acct>:secret:agenteye/mtls-client/<cluster>-*Le CSI Driver lit le bundle de certificats à chaque montage et à chaque tick de rotation.
secretsmanager:DescribeSecretidentiqueLe CSI Driver appelle DescribeSecret pour détecter les changements de version entre les sondages.
N’accordez PAS secretsmanager:PutSecretValue, secretsmanager:UpdateSecret ou secretsmanager:DeleteSecret au pod. Le pod ne fait que lire le secret ; l’écriture de nouvelles versions est gérée par Exosphere lors de l’émission ou du renouvellement du certificat. Si le secret est chiffré avec une clé KMS gérée par le client (et non la clé aws/secretsmanager par défaut), accordez également :

Phase 4 : Déployer le Pod

4.1 SecretProviderClass

agenteye-mtls-spc.yaml :
Le bloc jmesPath indique au fournisseur AWS de scinder le secret JSON en trois fichiers distincts sur le disque. Les guillemets dans '"client.crt"' sont requis parce que JMESPath traite . comme un opérateur de sous-expression.

4.2 Manifeste Pod / Deployment

Comment les deux conteneurs communiquent. Le SDK AgentEye et le collector ne communiquent pas via un socket réseau ; il n’y a pas de port HTTP local. Le SDK écrit des lots d’événements sous forme de fichiers .jsonl dans $AGENTEYE_HOME/events/, et le collector surveille en continu ce répertoire et envoie chaque fichier. Pour un pod sidecar, cela signifie :
  • Les deux conteneurs montent le même volume emptyDir au même chemin.
  • Les deux conteneurs définissent AGENTEYE_HOME sur ce chemin.
  • L’image de votre application doit avoir le SDK AgentEye installé et configuré (voir enterprise-docs/python-sdk.md).
Lorsque AGENTEYE_HOME n’est pas défini, le SDK et le collector utilisent par défaut ~/.agenteye, et les deux conteneurs ont des répertoires home différents — ils se retrouveraient donc sur deux files séparées et le transfert échouerait silencieusement. Définissez AGENTEYE_HOME sur le même chemin explicite sur les deux conteneurs. La vérification §4.3 et la ligne correspondante dans le tableau de dépannage permettent de détecter ce cas si vous l’oubliez.
agenteye-pod.yaml (Deployment avec un replica, à faire évoluer selon vos besoins) :
Le Secret agenteye-collector-api-key contient la clé API du collector (voir enterprise-docs/api-keys.md pour le provisionnement). Appliquer :

4.3 Vérification

Résultat attendu : client.crt, client.key, ca.crt tous présents en lecture seule, appartenant à l’utilisateur du conteneur. Confirmer que la file d’événements partagée est visible par les deux conteneurs :
Si les deux listings divergent, le volume n’est pas monté dans les deux conteneurs (ou AGENTEYE_HOME diffère) ; voir § Dépannage. Test de fumée de bout en bout :
Résultat attendu : le collector envoie tous les événements en attente et affiche un résumé Done: N/N uploaded, 0 failed.. Si la file est vide, il affiche No pending files. et se termine sans rien valider — exécutez donc cette commande uniquement après que votre application a vidé au moins un événement. Notez que flush se termine avec un code non nul uniquement pour des défauts de configuration locale : configuration manquante (aucune URL/clé résolue) ou certificat TLS illisible/non parsable (voir § Dépannage). Une mauvaise clé API ne modifie pas le code de sortie — l’envoi reçoit un 401, le fichier est déplacé vers failed/, et la commande affiche tout de même [FAILED] … par fichier, puis Done: 0/N uploaded, N failed. et se termine avec 0. Pour détecter une mauvaise clé ou un envoi rejeté, lisez la sortie Done:/[FAILED] ou vérifiez la présence de fichiers dans $AGENTEYE_HOME/failed/, et non le code de sortie.

Rotation des certificats

Le certificat client est valide 90 jours et est renouvelé automatiquement environ 15 jours avant expiration ; Exosphere publie ensuite le bundle renouvelé dans le même secret Secrets Manager. De là, le flux in-pod est le suivant :
  1. Le secret Secrets Manager reçoit une nouvelle version AWSCURRENT. L’ARN et le nom sont inchangés.
  2. Dans le délai de rotationPollInterval (1h par défaut ; voir § Phase 2), le CSI Driver lit la nouvelle version et réécrit les fichiers sous /etc/agenteye/tls/.
  3. Le collector charge les fichiers de certificats une seule fois au démarrage, donc il continue de présenter l’ancien certificat jusqu’au redémarrage du processus. Pour basculer vers le matériel renouvelé, redémarrez le collector ; un rolling restart suffit :
    Pour automatiser cela, ajoutez un sidecar qui surveille /etc/agenteye/tls/ (par exemple avec inotifywait) et déclenche le rollout lorsque les fichiers changent.
Comme l’ancien certificat reste valide environ 15 jours après le renouvellement, vous disposez d’une large fenêtre pour effectuer le redémarrage sans interruption de l’ingestion. Exosphere publie le bundle renouvelé pour vous ; la seule action de routine de votre côté est de vous assurer que le collector redémarre dans cette fenêtre.

Dépannage

SymptômeCause probableCorrection
Pod bloqué en ContainerCreating, les événements montrent MountVolume.SetUp failed for volume "agenteye-mtls"Le fournisseur CSI ne peut pas atteindre Secrets ManagerVérifiez que l’IRSA est correctement lié : kubectl describe sa agenteye-pod -n <ns> affiche l’annotation eks.amazonaws.com/role-arn. Vérifiez CloudTrail pour l’appel AssumeRole.
Erreur : AccessDeniedException: not authorized to perform secretsmanager:GetSecretValueLa politique IAM est limitée au mauvais ARNLe suffixe d’ARN du secret est aléatoire ; utilisez agenteye/mtls-client/<cluster>-* avec le joker, pas l’ARN exact.
Erreur : ParameterNotFound du fournisseur AWSInadéquation entre le nom du secret dans SecretProviderClass.objects[].objectName et le secret livré par ExosphereConfirmez le nom exact avec aws secretsmanager list-secrets --filters Key=tag-key,Values=AgentEyeCluster.
Erreur jmesPath, un seul fichier montéSyntaxe JMESPath incorrecteLes points dans les clés JSON nécessitent des guillemets doubles : '"client.crt"', pas client.crt.
Le collector journalise tls: bad certificate après un renouvellementLe CSI Driver n’a pas encore sondé la nouvelle version, ou le collector tourne encore avec l’ancien certificat chargé au démarrageConfirmez que les fichiers montés ont été mis à jour (ls -l /etc/agenteye/tls/), puis redémarrez le collector pour les charger : kubectl rollout restart deploy/my-app-with-collector -n <ns>. Voir § Rotation des certificats.
Le conteneur collector crashloope avec no such file or directory: /etc/agenteye/tls/client.crtVolume pas encore peuplé au premier démarrage ; probe de démarrage trop agressiveAjoutez un délai initial ou utilisez un init container qui attend que le fichier existe : until [ -f /etc/agenteye/tls/client.crt ]; do sleep 1; done.
Pod CSI Driver en OOMKilledLimites mémoire par défaut trop basses pour les clusters avec de nombreuses SecretProviderClassesAugmentez avec --set linux.resources.limits.memory=200Mi dans l’installation Helm.
L’application tourne correctement, agenteye-collector flush indique No pending files., mais le tableau de bord AgentEye ne montre aucun événementL’application et le collector ne partagent pas la file d’événementsVérifiez que (a) les deux conteneurs montent le même emptyDir agenteye-spool au même chemin, et (b) les deux définissent AGENTEYE_HOME sur ce chemin. Exécutez les deux vérifications ls /var/lib/agenteye/ du § 4.3 ; les listings doivent correspondre.
Logs à récupérer en premier :

Référence : fichiers sur le disque dans le pod

Le pod dispose de deux chemins de données sur le disque :

Bundle de certificats mTLS : /etc/agenteye/tls/ (CSI, lecture seule, collector uniquement)

Monté par le Secrets Store CSI Driver depuis AWS Secrets Manager.
FichierContenuUtilisé par le collector comme
client.crtCertificat client encodé PEMAGENTEYE_TLS_CERT
client.keyClé privée encodée PEMAGENTEYE_TLS_KEY
ca.crtCertificat CA encodé PEMAGENTEYE_TLS_CA (optionnel, uniquement lorsque le certificat serveur AgentEye n’est pas approuvé publiquement)
Les trois fichiers sont montés en lecture seule et appartiennent à l’utilisateur du conteneur. Ils sont réécrits par le CSI Driver lors de la rotation du secret.

File d’événements : $AGENTEYE_HOME/ (emptyDir, partagé en lecture-écriture entre les deux conteneurs)

Partagée via un volume emptyDir nommé agenteye-spool.
CheminÉcrit parLu parObjectif
$AGENTEYE_HOME/events/*.jsonlApplication (SDK AgentEye)Sweeper du collectorLots d’événements que le SDK a vidés, en attente d’envoi.
$AGENTEYE_HOME/failed/Collector (en cas d’échec d’envoi)Vous (lors du débogage)Fichiers JSONL que le collector n’a pas pu envoyer après plusieurs tentatives.
$AGENTEYE_HOME/config.jsonVous (optionnel)CollectorFichier de configuration optionnel du collector (alternative aux variables d’environnement).
Les sous-répertoires events/ et failed/ sont créés automatiquement par le collector au démarrage ; aucun initContainer n’est nécessaire.

Documentation associée