Skip to content

GovTech · 2025–2026

Orcrist: GitOps-Plattform auf GKE für sicherheitskritische Workloads

Eine Plattform übernommen, bei der Security, Reliability, Scalability und Observability nicht mehr trugen. Neu gebaut auf GitOps, Policy-as-Code und Zero Trust.

GovTech: Orcrist: GitOps-Plattform auf GKE für sicherheitskritische Workloads

Eine Plattform, bei der Security, Reliability, Scalability und Observability nicht mehr trugen.

Zero-Trust-GitOps-Plattform mit Policy-as-Code und Golden Paths für Application-Teams.

Plattformteam
5 Senior FTEs
Cross-funktionales Programm
30 FTEs
Workloads für Strafverfolgung
Mission-critical

Engagement

Kunde
Orcrist
Rolle
Technical Product Lead, Platform Engineering
Zeitraum
2025–2026
Branche
GovTech
GovTechPlattform-EngineeringCloud-PlattformDeveloper ExperienceMulti-Tenant-PlattformObservability+16 weitere

Auf dem Papier war die Plattform da. In der Realität klemmte es an vier Stellen gleichzeitig. Secrets lagen, wo sie nicht hingehörten. Cluster hatten keine einheitlichen Guardrails. Kapazität war Bauchgefühl. Und jeder Incident begann damit, dass erstmal jemand recherchiert hat, was eigentlich gerade läuft.

Für Workloads im Bereich Strafverfolgung ging das so nicht weiter. Mein Auftrag: Fundament reparieren, ohne die Application-Teams zu blockieren, die längst darauf liefern.

Anfangs: Credentials im Klartext, IAM-Rollen voller Drift, Terraform-PRs, die kaum jemand wirklich gelesen hat. Die Fixes waren unspektakulär.

  • External Secrets Operator vor dem GCP Secret Manager. Keine Anwendung sieht je ein langlebiges Credential.
  • Workload Identity und KMS durchgängig. Statische Service-Account-Keys sind raus.
  • Kyverno am Admission Controller: Image-Provenance, Pflicht-Labels, kein Privileged Container, Punkt.
  • Checkov in Cloud Build und GitHub Actions. IaC-Merges werden geblockt, bevor sie reinkommen. Terraform, OpenTofu und Pulumi laufen durch dieselben Gates.
  • NetworkPolicies auf Default-Deny, mit expliziten Egress-Regeln pro Workload.

Die Secrets-Exposure ist schnell runtergegangen. Wichtiger war: kein Control hängt mehr daran, dass jemand dran denkt, ihn zu setzen.

Clusterzustand und Git-Historie waren auseinandergelaufen. Hotfixes lebten in irgendeiner Shell. Rollbacks waren Glückssache.

FluxCD ist jetzt der einzige Pfad. Jede Änderung an einem Cluster – Code, Config, Policy, Secret-Referenz – läuft über einen PR, geht als OCI Artifact raus und landet über Kustomizations oder Helm Releases. Lokal, Staging und Prod nutzen dieselben Manifeste, über Git promotet. Drei langsam driftende Varianten gibt es nicht mehr.

Für die Application-Teams heißt das: vorhersagbare Deployments, echte Rollbacks und ein Audit-Trail, der vor Engineering und Compliance gleichermaßen besteht.

Vorher wurde jedes Application-Team einzeln onboardet. Heute habe ich die Plattform als Set von Capabilities neu gefasst, mit Owner, SLOs und Adoption-Metriken. Teams bekommen einen Golden Path: Template-Repo, Kustomization, Helm Chart, CI-Pipeline, Observability vorverdrahtet.

OCI-first heißt: derselbe Build wandert durch alle Umgebungen, ohne neu gebaut zu werden. Die Standards für Kustomizations und Helm Releases haben aus Onboarding eine Checkliste gemacht. Verhandeln muss man nicht mehr.

Die Data Plane skaliert mit den Workloads. Kafka für Streams, Spark für Batch, Temporal für alles, was einen Restart überstehen muss. Das Plattformteam ist nicht mehr der Engpass für jeden neuen Tenant.

Die Telemetrie war da. Nur hat jedes Team sie anders genutzt. Grafana, Prometheus und Loki liefen, aber Dashboards und Labels hatte jeder selbst gebaut.

Wir haben die Konventionen festgezogen: Metriknamen, Log-Felder, Trace-Kontext, Alert-Routing. SLOs pro Capability, mit Error Budgets, die Release-Entscheidungen tatsächlich beeinflussen. Runbooks und ADRs liegen neben dem Code, damit die Antwort auf „warum so" im Repo steht und nicht im Kopf von irgendwem.

Incident-Calls fangen heute direkt beim SLO an, statt bei der Suche über sechs verschiedene Dashboards.

Fünf Senior Engineers aus Platform, Infrastructure und Cloud, organisiert in Jira-Sprints. Ich priorisiere die Roadmap wie eine Produkt-Roadmap: Capabilities, Golden Paths, Deprecation-Timelines, Migrationspfade. Infrastructure-, Foundation- und Application-Teams bekommen dieselben Updates zum selben Zeitpunkt. Niemand wird von einer Änderung überrascht.

Runbooks, ADRs und Docs entstehen direkt während der Entwicklung.

  • Secrets-Exposure deutlich reduziert durch External Secrets Operator, Workload Identity und KMS.
  • Policy- und IaC-Checks automatisch in CI erzwungen.
  • GitOps ist der einzige Weg in den Cluster. Jede Änderung reviewbar, jede Änderung reversibel.
  • Onboarding von Einzelfallarbeit auf einen dokumentierten Golden Path verkürzt.
  • Kein Drift mehr zwischen Local, Staging und Prod, weil OCI Artifacts unverändert wandern.
  • Incidents starten beim SLO und eliminieren die Suche durch sechs Dashboards.
Zusammenarbeit

5 Senior FTEs plattformteam. 30 FTEs cross-funktionales Programm. Mission-critical workloads für Strafverfolgung.

Eine Herausforderung? Hab ich wahrscheinlich schon gesehen.

Kontakt aufnehmen Lebenslauf herunterladen