Projekte (Service ▸ Projekte)

Überblick — was diese Seite leistet

Projekte ist ein Register, das die Metadaten aller Projekte Ihres Teams an einem gemeinsamen Ort zusammenführt. Zu jedem Projekt erfassen Sie sein Quellcode-Repository (GitHub usw.), seine CI/CD-Pipeline (Jenkins), die genutzten Webdienste und Datenbanken, seine Backup-Ziele und — entscheidend — wo seine Geheimnisse liegen. Damit kann jede Person im Team auf einen Blick beantworten: „Woraus besteht dieses Projekt, wohin wird es ausgerollt, und welches Geheimnis liegt wo?“

Dieser Bildschirm ist kein Deployment-Werkzeug. Die tatsächlichen Builds und Deployments laufen in Jenkins. InfraGuard stößt von hier aus keine Pipeline an; die erfassten Daten sind gemeinsame Dokumentation. Die URLs, Job-Namen und Branches, die Sie hinterlegen, sind ausschließlich Referenzlinks und Beschriftungen — nichts davon wird ausgeführt.

Zentrale Gestaltungsprinzipien:

• Geheimniswerte werden niemals im Klartext hinterlegt. Die tatsächlichen Werte von Passwörtern, Tokens und Schlüsseln liegen nicht hier. Stattdessen (1) verweisen Sie auf einen Schlüssel im Tresor des Inventars (infr_vault_key) oder (2) halten in einer maskierten Checkliste lediglich fest, „welches Geheimnis wo liegt“.
• Alles wird in einem einzigen Dialog mit Registerkarten bearbeitet (Übersicht · Quellcode · CI/CD · Verknüpfungen · Backup · Geheimnisse).
• Anlegen, Ändern, Löschen sowie das Anzeigen von Tresorwerten werden sämtlich in das Audit-Protokoll (infr_audit_log) geschrieben.

Wann Sie sie verwenden

• Beim Einarbeiten einer neuen Teamkraft, die rasch wissen muss: „Welches Repository, welche Deploy-URL und welche Datenbank gehören zu diesem Projekt?“
• Um die Web-/DB-Abhängigkeiten jedes Projekts auszubreiten, damit Sie im Störungsfall den Wirkungsradius sofort abschätzen können.
• Um eine Karte der Geheimnisse zu dokumentieren, von denen ein Projekt abhängt (welcher Schlüssel wo liegt, welcher Tresoreintrag zu diesem Projekt gehört).
• Um Backup-Ziele und -Takt als Projekt-Metadaten festzuhalten, verzahnt mit Ihrer Backup-Richtlinie.

Aufbau

KPI-Leiste

Projektkarten

Jede Karte zeigt:

• Symbol und Name — von außen erreichbare Projekte verwenden mdi-web, rein interne mdi-folder-lock-outline.
• URL-Link — bei accessible und vorhandener URL ein Link, der in einem neuen Tab öffnet; andernfalls ein internal-Abzeichen.
• Status-Abzeichen — active / paused / archived.
• Einzeilige Zusammenfassung.
• Zusammensetzungs-Chips — es erscheinen nur die erfassten Elemente: Quellcode · Jenkins · Umgebungen N · Web N · DB N · Backups N · Geheimnisse N.
• Gruppenbezeichnung (Kategorie) sowie Schaltflächen zum Bearbeiten/Löschen (sofern Sie Schreibrechte haben).

Bearbeitungsdialog (6 Registerkarten)

Ein breiter Dialog (.infr-modal__panel--wide), der die Eingaben auf Registerkarten verteilt.

Vorgehen

Ein Projekt erfassen

1. Klicken Sie oben rechts auf [Projekt hinzufügen] (Schreibrechte erforderlich).
2. Geben Sie auf der Registerkarte Übersicht den Namen ein (Pflichtfeld). Der Schlüssel (Slug) ist optional und muss ^[a-z0-9_-]+$ entsprechen (z. B. coin-market).
3. Ist der Dienst von außen erreichbar, aktivieren Sie den Schalter Von außen erreichbar und tragen die URL ein. Für rein interne Projekte lassen Sie ihn aus; das URL-Feld ist dann deaktiviert.
4. Füllen Sie die übrigen Registerkarten (Quellcode, CI/CD, Verknüpfungen, Backup, Geheimnisse) nach Bedarf aus — sie sind alle optional.
5. [Speichern] — der Server prüft die Eingaben, führt ein Upsert in infr_project aus und aktualisiert die Karte.

