emptyDir-Ereignis-Spool teilen, funktionieren auf jeder Kubernetes-Distribution. Lediglich der Pfad zur Zertifikatsauslieferung in diesem Leitfaden (AWS Secrets Manager + Secrets Store CSI Driver + IRSA) ist spezifisch für AWS/EKS. Wenn Sie eine andere Umgebung verwenden, behalten Sie das Pod- und Spool-Layout bei und ersetzen Sie den Secret-Mount-Mechanismus aus Phase 2 und 3 durch den Ihrer Plattform.
Wann sollte dieses Muster verwendet werden? Wählen Sie Single-Pod, wenn Ihre Anwendung den Collector nicht über eine Netzwerkgrenze hinweg ansprechen soll (latenzarme In-Pod-IPC, enge Lebenszyklus-Kopplung, Pod-Isolierung pro Mandant). Für Multi-App-Flotten, die einen gemeinsamen Collector pro Node oder Cluster verwenden, lesen Sie stattdessen enterprise-docs/kubernetes-deployment.md.
Auf einen Blick
- Ereignisse (In-Pod): Das SDK Ihrer Anwendung schreibt
.jsonl-Dateien in das gemeinsameemptyDirunter$AGENTEYE_HOME/events/; der Collector-Sweeper liest und lädt sie hoch. Kein localhost-Port, kein Loopback – reine Shared-Filesystem-Übergabe. - mTLS-Zertifikat (Pod ← Cloud): Der Secrets Store CSI Driver bindet das Zertifikats-Bundle aus dem Secrets Manager als schreibgeschütztes Volume unter
/etc/agenteye/tls/ein, begrenzt auf den Collector-Container.
| Partei | Verantwortlichkeit |
|---|---|
| Exosphere | Stellt das mTLS-Client-Zertifikat aus und liefert das Bundle in das Secrets Manager Ihres AWS-Kontos unter einem stabilen Namen. Veröffentlicht das erneuerte Bundle vor Ablauf erneut in demselben Secret. |
| Sie | Installieren den Secrets Store CSI Driver, gewähren dem ServiceAccount des Pods per IRSA Lesezugriff auf das Secret und wenden das Pod-Manifest an. Das ist alles. |
Voraussetzungen
In Ihrem AWS-Konto / EKS-Cluster
-
Ein EKS-Cluster mit einem zugehörigen OIDC-Provider. Überprüfen Sie dies mit:
Wenn der Befehl eine
https://oidc.eks.…-URL zurückgibt, ist OIDC aktiviert. Andernfalls verknüpfen Sie einen: - Der Secrets Store CSI Driver und der AWS-Provider sind im Cluster installiert (siehe § Phase 2).
-
AWS CLI v2 und
kubectlauf Ihrer Arbeitsstation.
Abstimmung mit Exosphere
Vor der Bereitstellung liefert Exosphere das mTLS-Client-Bundle in das Secrets Manager Ihres AWS-Kontos und stellt Folgendes bereit:- Den Secret-Namen (Konvention:
agenteye/mtls-client/<your-cluster>) - Die AWS-Region, in der das Secret gespeichert ist
- Die AgentEye-Backend-URL zur Konfiguration des Collectors
- Ihren Collector-API-Key (siehe enterprise-docs/api-keys.md)
Phase 1: Was Exosphere liefert
Sie generieren das mTLS-Client-Zertifikat nicht selbst. Exosphere stellt es aus und liefert das Bundle direkt in das Secrets Manager Ihres AWS-Kontos, sodass das einzige Credential-Material, das in Ihrer Umgebung landet, das fertige, einsatzbereite Secret ist. Was in Ihrem Konto ankommt:| Eigenschaft | Wert |
|---|---|
| Secret-Name | agenteye/mtls-client/<cluster-name> (stabil über Erneuerungen hinweg) |
| Region | Die AWS-Region, die Sie für Ihren EKS-Cluster festgelegt haben |
| Payload | Ein einzelnes JSON-Secret mit drei Schlüsseln (client.crt, client.key und ca.crt), die jeweils das PEM-kodierte Material enthalten |
| Tag | AgentEyeCluster=<cluster-name> |
SecretProviderClass und IAM-Policy bleiben unverändert funktionsfähig. Informationen zum Zertifikatslebenszyklus (Gültigkeit, Erneuerungsrhythmus, Ablaufwarnungen) finden Sie unter enterprise-docs/kubernetes-deployment.md.
Phase 2: Secrets Store CSI Driver + AWS-Provider installieren
Überspringen Sie diesen Schritt, wenn Sie bereits eine andere Arbeitslast betreiben, die AWS-Secrets per CSI einbindet.Running für jeden Pod.
Warum rotationPollInterval=1h? Wenn Exosphere ein erneuertes Zertifikat veröffentlicht, wird Secrets Manager direkt aktualisiert. Der CSI Driver liest das Secret in diesem Intervall erneut und überschreibt die eingebundenen Dateien. Der Collector liest die Zertifikatsdateien einmalig beim Start, sodass er das erneuerte Zertifikat erst nach einem Prozess-Neustart vorlegt; unter § Zertifikatsrotation erfahren Sie, wie Sie diesen auslösen.
Phase 3: Pod-Lesezugriff auf das Secret gewähren (IRSA)
3.1 IAM-Policy erstellen
Speichern Sie alsagenteye-mtls-reader-policy.json:
<region>, <account-id> und <cluster-name>. Das abschließende -* entspricht dem sechsstelligen Zufallssuffix, den AWS an jeden Secret-ARN anhängt.
Policy erstellen:
3.2 IAM-Rolle erstellen und an den ServiceAccount des Pods binden
ServiceAccount namens agenteye-pod mit der eks.amazonaws.com/role-arn-Annotation, die auf die neue Rolle verweist.
3.3 Erforderliche IAM-Berechtigungen: Zusammenfassung
| Berechtigung | Geltungsbereich | Zweck |
|---|---|---|
secretsmanager:GetSecretValue | arn:aws:secretsmanager:<region>:<acct>:secret:agenteye/mtls-client/<cluster>-* | CSI Driver liest das Zertifikats-Bundle bei jedem Mount- und Rotations-Tick. |
secretsmanager:DescribeSecret | wie oben | CSI Driver ruft DescribeSecret auf, um Versionsänderungen zwischen den Abfragen zu erkennen. |
secretsmanager:PutSecretValue, secretsmanager:UpdateSecret oder secretsmanager:DeleteSecret. Der Pod liest das Secret ausschließlich; das Schreiben neuer Versionen übernimmt Exosphere bei der Ausstellung oder Erneuerung des Zertifikats.
Wenn das Secret mit einem kundenverwalteten KMS-Schlüssel (nicht dem Standard-Schlüssel aws/secretsmanager) verschlüsselt ist, gewähren Sie zusätzlich:
Phase 4: Den Pod bereitstellen
4.1 SecretProviderClass
agenteye-mtls-spc.yaml:
jmesPath-Block weist den AWS-Provider an, das JSON-Secret in drei separate Dateien auf der Festplatte aufzuteilen. Die Anführungszeichen in '"client.crt"' sind erforderlich, weil JMESPath . als Teilausdruck-Operator behandelt.
4.2 Pod-/Deployment-Manifest
Wie die beiden Container miteinander kommunizieren. Das AgentEye-SDK und der Collector kommunizieren nicht über einen Netzwerk-Socket; es gibt keinen lokalen HTTP-Port. Das SDK schreibt Ereignis-Batches als.jsonl-Dateien in $AGENTEYE_HOME/events/, und der Collector überwacht dieses Verzeichnis kontinuierlich und lädt jede Datei hoch. Für einen Sidecar-Pod bedeutet das:
- Beide Container binden dasselbe
emptyDir-Volume am gleichen Pfad ein. - Beide Container setzen
AGENTEYE_HOMEauf diesen Pfad. - Ihr Anwendungs-Image muss das AgentEye-SDK installiert und konfiguriert haben (siehe enterprise-docs/python-sdk.md).
WennAGENTEYE_HOMEnicht gesetzt ist, verwenden sowohl das SDK als auch der Collector standardmäßig~/.agenteye, und die beiden Container haben unterschiedliche Home-Verzeichnisse, sodass sie auf zwei separate Spools landen würden und die Übergabe lautlos fehlschlägt. Setzen SieAGENTEYE_HOMEauf beiden Containern auf denselben expliziten Pfad. Die Überprüfung in §4.3 und die entsprechende Zeile im Abschnitt Fehlerbehebung erkennen dies, falls es versäumt wurde.
agenteye-pod.yaml (Deployment mit einem Replikat, nach Bedarf skalierbar):
agenteye-collector-api-key enthält den API-Key des Collectors (zur Bereitstellung siehe enterprise-docs/api-keys.md).
Anwenden:
4.3 Überprüfung
client.crt, client.key, ca.crt sind alle vorhanden, schreibgeschützt und im Besitz des Container-Benutzers.
Bestätigen Sie, dass der gemeinsame Ereignis-Spool für beide Container sichtbar ist:
AGENTEYE_HOME unterscheidet sich); siehe § Fehlerbehebung.
End-to-End-Smoke-Test:
Done: N/N uploaded, 0 failed. aus. Wenn der Spool leer ist, gibt er No pending files. aus und beendet sich, ohne etwas zu validieren – führen Sie dies daher erst aus, nachdem Ihre Anwendung mindestens ein Ereignis geflusht hat.
Beachten Sie, dass flush nur bei lokalen Konfigurationsfehlern mit einem Nicht-Null-Exitcode abbricht: fehlende Konfiguration (keine URL/kein Key auflösbar) oder ein unlesbares/nicht parsebares TLS-Zertifikat (siehe § Fehlerbehebung). Ein falscher API-Key ändert den Exitcode nicht — der Upload erhält eine 401-Antwort, die Datei wird nach failed/ verschoben, und der Befehl gibt dennoch [FAILED] … pro Datei sowie Done: 0/N uploaded, N failed. aus und beendet sich mit 0. Um einen falschen Key oder einen abgelehnten Upload zu erkennen, lesen Sie die Done:/[FAILED]-Ausgabe oder prüfen Sie, ob Dateien in $AGENTEYE_HOME/failed/ landen, nicht den Exitcode.
Zertifikatsrotation
Das Client-Zertifikat ist 90 Tage gültig und wird automatisch etwa 15 Tage vor Ablauf erneuert; Exosphere veröffentlicht das erneuerte Bundle dann in dasselbe Secrets Manager-Secret. Danach läuft der In-Pod-Ablauf wie folgt:-
Das Secret in Secrets Manager erhält eine neue
AWSCURRENT-Version. ARN und Name bleiben unverändert. -
Innerhalb des
rotationPollInterval(standardmäßig 1h; siehe § Phase 2) liest der CSI Driver die neue Version und überschreibt die Dateien unter/etc/agenteye/tls/. -
Der Collector lädt die Zertifikatsdateien einmalig beim Start, sodass er das vorherige Zertifikat weiter vorlegt, bis der Prozess neu gestartet wird. Um zum erneuerten Material zu wechseln, starten Sie den Collector neu; ein Rolling Restart reicht aus:
Um dies zu automatisieren, fügen Sie einen Sidecar hinzu, der
/etc/agenteye/tls/überwacht (z. B. mitinotifywait) und den Rollout auslöst, wenn sich die Dateien ändern.
Fehlerbehebung
| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
Pod bleibt in ContainerCreating, Ereignisse zeigen MountVolume.SetUp failed for volume "agenteye-mtls" | CSI-Provider kann Secrets Manager nicht erreichen | Prüfen Sie, ob IRSA korrekt gebunden ist: kubectl describe sa agenteye-pod -n <ns> zeigt die eks.amazonaws.com/role-arn-Annotation. Prüfen Sie CloudTrail auf den AssumeRole-Aufruf. |
Fehler: AccessDeniedException: not authorized to perform secretsmanager:GetSecretValue | IAM-Policy ist auf den falschen ARN beschränkt | Das Secret-ARN-Suffix ist zufällig; verwenden Sie agenteye/mtls-client/<cluster>-* mit Wildcard, nicht den exakten ARN. |
Fehler: ParameterNotFound vom AWS-Provider | Secret-Name stimmt nicht zwischen SecretProviderClass.objects[].objectName und dem von Exosphere gelieferten Secret überein | Bestätigen Sie den genauen Namen mit aws secretsmanager list-secrets --filters Key=tag-key,Values=AgentEyeCluster. |
jmesPath-Fehler, nur eine Datei eingebunden | JMESPath-Syntax | Die Punkte in den JSON-Schlüsseln erfordern doppelte Anführungszeichen: '"client.crt"', nicht client.crt. |
Collector-Logs zeigen tls: bad certificate nach einer Erneuerung | Der CSI Driver hat die neue Version noch nicht abgefragt, oder der Collector läuft noch mit dem beim Start geladenen vorherigen Zertifikat | Bestätigen Sie, dass die eingebundenen Dateien aktualisiert wurden (ls -l /etc/agenteye/tls/), und starten Sie dann den Collector neu, um sie zu laden: kubectl rollout restart deploy/my-app-with-collector -n <ns>. Siehe § Zertifikatsrotation. |
Collector-Container crashloopt mit no such file or directory: /etc/agenteye/tls/client.crt | Volume beim ersten Start noch nicht befüllt; Startup-Probe zu aggressiv | Fügen Sie eine kurze Anfangsverzögerung hinzu oder verwenden Sie einen Init-Container, der auf das Vorhandensein der Datei wartet: until [ -f /etc/agenteye/tls/client.crt ]; do sleep 1; done. |
CSI-Driver-Pod OOMKilled | Standard-Speicherlimits zu niedrig für Cluster mit vielen SecretProviderClasses | Erhöhen Sie --set linux.resources.limits.memory=200Mi bei der Helm-Installation. |
App läuft einwandfrei, agenteye-collector flush meldet No pending files., aber das AgentEye-Dashboard zeigt keine Ereignisse | App und Collector teilen sich nicht denselben Ereignis-Spool | Prüfen Sie, ob (a) beide Container dasselbe agenteye-spool-emptyDir am selben Pfad einbinden und (b) beide AGENTEYE_HOME auf diesen Pfad setzen. Führen Sie die beiden ls /var/lib/agenteye/-Prüfungen aus § 4.3 aus; die Auflistungen müssen übereinstimmen. |
Referenz: Dateien auf dem Pod-Datenträger
Der Pod hat zwei Datenpfade auf dem Datenträger:mTLS-Zertifikats-Bundle: /etc/agenteye/tls/ (CSI, schreibgeschützt, nur Collector)
Eingebunden durch den Secrets Store CSI Driver aus AWS Secrets Manager.
| Datei | Inhalt | Vom Collector verwendet als |
|---|---|---|
client.crt | PEM-kodiertes Client-Zertifikat | AGENTEYE_TLS_CERT |
client.key | PEM-kodierter privater Schlüssel | AGENTEYE_TLS_KEY |
ca.crt | PEM-kodiertes CA-Zertifikat | AGENTEYE_TLS_CA (optional, nur wenn das AgentEye-Server-Zertifikat nicht öffentlich vertrauenswürdig ist) |
Ereignis-Spool: $AGENTEYE_HOME/ (emptyDir, gemeinsam les- und schreibbar für beide Container)
Geteilt über ein emptyDir-Volume namens agenteye-spool.
| Pfad | Geschrieben von | Gelesen von | Zweck |
|---|---|---|---|
$AGENTEYE_HOME/events/*.jsonl | App (AgentEye-SDK) | Collector-Sweeper | Ereignis-Batches, die das SDK geflusht hat und die auf den Upload warten. |
$AGENTEYE_HOME/failed/ | Collector (bei Upload-Fehler) | Sie (beim Debugging) | JSONL-Dateien, die der Collector nach Wiederholungsversuchen nicht hochladen konnte. |
$AGENTEYE_HOME/config.json | Sie (optional) | Collector | Optionale Collector-Konfigurationsdatei (Alternative zu Umgebungsvariablen). |
events/ als auch failed/ werden beim Start automatisch vom Collector angelegt; kein initContainer erforderlich.
Verwandte Dokumentation
- enterprise-docs/collector-installation.md: Binäroptionen des Collectors, mTLS-Konfigurationsreferenz, Daemon-Modi.
- enterprise-docs/kubernetes-deployment.md: Multi-Pod-Deployment, interne Abläufe der Zertifikatsausstellung, Lebenszyklus- und Ablaufwarnungen.
- enterprise-docs/api-keys.md: Bereitstellung des vom Pod verwendeten Collector-API-Keys.
- enterprise-docs/troubleshooting.md: Clusterweiter Fehlerbehebungsindex.

