GitOps und Secrets

GitOps ist der unterstützte Deployment-Weg. Ein Commit im konfigurierten Repository ändert den gewünschten App-Zustand; gh0stcloud reconciled ihn über Flux.

Secrets gehören nicht in Git. Nutze OpenBao und External Secrets.

Repository verbinden

Applications öffnen.
GitOps-Binding öffnen.
Transport und Repository-URL wählen.
Branch und Pfad eintragen.
Vorschau prüfen und speichern.
Flux Source und Kustomization Reconcile abwarten.

Als Startpunkt: gh0stservice/ghc-gitops-example und docs/02-gitops-binding.md.

Repository-Struktur

Einfach starten:

kustomize/
  base/
    <app>/
  overlays/
    ghc-basic/
      kustomization.yaml

Erweiterte Overlays erst hinzufügen, wenn der Basis-Pfad reconciled.

Secrets-Workflow

Schritt	Owner
Secret-Werte im OpenBao-Pfad aus gh0stportal ablegen.	Tenant
`ExternalSecret` in GitOps anlegen.	Tenant GitOps
External Secrets Operator erzeugt Kubernetes Secret.	Plattform
Workload referenziert das erzeugte Secret.	Tenant GitOps

Nie Secret-Werte ins Repository schreiben.

ServiceAccounts

Account	Zweck
Flux ServiceAccount	Flux `Kustomization` und HelmRelease.
Workload ServiceAccount	Anwendungspods und Runtime-Identität.

Den Flux ServiceAccount nicht für Pods nutzen, außer gh0stportal sagt es explizit.

RPC/Funktionskarte

Portal-Aktion	gh0stplane-Fläche
GitOps-Zustand laden	`GetTenantApplicationsWorkspace`
GitOps-Binding speichern	`UpdateTenantGitOpsBinding`
OpenBao-Pfade und Secret-Metadaten lesen	`GetTenantSecretWorkflow`
Onboarding-Zustand lesen	`GetTrialOnboardingWorkspace`

Vor AI-generierten GitOps-Änderungen

Gib dem Agenten:

Ziel-Namespace aus Applications;
App-Name;
Hostname aus Network & Exposure;
Storage-Intent/PVC-Name aus Data & Services;
Secret-Pfadnamen, nicht Secret-Werte;
Beispiel-Repo-Link.