CI/CD-Umgebungen erfassen

Tragen Sie auf der Registerkarte CI/CD die Jenkins-URL ein und fügen Sie danach mit [Umgebung hinzufügen] die Deploy-Ziele Zeile für Zeile hinzu:

{
  "env": "prod",
  "url": "https://coin.example.com",
  "branch": "main",
  "jenkins_job": "coin_market-deploy-prod",
  "note": "blue/green"
}

• env akzeptiert nur die Positivliste dev / staging / prod (jeder andere Wert wird vom Server auf dev gesetzt).
• Jedes Textfeld wird längenbegrenzt (URL 255 · Branch 120 · Job 191 · Notiz 255).
• Bis zu 20 Umgebungen.

Web/DB verknüpfen

Markieren Sie auf der Registerkarte Verknüpfungen die Ressourcen, die dieses Projekt nutzt.

• Webdienste — wählen Sie aus der Liste der infr_web_service (Name · Domain), die unter Service ▸ Web erfasst sind. Gespeichert wird ein Array von web_service-IDs.
• DB (Collector) — das Schlüssel-Array der mit access=database erfassten Collectors (Verwaltung ▸ Collectors / Service ▸ Datenbank).

Jede Verknüpfung fasst bis zu 50 Einträge.

Backup-Ziele deklarieren

Dokumentieren Sie mit dem Wiederholer auf der Registerkarte Backup die Backup-Richtlinie dieses Projekts (Art · Ziel · Zeitplan · Notiz). Dies sind Referenz-Metadaten, die nicht ausgeführt werden — die tatsächlichen Backup-Jobs verwalten Sie im Zeitplan-Board.

Vertrauliche Angaben verwalten (die Kernfunktion)

Für Geheimnisse greifen zwei Mechanismen zusammen. Keiner von beiden legt den echten Geheimniswert in infr_project ab.

1) Verweise auf Tresorschlüssel (vault_key_ids)

• Markieren Sie auf der Registerkarte Geheimnisse Schlüssel aus dem Tresor des Inventars (Assets ▸ Inventar ▸ Schlüsseltresor, infr_vault_key), um sie zu verknüpfen.
• Die Liste wird maskiert ausgeliefert (nur ID · Kategorie · Titel · Benutzername — ohne Wert).
• Ein Druck auf [Anzeigen] bei einem verknüpften Schlüssel ruft POST /service/projects/vault-reveal auf; erst in diesem Moment wird der Wert entschlüsselt und zurückgegeben.

Das Anzeigen von Tresorwerten wird auditiert. Jede Anzeige schreibt vault_key.reveal (target=vault_key, via=project) in infr_audit_log. Der Wert erscheint nur kurz und wird per Klick in die Zwischenablage kopiert — zeigen Sie ihn nur an, wenn Sie ihn brauchen. Der gespeicherte Projektdatensatz enthält ausschließlich den Verweis auf die Schlüssel-ID.

2) Geheimnis-Checkliste (secrets, maskiert)

Halten Sie bei Geheimnissen, die nicht im Tresor liegen (oder extern verwahrt werden), nur den Ort fest. Der Wert wird nie gespeichert.

Die serverseitige Funktion cleanList() behält nur die zulässigen Schlüssel (label/location/ref/note) und kürzt jeden auf 255 Zeichen. Sind alle vier Felder leer, wird die Zeile verworfen.

Löschen

Löschen Sie unten links im Bearbeitungsdialog oder über [Löschen] auf der Karte. Nach der Bestätigung entfernt POST /service/projects/delete die Zeile in infr_project und protokolliert project.delete.

Datenquellen

Speicherschema (infr_project, Auszug)

