FinOps in der CI: Cost Guardrails zum Zeitpunkt des Provisionings

Kubernetes Security Tooling: Data-Driven Guide to the Open-Source Ecosystem in 2026

Data-driven survey of open-source Kubernetes security tools from a 2,080-repo corpus — scanning, secrets, policy, runtime, and supply chain integrity.

Dashboards sind Quittungen, Gates sind Leitplanken

Im Kern des Cloud-Kostenmanagements gibt es eine Asymmetrie: Die Entscheidungen, die Kosten verursachen, fallen in Pull Requests, während die Entdeckung dieser Kosten erst 30 Tage später in der Rechnung erfolgt. Bis ein Dashboard die Budgetüberschreitung anzeigt, wurde die Infrastruktur bereits bereitgestellt, die Ressourcen bezahlt und die Behebung wird zu einem Cleanup-Projekt in einem Ticket-Backlog.

Provision-time FinOps eliminiert diese Asymmetrie. Der Entwickler sieht die Kosten während der Aktivität, die sie verursacht, im vollen Kontext und in dem Tool, in dem er bereits Entscheidungen trifft. Die verfügbaren Optionen sind nun: die Kosten akzeptieren und mergen oder die Änderung anpassen und neu bewerten – beides innerhalb derselben Arbeitssitzung.

Das ist der Unterschied zwischen einer Quittung und einer Leitplanke. Ein Dashboard ist eine Quittung. Ein blockierender CI-Check ist eine Leitplanke.

Die zwei Ebenen: Statisch und Runtime

Eine vollständige Shift-Left FinOps Toolchain betrachtet die Infrastruktur aus zwei Perspektiven:

Die Cost-Gate-Pipeline

Das Gate läuft bei jedem Pull Request, der Infrastruktur-Code berührt. Die statische Analyse erkennt Fehler in der Bereitstellung auf Makroebene – etwa ein m5.large, das auf ein r5.4xlarge aktualisiert wurde –, während die Runtime-Ebene das erfasst, was die statische Analyse nicht sehen kann.

Das Gate bauen: Infracost

Infracost ist das Arbeitstier der statischen Ebene. Es parst Terraform-, OpenTofu-, CloudFormation- und AWS CDK-Manifeste, fragt Cloud-Pricing-APIs in Echtzeit ab und berechnet exakt, wie sich die Rechnung ändert, wenn ein PR gemergt wird. Es unterstützt über 1.100 Ressourcentypen über AWS, Azure und Google Cloud hinweg.

Für sicherheitsbewusste Teams sind zwei Eigenschaften entscheidend:

• Keine Cloud-Credentials verlassen Ihre Pipeline. Infracost sendet nur Ressourcentypen und Pricing-Lookup-Abfragen an seine Pricing-API – keine Credentials, Secrets oder State-Daten.
• Verbrauchsbasierte Kosten werden explizit modelliert über eine usage.yml Datei (Lambda-Aufrufe, S3-Requests, Datentransfer), da die statische Analyse die Runtime-Nutzung nicht erraten kann.

Das Policy-Gate: OPA und Rego

Infracost erstellt eine JSON-Aufschlüsselung mit Kosten pro Ressource und einem aggregierten diff.totalMonthlyCost. Der Open Policy Agent (OPA) evaluiert dieses JSON gegen Rego-Policies; conftest ist der gängige Runner in der CI.

Policy 1: Aggregiertes monatliches Limit

deny[msg] {
  delta := to_number(input.projects[_].diff.totalMonthlyCost)
  delta > threshold_monthly
  msg := sprintf(
    "Monthly cost delta is $%.2f, which exceeds the $%d limit. Break this into smaller changes or request an exception.",
    [delta, threshold_monthly],
  )
}

Policy 2: Limit pro Ressource mit Ausnahme-Pfad

Aggregierte Limits übersehen Ausreißer – eine einzelne Ressource für 2.000 $/Monat innerhalb eines Diffs von 400$ bleibt in der Gesamtsumme unsichtbar. Eine Regel pro Ressource erkennt dies, inklusive eines dokumentierten Ausnahme-Pfads:

deny[msg] {
  resource := input.projects[i].diff.resources[j]
  cost := to_number(resource.monthlyCost)
  cost > 200
  not has_justification(resource)
  msg := sprintf(
    "Resource %s costs $%.2f/mo. Add a '# cost-justified: <reason>' comment or split the PR.",
    [resource.name, cost],
  )
}

has_justification(resource) {
  startswith(resource.metadata.code_comment, "cost-justified:")
}

Das has_justification Prädikat ist die zentrale Designentscheidung: Ausnahmen sind keine Umgehungen, sondern werden Teil des Audit-Trails des Codes. Jede Ausnahme ist im PR-Kommentarverlauf sichtbar und überprüfbar.

Der vollständige Workflow

name: FinOps Cost Gate

on:
  pull_request:
    paths:
      - "terraform/**"

jobs:
  cost-gate:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - uses: actions/checkout@v4

      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.9.x

      - name: Configure AWS credentials (read-only)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.PLAN_ROLE_ARN }}
          aws-region: us-east-1

      - name: Terraform plan
        working-directory: terraform
        run: |
          terraform init -input=false
          terraform plan -out=tfplan.binary -input=false
          terraform show -json tfplan.binary > tfplan.json

      - name: Setup Infracost
uses: infracost/actions/setup@v3
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}

      - name: Infracost breakdown
        working-directory: terraform
        run: |
          infracost breakdown \
            --path tfplan.json \
            --format json \
            --out-file ../infracost.json

      - name: Enforce cost policy
        run: conftest test --policy policy/ infracost.json

      - name: Comment cost diff on PR
        if: always()
        uses: infracost/actions/comment@v3
        with:
          path: infracost.json
          behavior: update

Die IAM-Rolle für das Planning ist schreibgeschützt und auf das Zielkonto beschränkt – das Gate kann prüfen, aber niemals verändern. Der PR-Check wird über den Branch-Schutz als erforderlich erzwungen, sodass eine Kostenüberschreitung den Merge blockiert, genau wie ein fehlgeschlagener Test.

Die Runtime-Ebene: OpenCost und Kubecost

Statische Prüfungen können nicht vorhersagen, was innerhalb einer elastischen Orchestrierungsebene passiert, in der sich die Kosten mit dem Traffic ändern. Dafür betreiben Sie OpenCost in Ihren Clustern.

OpenCost ist der offene Standard: eine cloud-agnostische, community-getriebene API, die Kostenmetriken über verschiedene Plattformen hinweg standardisiert. Kubecost implementiert die OpenCost-Spezifikation und bietet eine Echtzeit-Kostenallokation auf Namespace-, Deployment- und Pod-Ebene sowie Budget-Warnungen, wenn Ausgaben bestimmte Schwellenwerte überschreiten.

Die beiden Ebenen arbeiten zusammen. Wenn Ihr Infracost-Gate zeigt, dass ein Microservice basierend auf den deklarierten CPU-Requests 200 $/Monat kostet, die OpenCost-Telemetrie jedoch zeigt, dass die reale Speicherauslastung niemals 5 % überschreitet, haben Sie ein Ziel für ein Downsizing gefunden – inklusive der Zahlen, um es zu rechtfertigen.

Der Drei-Phasen-Adoptionspfad

Aktivieren Sie das „Hard-Deny“ nicht am ersten Tag. Die Pipeline muss erst Vertrauen aufbauen:

1. Advisory. Kostenschätzungen erscheinen in jedem PR, nichts wird blockiert. Die Teams lernen das Tooling und die Sprache der Kosten kennen.
2. Warning. OPA-Policies werden ausgewertet, aber Verstöße führen nur zu Kommentaren. Schwellenwerte werden anhand realer Deltas kalibriert.
3. Hard-deny. Merges werden bei Policy-Verstößen blockiert; Ausnahmen erfordern eine explizite FinOps-Genehmigung über den cost-justified-Pfad.

