Voraussetzungen
- Ein GitHub PAT zum Abrufen von Container-Images und zum Herunterladen von Artefakten (siehe enterprise-docs/github-token.md)
- Ein dedizierter Kubernetes-Cluster (siehe Anforderungen unten)
- Ein Storage-Bucket für Datenbank-Backups
- Netzwerkkonnektivität: Port 443 eingehend zum Load Balancer des Clusters
Schritt 1: Dedizierten Kubernetes-Cluster bereitstellen
Erstellen Sie einen Kubernetes-Cluster, der ausschließlich für AgentEye genutzt wird. Er sollte nicht mit anderen Workloads geteilt werden, damit die gesamte Plattform (Anwendungsdienste, Datenbanken, Analysen und Caching) isoliert läuft und Ihre bestehende Infrastruktur nicht beeinträchtigt.| Anforderung | Details |
|---|---|
| Distribution | Beliebiges konformes Kubernetes: EKS, GKE, AKS oder selbst verwaltet |
| Version | 1.27 oder neuer |
| Node-Pool | Minimum: 3 Nodes, jeweils 4 vCPU / 8 GB RAM (Standard-General-Purpose-Instanzen) |
| Storage | Eine Standard-StorageClass, die Block-Volumes bereitstellt (z. B. gp3 auf AWS, pd-ssd auf GCP) |
| Load Balancer | Der Cluster muss in der Lage sein, Cloud-LoadBalancer-Services bereitzustellen (Standard bei EKS, GKE, AKS) |
Exosphere installiert und verwaltet alles weitere im Cluster: Ingress-Controller, TLS-Zertifikate, Datenbanken, Caching, Monitoring und alle Anwendungs-Deployments.
Schritt 2: Zugang für das AgentEye-Team gewähren
Exosphere benötigt cluster-admin-Zugriff (oder gleichwertige umfangreiche RBAC-Berechtigungen), um Namespaces, Custom Resource Definitions, Ingress-Controller und Storage-Provisioner zu verwalten.| Anforderung | Details |
|---|---|
| Zugriffsmethode | IAM-Rolle (bevorzugt für EKS/GKE), kubeconfig oder SSO-basierter Zugriff |
| VPN / Bastion | Wenn der Kubernetes-API-Server privat ist, stellen Sie VPN-Zugangsdaten oder Bastion-Zugriff für das Exosphere-Operations-Team bereit |
Schritt 3: Netzwerkkonnektivität konfigurieren
Ihr Netzwerk-Team muss eingehenden Traffic auf Port 443 zu den Load Balancern des Clusters zulassen. Das Deployment betreibt zwei separate Load Balancer: einen für die Event-Ingestion (mTLS-geschützt) und einen für das Dashboard:| Traffic | Quelle | Ziel | Sicherheit |
|---|---|---|---|
| Event-Ingestion | Collector-Pods in Ihren Clustern | Ingest-LoadBalancer, Port 443 | mTLS (Client-Zertifikat) + API-Key |
| Dashboard | Entwickler-Browser | Dashboard-LoadBalancer, Port 443 | HTTPS auf Ihrer Domain, passwortloser E-Mail-OTP-Login |
agenteye.your-company.example) – die auf die von Exosphere bereitgestellten Load-Balancer-Hostnamen verweisen. Exosphere stellt dann automatisch öffentlich vertrauenswürdige TLS-Zertifikate für beide Hostnamen bereit, einschließlich der Erneuerungen.
Hinweis zu Port 80: Die automatische Zertifikatsausstellung und -erneuerung erfolgt über HTTP auf Port 80 jedes Load Balancers. Wenn Ihre Sicherheitsrichtlinien die Einschränkung des Dashboard-Load-Balancers auf unternehmenseigene IP-Bereiche erfordern, teilen Sie dies Exosphere vorab mit – wir wechseln dann auf eine DNS-basierte Zertifikatsvalidierung (ein zusätzlicher DNS-Eintrag auf Ihrer Seite), damit Erneuerungen auch hinter der Einschränkung funktionieren.
Ausgehend: Cluster-Nodes benötigen Internet-Zugriff, um Container-Images vonghcr.iozu beziehen. Wenn Ihr Netzwerk ausgehenden Traffic einschränkt, nehmen Sieghcr.ioin die Allowlist auf oder spiegeln Sie Images in Ihre interne Registry.
Schritt 4: Backup-Storage-Bucket bereitstellen
Datenbank-Backups werden in einem Cloud-Storage-Bucket gespeichert, der Ihnen gehört.| Anforderung | Details |
|---|---|
| Dienst | S3 (AWS), GCS (GCP) oder Azure Blob Storage |
| Zugriff | Gewähren Sie den Cluster-Nodes Schreibzugriff über eine IAM-Rolle für Service Accounts (IRSA auf EKS, Workload Identity auf GKE) oder stellen Sie Zugangsdaten bereit |
| Aufbewahrung | Sie kontrollieren die Lifecycle-Policy des Buckets (Aufbewahrungszeitraum, Archivierungsregeln). Exosphere schreibt Backups; Sie entscheiden, wie lange sie aufbewahrt werden |
Schritt 5: Ansprechpartner benennen
Benennen Sie eine Person oder einen Slack/Teams-Kanal auf Ihrer Seite für Fragen auf Cluster-Ebene: Node-Health, Cloud-Account-Limits, Netzwerkänderungen. Der tägliche Betrieb erfordert diesen Kontakt nicht.Was wir deployen
Sobald Exosphere Cluster-Zugriff hat, werden folgende Komponenten für Sie deployt und verwaltet:| Komponente | Funktion |
|---|---|
| AgentEye Server | HTTP-API, die Events von Collectors empfängt, Analysen ausführt und Daten an das Dashboard liefert |
| Dashboard | Web-Interface zur Anzeige von Agenten-Sessions, Tool-Aufrufen, Modellanfragen und Fehlern; enthält den optionalen schreibgeschützten KI-Assistenten |
| ClickHouse | Erforderlicher kanonischer Speicher für ingested Events, Analysen und Evaluierungen |
| PostgreSQL | Relationaler Speicher für Organisationen, API-Keys, Benutzer, Dashboards und gespeicherte Abfragen |
| Redis | Optionaler gemeinsamer Cache und Rate-Limit-Backend; die Plattform degradiert graceful, wenn er nicht verfügbar ist |
| KI-Assistent (optional) | Interner schreibgeschützter Assistenten-Container; bleibt deaktiviert, bis ein LLM-Endpunkt konfiguriert wird |
| Ingress-Controller | Zwei Load Balancer (einer für mTLS-geschützte Ingestion, einer für das Dashboard), die TLS mit öffentlich vertrauenswürdigen, automatisch erneuerten Zertifikaten terminieren und mTLS am Ingest-Endpunkt durchsetzen |
| cert-manager | Automatisiert die TLS-Zertifikatsbereitstellung und die Ausstellung von mTLS-Client-Zertifikaten |
| Zertifikats-Monitoring | Ein geplanter Job prüft den Ablauf von Zertifikaten und sendet Warnmeldungen (z. B. an Slack), wenn Zertifikate ihrer Erneuerung nähern |
Was Sie von uns erhalten
Nach Abschluss des Deployments erhalten Sie:| Element | Details |
|---|---|
| Dashboard-URL | Ein Hostname unter Ihrer Domain (z. B. https://agenteye.your-company.example), mit einem öffentlich vertrauenswürdigen, automatisch erneuerten TLS-Zertifikat bereitgestellt. Sie erstellen einen CNAME zum von uns bereitgestellten Load-Balancer-Hostnamen; der Login erfolgt passwortlos per E-Mail-OTP |
| Collector-Endpunkt | Der /events-Pfad des Ingest-Hostnamens (z. B. https://ingest.your-company.example/events), mTLS-geschützt |
| Client-Zertifikat-Bundle | Pro Cluster: Client-Zertifikat, privater Schlüssel und CA-Zertifikat, bereitgestellt als Kubernetes-Secret-Manifest. Einmalig pro Cluster anwenden |
| GitHub PAT | Zum Herunterladen von Collector-Binärdateien und Python-SDK-Paketen |
| Collector-API-Keys | Scoped Keys mit events:add-Berechtigung, einer pro Collector-Deployment |
| Installationsanleitungen | Schritt-für-Schritt-Dokumentation für Collector und Python-SDK |
Was Sie nach der Einrichtung tun
Ihre einzige laufende Arbeit betrifft Ihre eigenen Agent-Maschinen, nicht den AgentEye-Cluster:- Collector installieren in jedem Kubernetes-Cluster, der KI-Agenten ausführt: Client-Zertifikat einbinden und Endpunkt-URL sowie API-Key konfigurieren. Siehe enterprise-docs/collector-installation.md.
- Python-SDK integrieren in Ihren Agenten-Code. Siehe enterprise-docs/python-sdk.md.
- Dashboard öffnen in Ihrem Browser, um Agentenaktivitäten anzuzeigen.
Sicherheit
- Daten verbleiben in Ihrem Cloud-Account. Cluster, Storage und Datenbanken laufen ausnahmslos in Ihrer Umgebung. Keine Daten verlassen Ihre Grenzen.
- Sie kontrollieren den Zugriff. Der Cluster befindet sich in Ihrem Account. Sie können den Zugriff von Exosphere jederzeit prüfen, überwachen oder widerrufen. Alle Operationen werden im Audit-Log Ihrer Cloud erfasst (CloudTrail, GCP Audit Logs usw.).
- mTLS bei der Event-Ingestion. Jede Collector-Anfrage erfordert sowohl ein gültiges Client-Zertifikat als auch einen API-Key. Ein geleakter Key ist ohne das Zertifikat wertlos; ein gestohlenes Zertifikat ist ohne einen gültigen Key nutzlos.
- Dashboard-Zugangskontrolle. Das Dashboard läuft auf seinem eigenen Load Balancer, getrennt von der Event-Ingestion, und der Login erfolgt passwortlos per E-Mail-OTP, beschränkt auf die von Ihnen erlaubten E-Mail-Adressen/Domains. Eine IP-Quellbereichs-Allowlist am Load Balancer ist auf Anfrage verfügbar; da die automatische Zertifikatserneuerung den Load Balancer erreichen muss, kombiniert Exosphere die Einschränkung mit DNS-basierter Zertifikatsvalidierung, damit Erneuerungen weiterhin funktionieren.
- Zertifikate pro Cluster. Jeder Ihrer Cluster erhält ein eigenes Client-Zertifikat. Wenn ein Cluster kompromittiert wird, kann dieses Zertifikat unabhängig widerrufen werden, ohne andere zu beeinträchtigen.
Deployment-Zeitplan
| Phase | Dauer | Ihr Einsatz |
|---|---|---|
| Cluster-Bereitstellung | 1–2 Tage | Cluster bereitstellen und Exosphere Zugriff gewähren |
| Plattform-Einrichtung | 1 Tag | Keiner; Exosphere installiert alle Infrastrukturkomponenten |
| Anwendungs-Deployment | 1 Tag | Keiner; Exosphere deployt Server und Dashboard und erstellt API-Keys |
| Collector-Rollout | 1–3 Tage | Collectors in Ihren Clustern installieren (mit Unterstützung durch Exosphere) |
| Produktions-Burn-in | 1 Woche | Keiner; Exosphere überwacht und optimiert |
Support
Bei Fragen oder Problemen wenden Sie sich an Exosphere untersupport@exosphere.host.
Nächste Schritte
- Getting Started: Vollständige End-to-End-Anleitung
- Collector Installation: Collector installieren und konfigurieren
- Python SDK: Ihren Agenten-Code instrumentieren
- API Keys: Zugriff und Berechtigungen verwalten
- Troubleshooting: Häufige Probleme und Lösungen