lennlay.com EN
Blog
JBOSS EAP ANSIBLEOPEN SOURCESECURITY

JBoss-Hardening mit der lennlay Ansible Collection: Ein Walkthrough

Schritt für Schritt durch unsere Open-Source Ansible Collection für JBoss EAP Security Hardening.

Autor
Justin B. Lucht
Veröffentlicht
Lesezeit
3 Min. Lesezeit

Dieser Artikel zeigt Schritt für Schritt, wie die lennlay Ansible Collection für JBoss EAP Hardening in einer realen Umgebung eingesetzt wird. Keine Werbeaussagen, keine vereinfachten Beispiele: ein konkreter Walkthrough von der Installation bis zum ersten Compliance-Report.

Die Collection ist auf Ansible Galaxy und GitHub verfügbar. Zielgruppe dieses Artikels sind Engineers, die JBoss EAP in regulierten Umgebungen betreiben und eine reproduzierbare Härtungsstrategie aufbauen wollen.

Voraussetzungen

Bevor die Collection installiert wird, müssen folgende Voraussetzungen erfüllt sein:

  • Ansible Core 2.15 oder neuer
  • Zugriff auf JBoss EAP 7.4 oder 8.0 (Installationspfad mit Schreibrechten)
  • JBoss Management CLI erreichbar (lokal oder remote)
  • RHEL 8 oder RHEL 9 als Zielsystem (andere Distributionen sind nicht offiziell getestet)

Der Ansible-Controller kann ein lokales System, ein AWX-Setup oder eine Red Hat Ansible Automation Platform-Instanz sein. Die Collection funktioniert in allen drei Szenarien.

Installation

Die Installation läuft über Ansible Galaxy:

ansible-galaxy collection install lennlay.jboss_eap_hardening

Alternativ kann die Collection aus dem GitHub-Repository installiert werden, wenn der aktuelle Entwicklungsstand gebraucht wird:

ansible-galaxy collection install git+https://github.com/lennlay/ansible-collection-jboss-eap-hardening.git

Nach der Installation sind alle enthaltenen Rollen im Namespace lennlay.jboss_eap_hardening verfügbar.

Was die Collection enthält

Die Collection besteht aus fünf Rollen, die unabhängig oder kombiniert eingesetzt werden können:

jboss_eap_hardening_base - Grundkonfiguration: SSL/TLS-Einstellungen (Cipher Suites, Protokollversionen), Management-Interface-Absicherung, Deaktivierung nicht benötigter Subsysteme.

jboss_eap_hardening_logging - Audit-Log-Aktivierung, strukturiertes Log-Format, Log-Rotation-Konfiguration. Erzeugt einen Audit-Trail, der in regulierten Umgebungen für Compliance-Nachweise benötigt wird.

jboss_eap_hardening_access - Rollenbasierter Zugriff auf die Management-Schnittstelle, Konfiguration von Management-Benutzern, Einschränkung von Remote-Access-Pfaden.

jboss_eap_hardening_network - Bind-Adressen, Interface-Konfiguration, Deaktivierung von AJP-Connector wenn nicht benötigt.

jboss_eap_compliance_check - Standalone-Prüfrolle ohne Remediierung. Prüft den aktuellen Zustand gegen CIS-Benchmark-Controls und liefert einen strukturierten JSON-Report zurück. Nützlich für regelmäßige Compliance-Checks ohne Konfigurationseingriff.

Ein vollständiges Beispiel-Playbook

Ein typisches Hardening-Playbook, das alle Konfigurationsrollen kombiniert und mit einem abschließenden Compliance-Check endet:

---
- name: JBoss EAP Hardening
  hosts: jboss_servers
  become: true
  vars:
    jboss_home: /opt/jboss-eap-8.0
    jboss_management_user: admin
    jboss_management_password: "{{ vault_jboss_mgmt_password }}"
    jboss_tls_enabled: true
    jboss_tls_keystore_path: /opt/jboss-eap-8.0/standalone/configuration/keystore.jks
    jboss_tls_keystore_password: "{{ vault_keystore_password }}"
    jboss_ajp_enabled: false
    jboss_audit_log_enabled: true
    jboss_cis_level: 2

  roles:
    - role: lennlay.jboss_eap_hardening.jboss_eap_hardening_base
    - role: lennlay.jboss_eap_hardening.jboss_eap_hardening_logging
    - role: lennlay.jboss_eap_hardening.jboss_eap_hardening_access
    - role: lennlay.jboss_eap_hardening.jboss_eap_hardening_network
    - role: lennlay.jboss_eap_hardening.jboss_eap_compliance_check
      vars:
        compliance_report_path: /tmp/jboss_compliance_{{ inventory_hostname }}.json

