Workflow: Ansible Playbook Generation¶
Ansible Playbooks für Multi-Vendor Umgebungen generieren - von einzelnen Tasks bis zu kompletten Rollen.
Übersicht¶
| Aspekt | Details |
|---|---|
| Ziel | Production-ready Playbooks für Netzwerk-Infrastruktur |
| Features | Plan Mode, Skills, Sub-Agents |
| Vendors | FortiGate, OPNsense, Cisco, Nokia, VeloCloud, Meraki, Linux |
| Output | Playbooks, Rollen, Inventory, Vault-Beispiele |
Feature-Kombination¶
┌─────────────────────────────────────────────────────────┐
│ PLAN MODE │
│ "Ich will Playbooks für X" → Strukturierter Plan │
└───────────────────────────┬─────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ ANSIBLE SKILL │
│ SKILL.md mit Vendor-Templates und Best Practices │
└───────────────────────────┬─────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│Sub-Agent │ │Sub-Agent │ │Sub-Agent │
│FortiGate │ │OPNsense │ │Linux │
│ (Haiku) │ │ (Haiku) │ │ (Haiku) │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└───────────────┼───────────────┘
▼
┌──────────────────┐
│ Konsolidierung │
│ + Review │
└──────────────────┘
Voraussetzung: Ansible Skill¶
Falls noch nicht vorhanden, Skill erstellen:
# ~/.claude/skills/ansible-playbook-builder/SKILL.md
---
name: ansible
description: Generiert Ansible Playbooks für Netzwerk-Infrastruktur.
Aktiviert bei Ansible, Playbook, Automatisierung, oder Vendor-Namen
wie FortiGate, OPNsense, Cisco.
---
# Ansible Playbook Generator
## Unterstützte Plattformen
- FortiGate (fortinet.fortios)
- OPNsense (ansibleguy.opnsense)
- Cisco IOS/IOS-XE (cisco.ios)
- Cisco NX-OS (cisco.nxos)
- Nokia SR OS (nokia.sros)
- VeloCloud (velocloud.velocloud)
- Meraki (cisco.meraki)
- FortiManager (fortinet.fortimanager)
- FortiAnalyzer (fortinet.fortianalyzer)
- Linux (ansible.builtin)
## Output-Struktur
Generiere immer diese Struktur:
```text
roles/
└── <role_name>/
├── tasks/
│ └── main.yml
├── handlers/
│ └── main.yml
├── defaults/
│ └── main.yml
├── vars/
│ └── main.yml
├── templates/
│ └── *.j2
└── README.md
Best Practices¶
- Idempotenz: Tasks müssen wiederholt ausführbar sein
- Tags: Jeder logische Block bekommt Tags
- Handlers: Für Service-Restarts, Config-Reloads
- Vault: Credentials immer als Vault-Variablen
- Check Mode: Tasks müssen
--checkunterstützen
Vendor-spezifische Hinweise¶
FortiGate¶
- Collection:
fortinet.fortios - Access Token bevorzugt über User/Pass
vdomimmer explizit setzen
OPNsense¶
- Collection:
ansibleguy.opnsense - API Key + Secret erforderlich
- SSL Verify beachten bei Self-Signed
Cisco IOS¶
- Collection:
cisco.ios ansible_network_os: cisco.ios.iosansible_connection: network_cli/ansible
Erstelle ein Playbook das auf allen FortiGates: 1. Admin-Passwort rotiert 2. Neues Passwort in Vault speichert 3. Altes Passwort dokumentiert
### Schritt 2: Plan reviewen
Claude erstellt erst einen Plan:
```markdown
## Plan: FortiGate Password Rotation
### Phase 1: Vorbereitung
1. Rolle `fortigate_password_rotate` scaffolden
2. Vault-Struktur für Credentials definieren
### Phase 2: Implementation
3. Task: Aktuelles Passwort aus Vault lesen
4. Task: Neues Passwort generieren
5. Task: Passwort auf FortiGate setzen
6. Task: Neues Passwort in Vault schreiben
### Phase 3: Safety
7. Handler: Rollback bei Fehler
8. Verify-Task: Login mit neuem Passwort testen
Dateien: 6
Geschätzte Zeit: 10 Minuten
Schritt 3: Feedback geben¶
Sieht gut aus, aber:
- Füge Backup der Config hinzu vor Änderung
- Nutze lookup plugin für Passwort-Generierung
Schritt 4: Generierung¶
Nach Approval generiert Claude die Dateien.
Workflow: Multi-Vendor Playbook-Set¶
Für mehrere Vendors gleichzeitig - hier lohnen sich Sub-Agents.
Schritt 1: Übergreifende Anforderung¶
/ansible --plan
Erstelle ein Playbook-Set für Firewall-Hardening:
- FortiGate
- OPNsense
- Cisco ASA
Jede Firewall soll:
1. Unsichere Cipher deaktivieren
2. Management-Zugriff auf bestimmte IPs limitieren
3. Logging aktivieren
Schritt 2: Sub-Agents für Vendors¶
Nach Plan-Approval:
Claude spawnt:
- Sub-Agent 1: FortiGate Hardening →
roles/fortigate_hardening/ - Sub-Agent 2: OPNsense Hardening →
roles/opnsense_hardening/ - Sub-Agent 3: Cisco ASA Hardening →
roles/asa_hardening/
Schritt 3: Konsolidierung¶
Haupt-Agent:
- Erstellt übergreifendes
site.yml - Generiert gemeinsames Inventory-Template
- Schreibt README mit Nutzungsanleitung
Beispiel-Output¶
Inventory Template¶
# inventory/production/hosts.yml
all:
children:
firewalls:
children:
fortigates:
hosts:
fw-hq-01:
ansible_host: 10.0.0.1
fw-branch-01:
ansible_host: 10.1.0.1
vars:
ansible_network_os: fortinet.fortios.fortios
ansible_connection: httpapi
ansible_httpapi_use_ssl: true
ansible_httpapi_validate_certs: false
opnsense:
hosts:
fw-lab-01:
ansible_host: 10.99.0.1
vars:
ansible_connection: local
Vault-Struktur¶
# inventory/production/group_vars/fortigates/vault.yml
# ansible-vault encrypt inventory/production/group_vars/fortigates/vault.yml
vault_fortigate_api_token: "your-api-token-here"
Site Playbook¶
# site.yml
---
- name: Firewall Hardening
hosts: firewalls
gather_facts: false
tasks:
- name: Include vendor-specific hardening
ansible.builtin.include_role:
name: "{{ ansible_network_os | regex_replace('\\..*', '') }}_hardening"
tags:
- hardening
- security
Tipps für gute Ergebnisse¶
DO ✅¶
Erstelle ein Playbook für FortiGate das:
- VPN Phase1/Phase2 konfiguriert
- Partner: Kunde-XY, Remote-IP: 203.0.113.50
- Lokales Subnetz: 10.0.0.0/24
- Remote Subnetz: 192.168.100.0/24
- PSK aus Vault lesen
Konkret, mit allen nötigen Parametern.
DON'T ❌¶
Zu vage - Claude muss raten.
TIPP: Iterativ arbeiten 💡¶
Statt alles auf einmal zu verlangen, in Schritten:
# Erst Grundstruktur
Erstelle die Rolle für FortiGate VPN, nur die Task-Struktur
# Review, dann Details
Jetzt fülle die Tasks aus mit den richtigen Modulen
# Dann Erweiterung
Füge Handlers hinzu für Config-Backup
Kosten-Optimierung¶
| Szenario | Empfehlung |
|---|---|
| Einzelnes Playbook | Sonnet direkt |
| Multi-Vendor Set | Plan Mode + Haiku Sub-Agents |
| Review bestehendes Playbook | Fork Context, Sonnet |
| Boilerplate-Generierung | Haiku reicht |
Kosten-Beispiel¶
Multi-Vendor Hardening (3 Vendors):
Mit Opus überall:
Planning: 10K tokens → $1.50
3 Vendors × 15K tokens → $6.75
Total: $8.25
Mit Sonnet + Haiku:
Planning (Sonnet): 10K → $0.18
3 Vendors × 15K (Haiku) → $0.06
Total: $0.24
Ersparnis: 97% - bei gleichem Output.
Troubleshooting¶
Falsches Modul verwendet¶
Das Modul fortios_system_admin existiert nicht mehr.
Nutze das aktuelle Modul aus fortinet.fortios Collection.
Fehlende Idempotenz¶
Der Task ist nicht idempotent - bei erneutem Lauf
würde er Fehler werfen. Füge entsprechende Checks hinzu.
Vendor-Doku einbinden¶
Wenn Claude veraltete Info hat:
Hier die aktuelle Doku für das OPNsense Ansible Modul:
[Doku-Link oder Content einfügen]
Passe das Playbook entsprechend an.
Best Practices¶
Vault-Patterns¶
Credentials nie in Klartext, immer über Vault-Variablen referenzieren:
# defaults/main.yml – nur Platzhalter, kein Klartext
fortigate_api_token: "{{ vault_fortigate_api_token }}"
opnsense_api_key: "{{ vault_opnsense_api_key }}"
opnsense_api_secret: "{{ vault_opnsense_api_secret }}"
# group_vars/fortigates/vault.yml – verschlüsselt mit ansible-vault
vault_fortigate_api_token: "your-actual-token"
Claude-Prompt für korrekte Vault-Struktur:
Erstelle das Playbook mit korrekter Vault-Struktur:
- Alle Credentials als vault_* Variablen
- defaults/main.yml mit Referenz-Variablen
- Beispiel-Vault-Datei mit Platzhaltern
- .vault_pass Datei in .gitignore
Idempotenz garantieren¶
Problematische Patterns vermeiden:
# SCHLECHT: Nicht idempotent
- name: Add admin user
command: fortios_system_admin add {{ admin_name }}
# GUT: Idempotent durch Modul
- name: Configure admin user
fortinet.fortios.fortios_system_admin:
state: present
system_admin:
name: "{{ admin_name }}"
accprofile: "super_admin"
Test auf Idempotenz:
# Zweimal laufen lassen – zweiter Lauf muss 0 Changes haben
ansible-playbook site.yml --check --diff
ansible-playbook site.yml
ansible-playbook site.yml # Keine "changed" Tasks
Check Mode immer unterstützen¶
# Tasks die check mode unterstützen brauchen keine Anpassung
# Für Tasks die es nicht tun: check_mode: false mit Kommentar
- name: Backup before change (kann nicht check-mode)
fortinet.fortios.fortios_system_backup:
...
check_mode: false
# Backup ist idempotent-sicher, wird immer ausgeführt
Tagging-Strategie¶
Konsistente Tags über alle Playbooks:
tasks:
- name: Configure VPN
block:
- name: Phase 1
...
- name: Phase 2
...
tags:
- vpn
- phase1 # Oder phase2 pro Task
- network
# Nutzung:
# ansible-playbook site.yml --tags vpn
# ansible-playbook site.yml --skip-tags vpn
Empfohlene Tags im MSP-Kontext:
| Tag | Bedeutung |
|---|---|
config |
Konfigurationsänderungen |
security |
Security-bezogene Tasks |
vpn |
VPN-Konfiguration |
backup |
Backup-Tasks |
verify |
Verifikations-Tasks |
never |
Nur auf explizite Anfrage |