Wie wir SPAS gebaut haben
SPAS begann als interne Ansible-Sammlung. Heute ist es eine Plattform-Automatisierungssuite. Die Geschichte hinter dem Produkt.
SPAS war nie als Produkt geplant. Es entstand aus einem praktischen Problem: Wir haben dieselbe Arbeit zu oft manuell gemacht.
Jedes Mal, wenn ein neues JBoss-EAP-System für einen Kunden aufgesetzt wurde, folgte ein vorhersehbarer Ablauf. Sicherheitsbaseline dokumentieren, CIS-Benchmarks manuell durchgehen, Konfigurationen anpassen, Ergebnis prüfen, dokumentieren, dem Compliance-Team übergeben. Bei einem System dauert das Tage. Bei zehn Systemen - oder zwanzig - wird es unangemessen teuer, und die Qualität beginnt zu schwanken.
Das war der eigentliche Startpunkt.
Die erste Version: eine Sammlung von Rollen
Anfangs war SPAS keine Suite, sondern eine Sammlung von Ansible-Rollen. Jede Rolle adressierte einen spezifischen Bereich: TLS-Konfiguration, Audit-Logging, Dateirechte, JVM-Härtungsparameter. Die Rollen wurden aus einem privaten Repository heraus genutzt, angepasst, und von Projekt zu Projekt kopiert - mit allen Problemen, die das mit sich bringt.
Die Kopier-Variante hat einen bestimmten Punkt überlebt: solange ein Entwickler weiß, was er tut, und die Umgebungen ähnlich sind. Sobald mehrere Projekte parallel laufen und das Team wächst, beginnen die Divergenzen. Eine Rolle, die in Projekt A angepasst wurde, bekommt Projekt B nicht mit. Ein Fix bleibt lokal. Das Wissen darüber, welche Version welches Verhalten hat, sitzt in einzelnen Köpfen.
Nach dem ersten Jahr war klar, dass das nicht skaliert.
Von Rollen zur Collection
Der erste strukturelle Schritt war die Konsolidierung in eine Ansible Collection. Eine Collection erzwingt eine klare Namespace-Struktur, versionierbares Packaging und eine explizite Abhängigkeitsverwaltung. Ab diesem Punkt gab es eine einzige Quelle: ein Repository, eine Version, eine CHANGELOG-Disziplin.
Das klingt nach einer technischen Kleinigkeit. Es war in der Praxis eine signifikante Veränderung. Erstmals war es möglich zu sagen: “Wir betreiben Version 1.2.1. Hier ist, was seit 1.1.0 geändert wurde.” Kunden mit auditierungsgetriebenen Anforderungen brauchen genau das.
In dieser Phase wurden auch die ersten systematischen Tests eingeführt. Nicht nachträglich, sondern als Bedingung dafür, dass eine Rolle in die Collection aufgenommen wurde. Molecule-Tests gegen virtuelle JBoss-Instanzen, zunächst lokal, später als CI-Lauf. Kein Merge ohne grünen Test.
Kundenfeedback als Produktentwicklung
Die Features, die SPAS heute ausmachen, sind nicht aus einer Produktplanung entstanden. Sie kommen aus konkreten Projekten.
Das automatisierte Audit-Reporting in SPAS 2.0 entstand, weil ein Kunde einen Auditor hatte, der PDF-Nachweise verlangte. Nicht JSON, nicht Logs aus einem SIEM. Ein PDF, mit Zeitstempel, Hostname und Ergebnis pro Control. Wir hätten das manuell erstellen können. Stattdessen haben wir einen Report-Task gebaut, der am Ende jedes Playbook-Laufs automatisch ausgeführt wird.
Die Golden-Image-Pipeline kam aus einem anderen Projekt. Dort gab es die Anforderung, dass neue Systeme nur aus geprüften Basisimages deployt werden dürfen. Das Image muss dokumentiert gehärtet sein, bevor es überhaupt in der Registry landet. Wir haben den Pipeline-Schritt gebaut und ihn danach als wiederverwendbares Template in die Suite aufgenommen.
Das Muster ist konsistent: ein reales Problem in einem Kundenprojekt, eine Lösung, die von Anfang an allgemein formuliert wird, Aufnahme in die Collection nach Test und Review.
Wie wir heute testen
Jede Rolle hat Molecule-Tests. Jeder Testlauf simuliert eine vollständige JBoss-EAP-Instanz in einer kontrollierten Umgebung und prüft, ob die Rolle den erwarteten Konfigurationsstand herstellt - nicht nur ob sie fehlerfrei durchläuft.
Zusätzlich gibt es Integrationstests, die das Zusammenspiel mehrerer Rollen prüfen. Weil Konfigurationsänderungen in JBoss EAP manchmal miteinander in Konflikt geraten können, reicht es nicht, Rollen isoliert zu testen. Ein Playbook, das TLS und Audit-Logging gleichzeitig konfiguriert, muss als Einheit getestet werden.
Neue Features durchlaufen einen Review-Prozess, bevor sie gemergt werden. Das ist nicht bürokratisch, sondern notwendig: In regulierten Umgebungen ist ein Fehler in einem Härtungs-Playbook kein Deployment-Fehler. Er ist ein Compliance-Ereignis.
Was SPAS heute ist
SPAS ist eine Automatisierungssuite für JBoss-EAP-Plattformen in regulierten Umgebungen. Sie deckt Härtung, Drift-Detection, Audit-Reporting und Golden-Image-Pipelines ab. Sie läuft bei Kunden in der Finanzindustrie, im Energiesektor und bei KRITIS-Betreibern.
Der Weg dorthin war nicht linear. Es war eine Abfolge von konkreten Problemen, die zu konkreten Lösungen geführt haben, die wir anschließend verallgemeinert haben. Das Produkt ist das, was übrig bleibt, wenn man diese Entscheidungen über mehrere Jahre konsequent trifft.