Sensible Werte wie Passwörter werden nicht im Klartext gespeichert. Das Beispiel verwendet Ansible Vault-Variablen (vault_*). Wer noch kein Vault-Setup hat, findet in der offiziellen Ansible-Dokumentation den Einstieg.

Variablen und Anpassung

Alle sicherheitsrelevanten Defaults orientieren sich an CIS Level 2. Wer bestimmte Controls deaktivieren muss - etwa weil eine Applikation aus Kompatibilitätsgründen eine ältere TLS-Version benötigt - kann das gezielt über Variablen steuern.

Ein Beispiel für eine gruppenspezifische Variablen-Datei (group_vars/legacy_apps.yml):

# TLS 1.1 aus Kompatibilitätsgründen erlauben (dokumentierte Ausnahme, Review-Datum: 2025-09-01)
jboss_tls_min_version: "TLSv1.1"
jboss_tls_allowed_protocols:
  - TLSv1.1
  - TLSv1.2
  - TLSv1.3

Der Kommentar mit Review-Datum ist keine technische Anforderung, aber eine sinnvolle Konvention: Wer Ausnahmen dokumentiert, verhindert, dass sie vergessen werden.

Es gibt keine hartcodierten Passwörter oder Environment-spezifischen Werte in der Collection. Alles, was umgebungsabhängig ist, wird als Variable erwartet.

Was nach dem ersten Lauf zu erwarten ist

Beim ersten Playbook-Lauf in einer noch nicht gehärteten Umgebung sind typischerweise viele changed-Tasks zu sehen. Das ist normal. JBoss EAP kommt in der Standardinstallation mit Defaults, die auf Funktionalität und nicht auf Sicherheit ausgelegt sind.

Die jboss_eap_compliance_check-Rolle erzeugt am Ende einen JSON-Report unter dem konfigurierten Pfad. Der Report enthält für jeden geprüften CIS-Control: Status (pass/fail), den tatsächlichen Wert, den Soll-Wert und - wenn vorhanden - eine Ausnahmereferenz.

Bei Folgeläufen sollte der Großteil der Tasks ok zurückgeben - ein Zeichen, dass die Konfiguration im Soll-Zustand ist. Tasks, die bei jedem Lauf changed melden, deuten auf ein Problem hin: Entweder läuft etwas gegen die Konfiguration (ein anderer Prozess, ein manueller Eingriff), oder eine Rolle arbeitet nicht idempotent. In letzterem Fall bitte ein Issue im GitHub-Repository eröffnen.

CVE-spezifische Patches und Ausnahmen

Die Collection enthält keine automatischen CVE-Patches. CVE-spezifische Maßnahmen - etwa das Deaktivieren bestimmter Log4j-Bindings oder das Patchen bekannter Request-Smuggling-Vektoren - werden als separate Tasks in projektspezifischen Playbooks implementiert, nicht in der Collection selbst.

Der Grund: CVE-Behandlung ist environment-spezifisch. Eine Collection, die automatisch CVE-Maßnahmen aufspielt, kann in einer Umgebung mit spezifischen Applikationsanforderungen unvorhergesehene Probleme erzeugen. Die Collection liefert die Baseline; was darüber hinausgeht, liegt in der Verantwortung des Teams, das die Umgebung kennt.

Weiterführendes

Wer die Collection produktiv einsetzen will und Fragen zur Integration in eine bestehende Ansible Automation Platform hat, kann sich direkt an uns wenden: kontakt@lennlay.de.

Das vollständige Repository mit Beispiel-Playbooks und der Variablen-Referenz liegt auf github.com/lennlay. Issues und Pull Requests sind willkommen - bevorzugt mit reproduzierbarem Beispiel und Angabe der Ansible- und JBoss-EAP-Version.