lennlay Open Source: Unsere Ansible Roles auf GitHub
Warum wir Teile unserer Plattform-Automatisierung als Open Source veröffentlichen und was dahintersteckt.
lennlay ist ein kleines Unternehmen. Wir haben kein Marketing-Budget für Konferenzauftritte und keine Zeit für Whitepaper-Kampagnen. Was wir haben, ist Arbeit, die wir für reale Projekte in regulierten Umgebungen gemacht haben - und ein Teil davon ist als Open Source auf GitHub verfügbar.
Dieser Artikel erklärt, was wir veröffentlicht haben, warum wir es tun und was wir uns von der Community erhoffen.
Was auf GitHub verfügbar ist
Unser Open-Source-Fokus liegt auf zwei Bereichen: Hardening-Rollen und Konfigurationsbaselines.
Die JBoss EAP Hardening Collection enthält Ansible-Rollen für CIS-Benchmark-konformes Hardening von JBoss EAP 7.4 und EAP 8.0. Die Rollen decken TLS-Konfiguration, Management-Interface-Absicherung, Audit-Logging, Rollenbasierte Zugriffskontrolle und Netzwerk-Interface-Einschränkungen ab. Alle Defaults orientieren sich an CIS Level 2; einzelne Controls lassen sich über Variablen aktivieren oder deaktivieren.
Daneben gibt es Konfigurationsbaseline-Rollen für verwandte Komponenten: Tomcat-Hardening, Apache HTTP Server und grundlegende Linux-Systemhärtung nach RHEL-Profil. Diese Rollen sind schlanker und weniger vollständig als die JBoss-Collection, decken aber die häufigsten Anforderungen ab.
Alles liegt auf github.com/lennlay. Die JBoss-Collection ist zusätzlich auf Ansible Galaxy verfügbar und direkt per ansible-galaxy collection install nutzbar.
Was nicht Open Source ist
SPAS - die Secure Platform Automation Suite - ist das proprietäre Produkt von lennlay. Es besteht aus einer Orchestrierungsschicht, die die Open-Source-Rollen koordiniert, einem strukturierten Ausnahmemanagement, einem Audit-Reporting-Modul und einer Golden-Image-Pipeline.
SPAS ist kein “verbessertes Open Source”. Es ist eine andere Abstraktionsebene: Während die Open-Source-Rollen einzelne Härtungsschritte auf einer Zielplattform ausführen, adressiert SPAS die operative Frage, wie diese Schritte über eine ganze Umgebung hinweg gesteuert, nachgewiesen und im Zeitverlauf konsistent gehalten werden.
Die Grenze ist bewusst gezogen: Was als Baustein nützlich ist und dessen offene Verfügbarkeit keinen Wettbewerbsnachteil bedeutet, kommt auf GitHub. Was Betrieb und Steuerung in komplexen Umgebungen ermöglicht, bleibt Bestandteil von SPAS.
Warum wir Open Source für regulierte Umgebungen wichtig finden
Regulierte Organisationen - Banken, Versicherungen, Energieversorger, KRITIS-Betreiber - haben eine berechtigte Anforderung: Sie müssen wissen, was auf ihren Systemen läuft. Nicht auf Folienniveau. Auf Code-Niveau.
Wenn ein Ansible-Playbook eine JBoss-Konfiguration verändert, will ein CISO in einer Bank wissen, welche Zeilen der Konfiguration geändert werden und warum. Das ist keine Paranoia - das ist die Grundvoraussetzung für ein funktionierendes Change-Management in einer regulierten Umgebung.
Open Source macht das einfacher. Wer unsere Rollen einsetzt, kann den Code lesen, reviewen und verstehen, bevor er etwas deployed. Es gibt keine Black Box, hinter der sich unerwartete Verhalten verstecken könnten. Das baut Vertrauen auf - und spart Zeit in Diskussionen, die in einer proprietären Umgebung unvermeidlich wären.
Wie das für uns praktisch funktioniert
Wir haben mehrere Kunden, die unsere Open-Source-Rollen vor einer SPAS-Implementierung zunächst eigenständig evaluiert haben. Das ist gut so. Wer die Rollen kennt und versteht, kann besser einschätzen, was SPAS darüber hinaus leistet.
Es gibt auch Kunden, die die Rollen einsetzen und kein SPAS brauchen oder wollen - weil ihre Umgebung kleiner ist, weil sie bereits eine Automatisierungsplattform haben oder weil ein paar gut gewartete Rollen ausreichen. Das ist ein vollständig legitimer Einsatzweg, und wir freuen uns darüber.
Open Source als verkappte Akquise-Pipeline zu betreiben, funktioniert nicht und sieht man meistens sofort. Unser Interesse an der Veröffentlichung ist echtes Interesse an der Nutzung - nicht am Funnel.
Wie man beitragen kann
Wir nehmen Issues und Pull Requests entgegen. Was wir als wertvoll betrachten:
- Dokumentierte Bug-Reports mit konkreter Fehlerbeschreibung und Environment-Angabe (Ansible-Version, JBoss-Version, RHEL-Version)
- Ergänzungen oder Korrekturen für weniger getestete Controls
- Konfigurationsbeispiele für Edge Cases, die in unserer Testumgebung nicht abgedeckt sind
Was wir nicht gut aufnehmen können: große Feature-Pull-Requests ohne vorherige Diskussion im Issue-Tracker. Wir sind ein kleines Team. Code-Review kostet Zeit, und Änderungen, die wir langfristig maintainen müssen, brauchen Kontext.
Wer konkrete Fragen zur Integration hat oder über einen Einsatz in einer regulierten Umgebung sprechen möchte, erreicht uns unter kontakt@lennlay.de.