key            varchar(60) unique nullable   # Slug
group_id       int -> infr_asset_group
name           varchar(160)                  # Pflichtfeld
status         enum(active,paused,archived)
accessible     boolean default 1
url            varchar(255)                  # exponiert, wenn accessible=1
summary        text
repo_provider  enum(github,gitlab,gitea,bitbucket,other)
repo_url / default_branch / visibility(public,private,internal)
jenkins_url    varchar(255)
environments   json  [{env,url,branch,jenkins_job,note}]
web_refs       json  -> infr_web_service id array
db_refs        json  -> infr_collector(database) key array
backup_targets json  [{kind,target,schedule,note}]
vault_key_ids  json  -> infr_vault_key id array (values stay in the vault)
secrets        json  [{label,location,ref,note}]  # Checkliste, keine Werte gespeichert
tags / meta    json

Dieser Bildschirm fragt nicht laufend ab. Die Liste wird nur beim Speichern, beim Löschen oder über die Aktualisieren-Schaltfläche (GET /service/projects/list) neu geladen. Um den Echtzeitstatus kümmern sich Service ▸ Katalog und Service ▸ Web.

Zugriff

• Die Schreibsperre prüft infr_user_level >= 2 in der Sitzung (canWrite()). Schlägt das fehl, folgt 403 samt project.err.forbidden.
• Beim Speichern wird vault_key_ids auf ausschließlich real existierende Tresorschlüssel-IDs gefiltert (Existenzprüfung per InfrVaultKey::whereIn(...)). Gefälschte IDs werden stillschweigend verworfen.
• Die Ebenen lauten demo=1 · staff=5 · admin=10; einzelne Bereiche werden zusätzlich über die Middleware infr.level:N abgesichert.

Fehlersuche und FAQ

Q. Ich drücke Speichern und erhalte eine 403. Schreiben erfordert Ebene 2 oder höher. Ein Konto mit reinem Leserecht (Ebene 1) kann nur lesen und Tresorwerte anzeigen. Bitten Sie eine Administratorin oder einen Administrator, Ihre Ebene anzuheben.

Q. [Anzeigen] liefert nichts zurück. Entweder enthält dieser Tresoreintrag kein Geheimnis (hasSecret=false), oder die Entschlüsselung ist fehlgeschlagen (etwa weil sich APP_KEY geändert hat). Setzen Sie den Wert unter Inventar ▸ Schlüsseltresor neu. revealSecret() gibt im Fehlerfall null zurück.

Q. In den Web-/DB-Verknüpfungslisten erscheint nichts. Webdienste müssen zuerst in Service ▸ Web vorhanden sein, und für die DB-Auswahl braucht es Collectors mit access=database. Erfassen Sie diese, öffnen Sie den Projektdialog erneut, und die Auswahl füllt sich.

Q. Beim Speichern des Schlüssels (Slug) erscheint ein Formatfehler. Der Schlüssel erlaubt nur Kleinbuchstaben, Ziffern, Bindestriche und Unterstriche (^[a-z0-9_-]+$, maximal 60). Entfernen Sie Leerzeichen, Großbuchstaben und sonstige Sonderzeichen. Der Schlüssel ist optional, Sie dürfen ihn also auch leer lassen.

Q. Kann ich hier ein Deployment auslösen? Nein. Deployments laufen in Jenkins. Dieser Bildschirm hält die Jenkins-URL und die Job-Namen nur als Dokumentation vor.

Q. Darf ich den Geheimniswert einfach in eine Geheimnis-Notiz schreiben? Auf keinen Fall. secrets ist eine Ortskarte, die keine Werte speichert. Legen Sie den echten Wert in den verschlüsselten Tresor unter Inventar ▸ Schlüsseltresor und verweisen Sie über vault_key_ids darauf.

Verwandte Themen

• Service ▸ Web — die über web_refs verknüpften Webdienste.
• Service ▸ Datenbank — die über db_refs verknüpften DB-Collectors.
• Service ▸ Katalog — Lebendigkeit der Daemons je Instanz (der Live-Status liegt dort).
• Zeitplan-Board — Definition und Ausführung der tatsächlichen Backup-Jobs.
• Assets ▸ Inventar — der Ursprungsbildschirm der Tresorschlüssel (infr_vault_key).
• Audit-Protokoll — prüfen Sie die Einträge project.create/update/delete und vault_key.reveal.