1. Threat Model

Vertiefung und Abgabebeispiel zu Threat Model

Eine vollständige Bearbeitung von Threat Model besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Threat Model

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Threat Model

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Threat Model zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Threat Model

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Threat Model immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Threat Model

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Threat Model

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Threat Model

Betriebsnotiz für Threat Model

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Threat Model ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

2. Assets und Angriffsflächen

Vertiefung und Abgabebeispiel zu Assets und Angriffsflächen

Eine vollständige Bearbeitung von Assets und Angriffsflächen besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Assets und Angriffsflächen

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Assets und Angriffsflächen

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Assets und Angriffsflächen zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Assets und Angriffsflächen

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Assets und Angriffsflächen immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Assets und Angriffsflächen

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Assets und Angriffsflächen

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Assets und Angriffsflächen

Betriebsnotiz für Assets und Angriffsflächen

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Assets und Angriffsflächen ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

3. Inventory-Risiken

Vertiefung und Abgabebeispiel zu Inventory-Risiken

Eine vollständige Bearbeitung von Inventory-Risiken besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Inventory-Risiken

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Inventory-Risiken

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Inventory-Risiken zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Inventory-Risiken

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Inventory-Risiken immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Inventory-Risiken

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Inventory-Risiken

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Inventory-Risiken

Betriebsnotiz für Inventory-Risiken

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Inventory-Risiken ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

4. Credential-Risiken

Vertiefung und Abgabebeispiel zu Credential-Risiken

Eine vollständige Bearbeitung von Credential-Risiken besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Credential-Risiken

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Credential-Risiken

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Credential-Risiken zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Credential-Risiken

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Credential-Risiken immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Credential-Risiken

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Credential-Risiken

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Credential-Risiken

Betriebsnotiz für Credential-Risiken

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Credential-Risiken ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

5. Privilege Escalation

Vertiefung und Abgabebeispiel zu Privilege Escalation

Eine vollständige Bearbeitung von Privilege Escalation besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Privilege Escalation

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Privilege Escalation

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Privilege Escalation zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Privilege Escalation

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Privilege Escalation immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Privilege Escalation

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Privilege Escalation

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Privilege Escalation

Betriebsnotiz für Privilege Escalation

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Privilege Escalation ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

6. Secrets und Vault

Vertiefung und Abgabebeispiel zu Secrets und Vault

Eine vollständige Bearbeitung von Secrets und Vault besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Secrets und Vault

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Secrets und Vault

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Secrets und Vault zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Secrets und Vault

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Secrets und Vault immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Secrets und Vault

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Secrets und Vault

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Secrets und Vault

Betriebsnotiz für Secrets und Vault

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Secrets und Vault ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

7. No-log und Diff-Risiken

Vertiefung und Abgabebeispiel zu No-log und Diff-Risiken

Eine vollständige Bearbeitung von No-log und Diff-Risiken besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für No-log und Diff-Risiken

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für No-log und Diff-Risiken

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird No-log und Diff-Risiken zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu No-log und Diff-Risiken

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird No-log und Diff-Risiken immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für No-log und Diff-Risiken

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für No-log und Diff-Risiken

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei No-log und Diff-Risiken

Betriebsnotiz für No-log und Diff-Risiken

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

No-log und Diff-Risiken ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

8. Supply Chain

Vertiefung und Abgabebeispiel zu Supply Chain

Eine vollständige Bearbeitung von Supply Chain besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Supply Chain

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Supply Chain

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Supply Chain zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Supply Chain

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Supply Chain immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Supply Chain

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Supply Chain

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Supply Chain

Betriebsnotiz für Supply Chain

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Supply Chain ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

9. Collections und Rollen

Vertiefung und Abgabebeispiel zu Collections und Rollen

Eine vollständige Bearbeitung von Collections und Rollen besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Collections und Rollen

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Collections und Rollen

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Collections und Rollen zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Collections und Rollen

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Collections und Rollen immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Collections und Rollen

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Collections und Rollen

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Collections und Rollen

Betriebsnotiz für Collections und Rollen

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Collections und Rollen ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

10. CI-Security

Vertiefung und Abgabebeispiel zu CI-Security

Eine vollständige Bearbeitung von CI-Security besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für CI-Security

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für CI-Security

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird CI-Security zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu CI-Security

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird CI-Security immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für CI-Security

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für CI-Security

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei CI-Security

Betriebsnotiz für CI-Security

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

CI-Security ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

11. AWX/AAP-RBAC

Vertiefung und Abgabebeispiel zu AWX/AAP-RBAC

Eine vollständige Bearbeitung von AWX/AAP-RBAC besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für AWX/AAP-RBAC

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für AWX/AAP-RBAC

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird AWX/AAP-RBAC zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu AWX/AAP-RBAC

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird AWX/AAP-RBAC immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für AWX/AAP-RBAC

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für AWX/AAP-RBAC

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei AWX/AAP-RBAC

Betriebsnotiz für AWX/AAP-RBAC

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

AWX/AAP-RBAC ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

12. Execution Environments

Vertiefung und Abgabebeispiel zu Execution Environments

Eine vollständige Bearbeitung von Execution Environments besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Execution Environments

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Execution Environments

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Execution Environments zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Execution Environments

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Execution Environments immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Execution Environments

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Execution Environments

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Execution Environments

Betriebsnotiz für Execution Environments

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Execution Environments ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

13. Windows und Netzwerkautomation

Vertiefung und Abgabebeispiel zu Windows und Netzwerkautomation

Eine vollständige Bearbeitung von Windows und Netzwerkautomation besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Windows und Netzwerkautomation

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Windows und Netzwerkautomation

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Windows und Netzwerkautomation zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Windows und Netzwerkautomation

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Windows und Netzwerkautomation immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Windows und Netzwerkautomation

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Windows und Netzwerkautomation

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Windows und Netzwerkautomation

Betriebsnotiz für Windows und Netzwerkautomation

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Windows und Netzwerkautomation ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

14. Incident Response

Vertiefung und Abgabebeispiel zu Incident Response

Eine vollständige Bearbeitung von Incident Response besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Incident Response

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Incident Response

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Incident Response zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Incident Response

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Incident Response immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Incident Response

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Incident Response

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Incident Response

Betriebsnotiz für Incident Response

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Incident Response ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

15. Security-Checkliste

Vertiefung und Abgabebeispiel zu Security-Checkliste

Eine vollständige Bearbeitung von Security-Checkliste besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Minimalartefakte für Security-Checkliste

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Security-Checkliste

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Security-Checkliste zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Security-Checkliste

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Security-Checkliste immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Beispielablauf für Security-Checkliste

ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Security-Checkliste

• Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
• Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
• Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
• Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
• Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
• Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
• Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Security-Checkliste

Betriebsnotiz für Security-Checkliste

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Security-Checkliste ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

Quellen und weiterführende Referenzen

• Offizielle Ansible Community Documentation: https://docs.ansible.com/
• Ansible Getting Started: https://docs.ansible.com/projects/ansible/latest/getting_started/index.html
• Inventory Guide: https://docs.ansible.com/projects/ansible/latest/inventory_guide/index.html
• Playbook Guide: https://docs.ansible.com/projects/ansible/latest/playbook_guide/index.html
• Module Index: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/index.html
• Vault Guide: https://docs.ansible.com/projects/ansible/latest/vault_guide/index.html
• Ansible Lint: https://ansible.readthedocs.io/projects/lint/
• Molecule: https://ansible.readthedocs.io/projects/molecule/
• AWX: https://github.com/ansible/awx
• Red Hat Certifications: https://www.redhat.com/en/services/certifications