Agenten & Orchestrierung
Pull-Orchestratoren über mTLS, die Zertifikate dorthin bringen, wo sie hingehören, die betroffenen Dienste neu laden und beweisen, dass die Erneuerung tatsächlich funktioniert hat — auf Linux und Windows.
Keine eingehenden Verbindungen. Niemals.
Ein Agent registriert sich mit einem Bootstrap-Token und erhält ein mTLS-Client-Zertifikat, signiert von einer dedizierten Agenten-CA. Neue Agenten stehen auf pending, bis ein Admin sie freigibt — erst dann dürfen sie Arbeit übernehmen. Ab da holen sie nur noch ab: keine offenen Ports auf Ihren Servern, keine eingehenden Firewall-Regeln, NAT-tauglich.
Registrieren
Bootstrap-Token; der Agent meldet seine Fähigkeiten und die Build-ID.
Freigeben
Admin-Gate, bevor ein Job übernommen wird; die mTLS-Identität wird ausgestellt.
Abholen
Der Agent holt Jobs über mTLS ab, führt sie aus und meldet die Ergebnisse.
Supervisor + Worker — konstruiert, um nie zu bricken
Der Agent ist in zwei Binaries aufgeteilt — dasselbe Muster wie bei Elastic Agent und Teleport. Der Supervisor hält die Serververbindung und wird bei einem Upgrade nie neu gestartet; der Worker läuft pro Job als kurzlebiger Subprozess. Ein Worker-Upgrade ist nur der Austausch einer Datei auf der Platte — der nächste Job nutzt das neue Binary, ohne Neustart und ohne Verbindungsabbruch.
ens0key-agent
Supervisor- ▸Hält die mTLS-Verbindung: registrieren, abholen, melden
- ▸Rotiert die mTLS-Identität an Ort und Stelle (Reset / Rekey)
- ▸Liefert aktuelle Logzeilen auf Anfrage ins UI
- ▸Führt Upgrade-Jobs für das Worker-Binary aus
ens0key-agent-worker
Worker- ▸Führt jeden Job als kurzlebigen Subprozess aus
- ▸Speicher-Deployments mit Snapshot, Post-Deploy-Schritten und Verifikation
- ▸Discovery, ADCS-Enrollment und IIS-Binding in entfernten Netzen
- ▸Wird beim Upgrade auf der Platte ersetzt — kein Neustart, keine Downtime
Flotten-Upgrades aus der Plattform
Veraltete Agenten werden mit einem Klick von der Agenten-Seite aktualisiert — ohne SSH oder RDP auf irgendeinen Host. Ein fehlgeschlagenes Upgrade kann einen Agenten nie bricken.
Einreihen
Der Upgrade-Job wird im UI eingereiht; der Supervisor übernimmt ihn beim nächsten Poll.
Prüfen
Der neue Worker wird über mTLS geladen, per SHA-256 geprüft und muss einen Selbsttest bestehen.
Tauschen
Atomares Umbenennen über das alte Binary; die Vorversion bleibt auf der Platte.
Zurückrollen
Jeder Fehler behält oder restauriert den alten Worker — der Agent bleibt durchgehend online.
Vollautomatische Erneuerung mit Sicherheitsnetz
Erneuerung ist eine Pipeline, kein Skript. Jeder Schritt wird protokolliert — und die letzten beiden liefert sonst niemand eingebaut mit.
Erneuern
Der Scheduler erneuert vor Ablauf über den CA-Konnektor.
Ausrollen
Der Agent installiert Zertifikat und Schlüssel in den Speicher — nach einem Snapshot.
Neu laden
Geordnete Post-Deploy-Schritte laden den Dienst neu, der das Zertifikat nutzt.
Verifizieren
Ein Dienstcheck bestätigt, dass das neue Zertifikat tatsächlich ausgeliefert wird.
Rollback
Jeder Fehler stellt automatisch das vorherige Zertifikat wieder her.
Post-Deploy-TLS-Verifikation mit automatischem Rollback ist fest ins Produkt eingebaut — kein Skript, das jemand nebenbei pflegt.
Eine Flotte betreiben, nicht einen Host
Blueprints
Eine komplette Agentenkonfiguration als Vorlage — Speicher, Erneuerungen, Checks — und Rollout über die ganze Flotte in einer Aktion.
Health & Logs
Online/Offline aus einem 60-Sekunden-Heartbeat; aktuelle Agenten-Logs direkt ins UI geholt.
Reset & Rekey
Die mTLS-Identität kann an Ort und Stelle neu ausgestellt werden; laufende Jobs werden sicher abgebrochen.
Fähigkeits-Routing
Agenten melden bei der Registrierung, was sie können — der Server leitet jeden Job nur an Agenten, die ihn ausführen können.
Sehen Sie einen Rollback — live
In einer Demo brechen wir die Verifikation absichtlich — und Sie sehen zu, wie der Agent das vorherige Zertifikat wiederherstellt.
Demo anfragen