ansible-webui/TODO.md

TODO-Liste

Offen

• Ziel: Bereitstellung einer schlanken Web-UI, die Ansible-Playbooks per CLI startet.
• Authentifizierung erfolgt ausschließlich via extern gepflegter .htpasswd.
• SSH-Keys werden nur abgelegt und referenziert; Berechtigungen bleiben bei Ops.
• Keine Reverse-Proxy/TLS-Komponente im MVP; Service lauscht direkt auf Port 8000.
• Hochgeladene Artefakte: ZIP/TAR.
• Geplante Erweiterung: Automatisches Host-Onboarding (Strict Ops-First Policy) nach MVP-Release, abgestimmt mit webapp/entwicklung/architektur.md und webapp/entwicklung/api_endpoints.md.
• Container-Basisimage finalisieren, Port 8000 exponieren.
• Ordnerstruktur für Uploads, temporäre Runs und SSH-Key-Ablage anlegen.
• Integration der Webserver-Basic-Auth (Übernahme REMOTE_USER, Fehlermeldungen).
• Dokumentation für Ops zur Pflege der .htpasswd erstellen.
• Datei-Uploads (ZIP/TAR) inkl. Validierung implementieren.
• Playbook-Metadaten persistieren laut schema.sql.
• CLI-Executor: Wrapper für ansible-playbook inkl. Parameteraufbereitung.
• Run-Verwaltung (Status, Logpfade) bauen.
• Read-only-API zur SSH-Key-Liste implementieren.
• API-Endpunkte gemäß api_endpoints.md fertigstellen.
• Funktionale Tests für Upload, Run-Start, Statuspolling.
• CLI-Aufruf unter verschiedenen Inventaren/Variablen validieren.
• Security-Checks: Keine Speicherung sensitiver Daten, Log-Redaktion.
• Belastungstest der Upload/Polling-Flows (einfacher Load-Test).
• Container-Image Review (kein TLS, nur HTTP).
• Build-/Release-Pipeline konfigurieren (Container Registry).
• Deployment-Checkliste erstellen (Port 8000, externe TLS-Schicht durch Ops).
• Monitoring-Anbindung (Basis: Health Endpoint, Log-Verfügbarkeit).
• Go-Live-Freigabe und Übergabe an Ops inkl. Betriebsdokumentation.
• Architektur- und Security-Review abschließen; Spezifikation finalisieren (Strict Ops-First Policy, siehe webapp/entwicklung/architektur.md).
• Datenbankmigrationen und Service-Layer implementieren (Hosts, Onboard-Jobs, Key-Metadaten) gemäß webapp/entwicklung/schema.sql.
• Backend: Onboarding-Service & Job-Runner (Key-Erzeugung, Fingerprint-Prüfung, sudo-Tasks) plus API-Endpunkte & Rate-Limits laut webapp/entwicklung/api_endpoints.md.
• UI/UX: Onboarding-Formular, Status-Detailansicht, Ops-Approval-Dashboard inkl. Log-Viewer.
• QA & Security: Integrationstests, Sudo-/SSH-Härtung, Pen-Test light, Memory-Handling-Checks (keine Persistenz von Passwort/Secret).
• Ops Enablement: Prozesse für known_hosts-Sync, Runbooks, Alerting, Eskalationspfade; Schulung der Ops-Gruppe.
• Staging-Dryrun mit realistischem Host; Post-Mortem + Go/No-Go Entscheidung.
• Abhängigkeiten: Abschluss Phase 1–3, verfügbare Ops-Ressourcen für Fingerprint-Freigaben und Sicherheitstests.
• Integrierter Reverse-Proxy/TLS-Termination.
• Erweiterter Credential-Store oder Secrets-Management.
• Rollenbasierte Zugriffssteuerung jenseits .htpasswd.
• UI-Verbesserungen für Run-Output (Streaming, Filter).
• Automatisierte Key-Rotation inklusive Berechtigungsupdates.
• Self-Service Ops Workflow für Re-Onboarding/Key-Rotation (Erweiterung der Onboarding-Plattform).
• Keine; Onboarding-Policy (Strict Ops-First) und Sicherheitsvorgaben abgestimmt.
• HTTP-Basic wird extern via .htpasswd gepflegt; Webserver setzt Auth und ggf. REMOTE_USER.
• Die Applikation verifiziert keine internen Benutzer, erwartet ggf. REMOTE_USER zur Audit-Zuordnung.
• Beschreibung: Simple Health-Check.
• Antwort: 200 OK.
• Beschreibung: Liste aller hochgeladenen Playbooks (Metadaten).
• Query: ?limit=&offset=.
• Antwort: JSON Array [{id,name,filename,uploaded_by,uploaded_at}].
• Beschreibung: Upload eines ZIP/TAR mit Playbook(s).
• Konsumiert: multipart/form-data file=....
• Validierung: MIME und Dateiendung (zip,tar,tgz), Größenlimit.
• Antwort: 201 Created + Metadaten.
• Beschreibung: Metadaten zu einem Playbook.
• Antwort: JSON.
• Beschreibung: Startet einen Run via systemweiter ansible-playbook CLI. Keine Nutzung von ansible-runner.
• Body: optional JSON {inventory: string, extra_vars: object, tags: [string], become: bool}.
• Behaviour: Prozess wird vom Service gestartet; stdout/stderr werden in temporäre Dateien geschrieben.
• Antwort: 202 Accepted {run_id}.
• Beschreibung: Statusabfrage (queued,running,success,failed).
• Antwort: JSON {run_id,status,exit_code,started_at,finished_at}.
• Beschreibung: Holt vollständiges stdout/stderr des Runs (Text/stream).
• Antwort: text/plain (oder chunked).
• Beschreibung: Listet referenzierbare SSH-Keys (nur lesend).
• Antwort: JSON [{key_id,filename,description}].
• Beschreibung: Zugriff auf Run-Logs / Audit-Einträge (keine sensiblen Daten).
• Antwort: JSON.
• Die Applikation führt keine Änderung an SSH-Keys oder .htpasswd durch.
• Alle schreibenden Betriebsaufgaben (Permissions, Key-Rollout, TLS) sind außerhalb des MVP-Scopes.
• Auth via vorhandene HTTP-Basic/.htpasswd-Integration; Webserver stellt REMOTE_USER zur Verfügung.
• Ops-spezifische Endpoints (z. B. Approve) erfordern REMOTE_USER ∈ Ops-Gruppe (Ops-Policy).
• Transport: Produktion erfordert TLS (Ops-Deployment-Voraussetzung).
• POST /onboard/requests.
• GET /onboard/requests.
• GET /onboard/requests/{id}/status.
• POST /onboard/requests/{id}/approve.
• POST /onboard/requests/{id}/cancel.
• GET /onboard/jobs.
• GET /onboard/keys.
• GET /onboard/requests/{id}/logs.
• Zweck: Erstellt eine Onboarding-Anfrage / startet ein Onboarding-Job (sofern Pre-Checks erfolgreich sind).
• Auth: REMOTE_USER (any authenticated user).
• Konsumiert: application/json.
• Payload: { "host": "192.0.2.10", "port": 22, "login_user": "ubuntu", "login_password": "secret", "desired_user": "ansible", "generate_key": true, "public_key": null, "description": "Kurzinfo", "options": { "force_approve": false } }.
• Verhalten:
• Validierung von Pflichtfeldern.
• Erzeugt Onboard-Request und Onboard-Job, reply enthält { "job_id": "...", "status": "created" }.
• Wenn Fingerprint nicht mit Ops known_hosts übereinstimmt, wird status = "awaiting_approval".
• Antwort: 201 Created { "job_id": "uuid", "status": "created" | "awaiting_approval" | "queued" }.
• Fehlercodes:
• 400 Bad Request (Validierungsfehler).
• 401 Unauthorized.
• 429 Too Many Requests (Rate-Limit pro User/Host).
• Zweck: Listet Onboarding-Requests (nur Metadaten).
• Query: ?limit=&offset=&status=.
• Antwort: JSON Array [{job_id, host, requested_by, status, created_at, fingerprint_sha256?}].
• Zweck: Statusabfrage für einen Request.
• Antwort: { "job_id": "...", "host": "...", "status": "created|queued|running|awaiting_approval|approved|onboarded|failed|cancelled", "retries": 0, "started_at": "...", "finished_at": "...", "error_message": "kurze Fehlerdiagnose (sensitivitäts-gefiltert)" }.
• Zweck: Ops-Endpoint zur Freigabe eines abweichenden Host-Fingerprints.
• Auth: REMOTE_USER muss Ops sein (Server-Side check).
• Payload: { "approve": true, "operator_note": "Fingerprint validiert via call", "operator_id": "ops-username" }.
• Verhalten: Wenn genehmigt, Job wird zur Fortsetzung freigegeben; Audit-Eintrag mit operator_id erzeugt.
• Antwort: 200 OK { "job_id": "...", "status": "approved" }.
• Fehler: 403 Forbidden (wenn nicht Ops), 404 Not Found.
• Zweck: Bricht laufenden/queued Onboarding-Job ab (z. B. User Abbruch).
• Auth: Requester oder Ops.
• Antwort: 200 OK { "job_id": "...", "status": "cancelled" }.
• Zweck: Admin/Operator Sicht auf Onboard-Jobs (Metadaten).
• Filters: status, requested_by, host.
• Antwort: Array von job-Metadaten (keine sensitiven Inhalte).
• Zweck: Listet erzeugte Public-Keys (Metadaten only).
• Antwort: [{ "key_id": "...", "host_id": "...", "public_key_fingerprint": "...", "created_at": "..." }].
• Zweck: Liefert redigierte Logs des Onboarding-Jobs (Ausgaben, Schritte).
• Sicherheits-Hinweis: Logs sind gesäubert; keine Passwörter oder private Key-Material enthalten.
• Antwort: text/plain oder JSON { "lines":[ ... ] }.
• Login-Password darf niemals geloggt werden; im API-Server mittelbar nur in-memory übergeben.
• API darf niemals privaten Schlüssel in Responses zurückliefern.
• Alle Endpoints, die sensible Ablaufsteuerung erlauben (approve, cancel), müssen REMOTE_USER-Checks durchführen.
• Rate-Limits: Schutz gegen bruteforce / DOS.
• Input-Sanitization: host/username dürfen keine Shell-Injection ermöglichen; SSH-Interaktionen erfolgen kontrolliert.
• Audit: Jeder state-wechsel (created, awaiting_approval, approved, onboarded, failed, cancelled) schreibt ein Metadaten-Audit (siehe webapp/entwicklung/schema.sql Anpassungen).
• UI-Form "Host Onboarding" ↟ POST /onboard/requests.
• UI-Ops Dashboard ↟ GET /onboard/requests?status=awaiting_approval.
• UI-Ops Approve Button ↟ POST /onboard/requests/{id}/approve.
• UI-User Status Polling ↟ GET /onboard/requests/{id}/status.
• UI-Logs ↟ GET /onboard/requests/{id}/logs.
• Schritt 1: User sendet POST /onboard/requests mit login_password.
• Schritt 2: API antwortet job_id.
• Schritt 3: Onboarding Service führt Pre-Check aus; bei Fingerprint-Mismatch → awaiting_approval.
• Schritt 4: Ops Approver ruft POST /onboard/requests/{id}/approve → Service fährt fort.
• Schritt 5: Job schreibt audit_logs und setzt Host Status auf onboarded oder failed.
• Architektur: webapp/entwicklung/architektur.md.
• DB Schema: webapp/entwicklung/schema.sql.
• Roadmap: webapp/entwicklung/roadmap.md.

Erledigt

(noch keine Einträge)