Ansible-Infrastrukturautomatisierung schreiben und prüfen, ohne die Sicherheit zu schwächen

## Sicherheit und Stabilität vorziehen und nur das Verlangte ändern Behandle Infrastrukturautomatisierung als sicherheitskritischen Code: Ein kleiner Konfigurationsfehler kann Datenschutz, Zugriffssteuerung, Routing oder Dienstverfügbarkeit unbemerkt schwächen. - Bevorzuge Stabilität gegenüber Funktionsumfang, Sicherheit gegenüber Bequemlichkeit und Klarheit gegenüber Raffinesse. - Löse genau das angeforderte Problem. Halte unverbundene Korrekturen und spekulative Funktionen in getrennten Arbeiten. - Prüfe Annahmen durch Ausführung der betroffenen Automatisierung, bevor du eine Änderung als abgeschlossen meldest. - Widerstehe neuen Abhängigkeiten. Jede Abhängigkeit vergrößert Angriffsfläche und Wartungsaufwand. - Folge vorhandenen Mustern des Quellcodearchivs, bevor du neue Abstraktionen oder Konfigurationsmöglichkeiten einführst. - Behandle jede neue Möglichkeit als zusätzliche Testfläche; füge sie nur bei nachgewiesenem Bedarf der Nutzer hinzu. - Nutze frische Bereitstellungen für Verhaltenstests, wenn beibehaltener Zustand Fehler verbergen könnte. ## Alle Lint- und Sicherheitsprüfungen ohne eine einzige Warnung bestehen Führe vor der Prüfung die vollständige lokale Qualitätsschranke des Quellcodearchivs aus. Sie soll Konfigurations-, YAML- und Sprachprüfung, Shell-Analyse, statische Sicherheitsanalyse, Playbook-Syntaxprüfung und einschlägige Einheitstests umfassen. In der fortlaufenden Integration ist keine Warnung zulässig. Bei sicherheitskritischer Automatisierung können scheinbar kosmetische Befunde beschädigte Vorlagen, unsichere Dateiberechtigungen oder eine echte Regression im wiederkehrenden Rauschen verbergen. Behebe Befunde in dieser Reihenfolge: 1. Behebe das zugrunde liegende Problem. 2. Ist die Regel für das Quellcodearchiv ungeeignet, nimm sie in der Konfiguration des zuständigen Werkzeugs in die Zulassungsliste auf und begründe dies. 3. Nutze eine Unterdrückung direkt im Code nur als letzten Ausweg, nenne die genaue Regel und dokumentiere die Ausnahme. Verschiebe Befunde nicht in eine dauerhafte Warnungsliste. Eine Regel muss entweder bestehen oder mit einer dauerhaft nachvollziehbaren Begründung ausdrücklich übersprungen werden. Zu den üblichen Pflichtprüfungen gehören: - Beginne YAML-Dokumente mit `---` und setze mehrdeutige Ablaufsteuerungsschlüssel in Anführungszeichen, wenn der Parser dies verlangt. - Bevorzuge ausdrückliche Fehlerbedingungen wie `failed_when` gegenüber einem weitreichenden `ignore_errors`. - Verwende konsistente Abstände in Jinja2. - Gib bei jeder Datei- oder Verzeichnisaufgabe `mode` an, statt dich auf `umask` zu verlassen. - Setze Shell-Variablen in Anführungszeichen und aktiviere strenge Shell-Fehlerbehandlung. - Behandle Unterdrückungen der statischen Analyse als prüfbare Ausnahmen, nicht als Abkürzungen. Untersuche vor dem Einreichen einer Änderung den Unterschied, protokolliere die ausgeführten Prüfungen und bestätige, dass die fortlaufende Integration dieselben wesentlichen Prüfungen ausführt. ## Eingaben früh prüfen und Geheimnisse aus dem Repository heraushalten Prüfe Eingaben vor aufwendigen oder zustandsändernden Vorgängen. Weise leere Sammlungen, fehlende Konfiguration, fehlerhafte Adressen, inkompatible Versionen und Berechtigungsabweichungen am frühesten verlässlichen Punkt zurück. - Lege Datei- und Verzeichnismodi ausdrücklich fest. - Brich bei Berechtigungs-, Authentifizierungs-, Kryptografie- oder Sicherheitsgrenzfehlern ab. Reserviere Warnungen für wirklich wahlfreies Verhalten. - Mache Fehler handlungsfähig, indem du die fehlgeschlagene Bedingung und die sichere Korrekturmaßnahme nennst. - Wende geringstmögliche Rechte an: Minimiere Berechtigungen, Konten, beibehaltene Zugangsdaten und Prozessfähigkeiten. - Nutze sichere Standardwerte, starke Kryptografie, strenge Firewallregeln, minimale Protokollierung und minimale Datenaufbewahrung. - Lege Passwörter, private Schlüssel, Zugriffstoken oder Anbieterzugangsdaten niemals in der Versionsverwaltung ab. - Reagiere unverzüglich auf bestätigte Sicherheitslücken und prüfe das aktualisierte Verhalten. - Vermeide undokumentierte Behelfslösungen. Halte fest, warum sie bestehen, und verweise auf den zugehörigen Vorgang beim Ursprungsprojekt, damit Verantwortliche sie später sicher außer Betrieb nehmen können. Suche in der Codebasis nach einem etablierten Muster, bevor du eine Aufgabe, Bedingung, Anbieterroute oder ein Modul hinzufügst. Verwende den vorhandenen Steuerungsablauf wieder, sofern keine Belege seine Untauglichkeit zeigen. ## Häufige Fehler bei Ansible-Loops und Jinja2-Vorlagen vermeiden Ersetze ältere Iteration nicht mechanisch durch `loop`. Manche älteren Iterationsformen verflachen verschachtelte Listen, während `loop` ihre Struktur erhält. Prüfe die entstehende Elementform und bestätige, dass die erwarteten Dateien oder Ressourcen erzeugt werden. - Übergib eine Liste direkt an `loop`; wickle eine vorhandene Liste nicht in eine weitere Liste ein. - Verbinde Listen ausdrücklich, wenn die vorherige Konstruktion mehrere Eingaben verflacht hat. - Halte Pfadvariablen frei von abschließenden Schrägstrichen, um doppelte Trennzeichen zu vermeiden. - Setze bei nur lesenden Befehlen und Behandlungsroutinen `changed_when: false`, damit Zustandsberichte korrekt bleiben. - Verwende `failed_when: false` nur, wenn das Scheitern des Befehls ausdrücklich erwartet und sicher ist; verdecke keine unverbundenen Fehler. Bei nativer Jinja2-Auswertung gilt: - Bedingungen benötigen echte boolesche Werte, nicht Zeichenketten wie `"true"` und `"false"`. - Übergib Variablen direkt an Nachschlagefunktionen; verschachtle keinen Vorlagenausdruck in einem anderen Vorlagenausdruck. - Analysiere JSON-Text ausdrücklich, wenn eine Nachschlagefunktion Dateiinhalte zurückgibt. - Beachte, dass `default()` eine leere Zeichenkette nur ersetzt, wenn seine Möglichkeit für falsche Werte aktiviert ist. - Ersetze komplexe, von Vorlagen erzeugte Listenkomprehensionen durch gewöhnliche Automatisierungsschleifen und ausdrückliches Sammeln. - Verwende Tests für boolesche Prädikate und Filter für Datenumwandlungen. Prüfe Vorlagen mit den echten Filtern des Automatisierungsrahmens oder getreuen Nachbildungen. Syntaktische Gültigkeit allein beweist kein Verhalten im nativen Modus. ## Netzwerkdienste Schicht für Schicht untersuchen, beginnend bei den lauschenden Ports Untersuche Netzwerkautomatisierung von der niedrigsten ungewissen Schicht aus, statt jedes Verbindungsproblem als Routingfehler anzunehmen. 1. Bestätige, dass die erwarteten TCP- und UDP-Sockets an der vorgesehenen Adresse und am vorgesehenen Port lauschen. 2. Prüfe Dienst- und Socketeinheitenstatus auf Konfigurationswarnungen. 3. Prüfe die erforderlichen Netzwerkeinstellungen des Betriebssystemkerns. 4. Teste die Namensauflösung direkt gegen den eingerichteten Resolver. 5. Untersuche erst danach Firewall-, Adressübersetzungs- und richtlinienbasierte Routingregeln. Konfiguriere bei Socket-aktivierten Diensten die Socketeinheit und nicht nur die Dienstkonfiguration. Leere bei Bedarf übernommene Listener, definiere Datenstrom- und Datagramm-Listener und starte den Socket nach Änderungen neu. Das Abschalten des Sockets kann Dienstabhängigkeiten beschädigen. Berücksichtige Plattformunterschiede bewusst: - Firewallvarianten können Regeln umordnen; lege die von der Automatisierung erwartete Variante fest oder prüfe sie. - Rechner mit mehreren Netzanschlüssen benötigen für die Adressübersetzung möglicherweise eine ausdrückliche ausgehende Schnittstelle. - Bevorzuge einfache Maskierung mit angegebener Schnittstelle gegenüber unnötig komplexer Quelladressübersetzung, wenn sie die Anforderung erfüllt. - Füge Kompatibilitätsschalter bedingt hinzu, nachdem du die installierte Werkzeugversion ermittelt hast. - Setze IPv6-Endpunkte in eckige Klammern, wenn die Host-und-Port-Syntax dies erfordert. - Prüfe die Namensauflösung, bevor du Routing- oder Übersetzungsregeln neu entwirfst. Halte Netzwerkregeln einfach und teste den Paketfluss, statt Erfolg aus dem Ergebnis einer Aufgabe abzuleiten. ## Nachweisen, dass jeder Regressionstest fehlschlägt, wenn der Fehler zurückkehrt Ein Regressionstest muss zeigen, dass er den Fehler erkennt, den er verhindern soll. 1. Schreibe einen gezielten Test für den Fehlerfall. 2. Führe den Fehler vorübergehend ein oder verändere die betreffende Bedingung. 3. Bestätige, dass der neue Test aus dem beabsichtigten Grund scheitert. 4. Stelle die korrekte Implementierung wieder her und bestätige, dass der Test besteht. 5. Dokumentiere die genaue Regression, vor der der Test schützt. Hängt Verhalten von Vorlagen, Dateipfaden, Berechtigungen, Firewallregeln oder Sammlungsformen ab, teste das beobachtbare Ergebnis und nicht nur den erzeugten Text. Prüfe je nach Fall erzeugte Dateien, wirksame Modi, analysierte Werte, Listenerzustand, Paketfluss oder gerenderte Ausgabe. Aktualisiere vorhandene Tests, wenn eine Änderung Pfade oder Verhalten ändert. Nimm erst dann an, dass ein bestehender Test aussagekräftig ist, wenn seine Empfindlichkeit gegenüber dem Fehler nachgewiesen wurde. ## Bereitstellung ohne Rückfragen ermöglichen und nur tatsächlich ausgeführte Prüfungen melden Automatisierung für fortlaufende Integration oder Agenten muss einen vollständig nichtinteraktiven Ausführungspfad unterstützen. - Umgehe jede Eingabeaufforderung, wenn ihre Variable über einen freigegebenen Parameter oder eine Umgebungsvariable vorbelegt ist. - Dokumentiere die vollständige Menge der Kernvariablen, ihre Typen, Standardwerte und ihren Zweck. - Trenne anbieterspezifische Zugangsdaten von gewöhnlicher Konfiguration und akzeptiere sie nur über freigegebene Geheimniskanäle. - Verlange ausdrückliche Bestätigungsvariablen für lokale oder wirkungsreiche Bereitstellungsarten. - Gib wahlfreien Funktionen ausdrückliche boolesche Werte, damit kopflose Ausführungen nicht wegen fehlender Eingaben anhalten. - Teste den nichtinteraktiven Pfad in einer sauberen Umgebung mit repräsentativen Bedingungen mehrerer Schnittstellen und Adressen. Führe vor dem Abschluss alle Prüfwerkzeuge, Syntaxprüfungen, einschlägigen Einheitstests sowie eine frische Bereitstellung oder einen gleichwertigen Integrationstest aus. Prüfe den Unterschied auf unverbundene Korrekturen, unbegründete Abhängigkeiten, verborgene Unterdrückungen, fehlende Dateimodi, Geheimnisse und undokumentiertes Verhalten. Berichte die genauen gesammelten Belege und melde keinen Bereitstellungserfolg, wenn nur statische Prüfungen ausgeführt wurden.