Tuning der Schwellenwerte

Schwellenwerte sind eine Frage der Kalibrierung, nicht des Ratens. Analysieren Sie zuerst zwei bis vier Wochen Infracost-Daten:

• Der mediane PR erhöht die monatlichen Kosten um 50–500 $.
• Setzen Sie den aggregierten Schwellenwert auf etwa das 90. Perzentil der beobachteten Deltas – für die meisten Platform-Teams liegt dieser zwischen 300 und 1.000 $/Monat.
• Setzen Sie den Warnschwellenwert noch höher (2.000–5.000 $) und den **Hard-Deny-Schwellenwert** auf einem Niveau, das eindeutig auf einen Provisionierungsfehler hinweist (5.000–15.000$).

Ergebnisse, die es wert sind, gemessen zu werden

Eine Referenzimplementierung in der Produktion berichtet:

Die zusätzlichen 47 Sekunden pro PR sind vernachlässigbar im Vergleich zur typischen Review-Latenz – das Gate kostet weniger als ein Kommentar-Thread und verhindert mehr als eine Budget-Überprüfung.

Jenseits von Terraform: Wo dasselbe Muster gilt

Das Gate-Muster ist nicht auf Terraform beschränkt. Dieselbe Struktur funktioniert überall dort, wo Infrastruktur deklarativ definiert wird:

• OpenTofu und CloudFormation — Infracost parst beides nativ, sodass die identische Pipeline auch ohne Terraform funktioniert.
• Kubernetes-Manifeste — OPA Gatekeeper fängt zum Zeitpunkt der Admission direkte kubectl apply-Änderungen ab, die das PR-Gate komplett umgehen.
• GitLab CI / Jenkins — der conftest-Schritt ist tool-agnostisch; nur der Workflow-Wrapper ändert sich.
• AI-Coding-Agents — Infracost liefert Agent-Skills (iac-generation, scan, price-lookup), sodass Agents, die Infrastruktur-Code generieren, Kosten-Policies bereits während der Arbeit prüfen, noch bevor der PR überhaupt existiert.

Das einigende Prinzip: Die Kosten-Policy existiert als Code direkt neben der Infrastruktur, die sie steuert, und wird in derselben Pipeline evaluiert, die die Änderung prüft.

Vorbehalte

• Statische Analyse kann keine elastischen Kosten vorhersagen. Kombinieren Sie das PR-Gate mit OpenCost; verlassen Sie sich niemals auf nur eine Ebene.
• Verbrauchsbasierte Ressourcen benötigen usage.yml-Modellierung, sonst werden die Schätzungen systematisch falsch sein.
• Schwellenwerte müssen kalibriert werden. Leiten Sie diese aus Daten ab, prüfen Sie sie quartalsweise und rechnen Sie mit Anpassungen nach Feedback zu False-Positives.
• Die Muster sind komplementär, nicht substitutiv: Das PR-Gate verhindert, dass Waste gemergt wird, Admission-Policies fangen direkte Cluster-Änderungen ab, Dashboards dienen dem Executive Reporting und Provider-Budget-Warnungen sind das letzte Sicherheitsnetz.
• Starten Sie mit Advisory. Ein Hard-Gate, das ohne Vertrauensaufbau installiert wird, erzeugt Schatten-Workflows statt Kostendisziplin.

Weiterführende Literatur

• Terraform for AWS Infrastructure: A Beginner's Guide — der IaC-Workflow, den das Gate analysiert
• Open Source Infrastructure Stack in Production 2026 — wo Cost Governance in den Stack passt
• Kubernetes GitOps with ArgoCD — die Deployment-Pipeline, die das Cost-Gate bewacht
• Grafana for Infrastructure Observability — Dashboards für die Runtime-Kostendaten
• Scaling Self-Hosted Cloud Applications — die Scaling-Muster, deren Kosten durch das Gate sichtbar gemacht werden