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
- Événements (in-pod) : le SDK de votre application écrit des fichiers
.jsonldans l’emptyDirpartagé 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.
| Partie | Responsabilité |
|---|---|
| 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. |
| Vous | Installez 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
kubectlsur 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 secret | agenteye/mtls-client/<cluster-name> (stable entre les renouvellements) |
| Région | La région AWS que vous avez désignée pour votre cluster EKS |
| Contenu | Un secret JSON unique avec trois clés (client.crt, client.key et ca.crt), chacune contenant le matériel encodé en PEM |
| Tag | AgentEyeCluster=<cluster-name> |
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.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 sousagenteye-mtls-reader-policy.json :
<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
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
| Permission | Périmètre | Pourquoi |
|---|---|---|
secretsmanager:GetSecretValue | arn: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:DescribeSecret | identique | Le CSI Driver appelle DescribeSecret pour détecter les changements de version entre les sondages. |
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 :
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
emptyDirau même chemin. - Les deux conteneurs définissent
AGENTEYE_HOMEsur ce chemin. - L’image de votre application doit avoir le SDK AgentEye installé et configuré (voir enterprise-docs/python-sdk.md).
LorsqueAGENTEYE_HOMEn’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éfinissezAGENTEYE_HOMEsur 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) :
agenteye-collector-api-key contient la clé API du collector (voir enterprise-docs/api-keys.md pour le provisionnement).
Appliquer :
4.3 Vérification
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 :
AGENTEYE_HOME diffère) ; voir § Dépannage.
Test de fumée de bout en bout :
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 :-
Le secret Secrets Manager reçoit une nouvelle version
AWSCURRENT. L’ARN et le nom sont inchangés. -
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/. -
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 avecinotifywait) et déclenche le rollout lorsque les fichiers changent.
Dépannage
| Symptôme | Cause probable | Correction |
|---|---|---|
Pod bloqué en ContainerCreating, les événements montrent MountVolume.SetUp failed for volume "agenteye-mtls" | Le fournisseur CSI ne peut pas atteindre Secrets Manager | Vé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:GetSecretValue | La politique IAM est limitée au mauvais ARN | Le suffixe d’ARN du secret est aléatoire ; utilisez agenteye/mtls-client/<cluster>-* avec le joker, pas l’ARN exact. |
Erreur : ParameterNotFound du fournisseur AWS | Inadéquation entre le nom du secret dans SecretProviderClass.objects[].objectName et le secret livré par Exosphere | Confirmez le nom exact avec aws secretsmanager list-secrets --filters Key=tag-key,Values=AgentEyeCluster. |
Erreur jmesPath, un seul fichier monté | Syntaxe JMESPath incorrecte | Les 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 renouvellement | Le CSI Driver n’a pas encore sondé la nouvelle version, ou le collector tourne encore avec l’ancien certificat chargé au démarrage | Confirmez 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.crt | Volume pas encore peuplé au premier démarrage ; probe de démarrage trop agressive | Ajoutez 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 OOMKilled | Limites mémoire par défaut trop basses pour les clusters avec de nombreuses SecretProviderClasses | Augmentez 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énement | L’application et le collector ne partagent pas la file d’événements | Vé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. |
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.
| Fichier | Contenu | Utilisé par le collector comme |
|---|---|---|
client.crt | Certificat client encodé PEM | AGENTEYE_TLS_CERT |
client.key | Clé privée encodée PEM | AGENTEYE_TLS_KEY |
ca.crt | Certificat CA encodé PEM | AGENTEYE_TLS_CA (optionnel, uniquement lorsque le certificat serveur AgentEye n’est pas approuvé publiquement) |
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 par | Lu par | Objectif |
|---|---|---|---|
$AGENTEYE_HOME/events/*.jsonl | Application (SDK AgentEye) | Sweeper du collector | Lots 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.json | Vous (optionnel) | Collector | Fichier de configuration optionnel du collector (alternative aux variables d’environnement). |
events/ et failed/ sont créés automatiquement par le collector au démarrage ; aucun initContainer n’est nécessaire.
Documentation associée
- enterprise-docs/collector-installation.md : options du binaire collector, référence de configuration mTLS, modes daemon.
- enterprise-docs/kubernetes-deployment.md : déploiement multi-pod, détails internes de l’émission des certificats, cycle de vie et alertes d’expiration.
- enterprise-docs/api-keys.md : provisionnement de la clé API du collector utilisée par le pod.
- enterprise-docs/troubleshooting.md : index de dépannage à l’échelle du cluster.

