BEREITSTELLUNG · CI/CD UND IAC
CI/CD und Infrastructure-as-Code-Bereitstellung auf STACKIT
Liefern Sie die migrierte Infrastruktur aus einer Pipeline aus, nicht vom Laptop: bewerten Sie mit strengem Gate, behalten Sie das erzeugte Paket als Build-Artefakt, authentifizieren Sie den STACKIT-Provider mit einem kurzlebigen OIDC-Token statt eines gespeicherten Schlüssels, legen Sie den State in einem geschützten Backend ab und wenden Sie nur eine Plan-Datei an, die jemand geprüft hat. Dieser Leitfaden begleitet eine kleine AWS-Umgebung durch diese Kette und markiert, was aus einem StackToIT-Lauf und was aus der Dokumentation des STACKIT-Providers stammt.
Die Lieferkette in der richtigen Reihenfolge
1. In der Pipeline bewerten
Führen Sie die Bewertung mit --strict und --format json aus. Der Bericht wird auch geschrieben, wenn das Gate scheitert; der Job behält den Ausgabeordner daher als Artefakt und notiert den Exit-Code daneben.
2. Den Ordner verifizieren
stacktoit verify prüft den Lauf gegen sein Manifest und ob die erzeugten Dateien zueinander passen. Es ist kein Beweis, dass etwas in einer Cloud gelaufen ist, und keine Signatur.
3. Offene Anfragen in Dateien beantworten
Der Lauf schreibt inputs-template.yaml und decisions-template.yaml in seinen Ausgabeordner. Kopieren Sie sie an einen Ort außerhalb des erzeugten Ordners, füllen Sie sie aus, committen Sie sie und führen Sie den Lauf erneut mit --inputs und --decisions aus. Eine festgehaltene Prüfung allein schreibt den Entwurf nicht um.
4. Den geprüften Entwurf committen
Der Ordner terraform pinnt den Provider auf eine Version und verlangt Terraform oder OpenTofu ab 1.11. Behandeln Sie den Entwurf als Vorschlag: Er läuft durch einen normalen Pull Request.
5. Ohne gespeicherten Schlüssel authentifizieren
Legen Sie einen Service Account an, hängen Sie einen Federated Identity Provider für Ihr CI-System an und lassen Sie den Provider das OIDC-Token der Pipeline eintauschen. Halten Sie die Assertions so eng, wie das Token es erlaubt.
6. State wählen und schützen
Der Entwurf deklariert kein Backend. Ein S3-Backend auf Object Storage funktioniert, wenn AWS-spezifische Prüfungen übersprungen werden, aber das Locking nicht; und der State enthält einige Secrets im Klartext.
7. Planen, prüfen, die Plan-Datei anwenden
Führen Sie init, validate und plan -out als getrennte Schritte aus, lassen Sie eine Person den Plan lesen und wenden Sie dann genau diese Datei an.
8. Nach jeder Änderung neu bewerten
Neue Eingaben oder Entscheidungen verändern Entwurf und Ausführungsplan. Bewerten Sie erneut und prüfen Sie den neuen Plan, statt den alten zu flicken.
Das Gate, wie der Lauf es meldet
Eine für diese Seite geschriebene Umgebung mit fünf Ressourcen, von StackToIT am 4. November 2026 mit --strict und --format json bewertet, mit --no-validate; die OpenTofu-Validierung wurde also übersprungen. Zuerst: die zwei Befehle, die die StackToIT-Dokumentation zur Automatisierung für ein Gate angibt, jeweils wörtlich aus einem eigenen Codeblock. Danach: das Verifikationsereignis und der Summary-Datensatz, die der Lauf ausgegeben hat, formatiert und nur mit den hier besprochenen Feldern (die Datensätze enthalten mehr, etwa Lauf-ID, Dateiliste und Schrittzahlen).
stacktoit assess ./terraform --strict --format json > assessment-events.jsonlstacktoit verify ./terraform-stacktoit --output json{
"type": "event",
"event_code": "RUN_VERIFIED",
"phase": "publish",
"severity": "INFO",
"human_summary": "The package passed the checks of stacktoit verify (7 checks, PASSED) before it was published; the record is in run_verification of manifest.json."
}
{
"type": "summary",
"exit_code": 7,
"exit_reasons": [
{
"code": 7,
"reason": "PACKAGE_NOT_EXECUTION_READY",
"detail": "package PARTIALLY_EXECUTABLE"
}
],
"run_status": "COMPLETE",
"package": "FULL",
"verification": "PASSED",
"summary": {
"package_state": "PARTIALLY_EXECUTABLE",
"architect_approval": "NOT_PROVIDED",
"safe_to_apply": "NOT_ASSERTED"
}
}Exit 7 heißt: Das strenge Gate greift
Das Paket war vollständig und verifiziert, trotzdem lautet der Exit-Code 7 mit der Begründung, dass das Paket nicht ausführungsbereit ist: Es ist teilweise ausführbar. Von seinen 12 automatisierten Schritten wartet einer auf eine Designentscheidung (das Boot-Image), und keiner läuft wie geschrieben, solange project_id keinen Wert hat. Eine erste Bewertung scheitert an einem strengen Gate in aller Regel; genau dafür ist es da.
Code und Artefakt zusammen behandeln
Die Dokumentation verlangt von Automatisierung, den Exit-Code zu notieren und die erzeugten Dateien zu behalten, wo sie existieren. Weitere Codes: 3 heißt, die Validierung hat Quelle oder Entwurf abgelehnt, 4 eine unvollständige Quelle, 5 einen gesperrten Ausgabeordner, 6 eine fehlgeschlagene Verifikation.
Freigabe bleibt ein menschliches Feld
Die Summary zeigt die Architektenfreigabe als nicht erteilt und „sicher anzuwenden“ als nicht zugesichert. Eine Pipeline füllt das nicht aus; eine Person tut es über die Entscheidungsdatei.
Was der Entwurf an die Pipeline übergibt
Derselbe Lauf. Links: terraform/terraform.tf, das den STACKIT-Provider pinnt. Rechts: die Befehle, die execution/terraform/apply.md auflistet. Der Lauf wendet nichts an; die Datei sagt, dass nichts in diesem Ordner ausgeführt wurde.
terraform {
# Write-only attributes (e.g. a VPN pre-shared key) need Terraform/OpenTofu 1.11 or later.
required_version = ">= 1.11.0"
required_providers {
stackit = {
source = "stackitcloud/stackit"
version = "0.121.0"
}
}
}
provider "stackit" {
default_region = var.region
}cd terraform
tofu init
tofu validate
tofu plan -out=stackit.tfplan
tofu apply stackit.tfplanEine Provider-Version
Der Entwurf pinnt den Provider auf genau eine Version, sodass jeder Pipeline-Lauf gegen dasselbe Schema plant. Erhöhen Sie den Pin bewusst, in einem Pull Request.
Variablen ohne Standardwert bleiben offen
Projekt-ID, Image, Machine Type und Größe des Boot-Volumes haben keinen Standardwert. Liefern Sie sie über eine Variablendatei oder TF_VAR-Umgebungsvariablen, sensible Werte nie in einer committeten Datei.
Manuelle Schritte und Apply in zwei Durchgängen
apply.md beginnt mit „Do not apply yet“: Ein OpenTofu-Schritt wartet auf eine Entscheidung. Die Datei hat einen Abschnitt für manuelle Schritte, die vor tofu apply erledigt sein müssen (in diesem Lauf keine), weil OpenTofu den ganzen Entwurf auf einmal anwendet und sie nicht erzwingt, und teilt den Apply hier in zwei Durchgänge: zuerst die beiden Security Groups, dann zwei STACKIT-API-Aufrufe, die Standard-Egress-Regeln löschen, danach der Rest.
Authentifizierung per Workload Identity Federation
Wörtlich aus dem Leitfaden des STACKIT-Providers zu Workload Identity Federation, nicht von einem Lauf erzeugt. Links: der Federated Identity Provider, den der Leitfaden für sein eigenes Repository am Service Account einrichtet (Repository und Branch in sub ersetzen Sie durch Ihre). Rechts: die Plan- und Apply-Schritte seines GitHub-Actions-Beispiels; der Job braucht zusätzlich die Berechtigung id-token: write.
- **Provider Name**: GitHub # This is just an example, you can choose any name you want
- **Issuer URL**: https://token.actions.githubusercontent.com # This is the public issuer for GitHub Actions OIDC tokens
- **Assertions**:
- **sub**->equals->repo:stackitcloud/terraform-provider-stackit:ref:refs/heads/main # This is the repository and branch where the action will run
- **aud**->equals->sts.accounts.stackit.cloud # Mandatory value - name: Terraform Plan
run: |
terraform plan -out=tfplan
env:
STACKIT_USE_OIDC: "1"
STACKIT_SERVICE_ACCOUNT_EMAIL: "terraform-example@sa.stackit.cloud"
- name: Terraform Apply
run: terraform apply -auto-approve tfplan
env:
STACKIT_USE_OIDC: "1"
STACKIT_SERVICE_ACCOUNT_EMAIL: "terraform-example@sa.stackit.cloud"Kein statisches Secret
Der Provider dokumentiert diesen Ablauf als den Weg, der langlebige Secrets in CI/CD überflüssig macht. Er sucht die OIDC-Einstellung im Provider-Block, dann in Umgebungsvariablen, dann in einer Credentials-Datei. Das Beispiel des Leitfadens nutzt Terraform und wendet im selben Job mit -auto-approve an; das Paket des Laufs nutzt tofu, und den Ablauf unter OpenTofu hat diese Seite nicht geprüft. Setzen Sie die Prüfung des Plans zwischen die beiden Schritte.
Die Audience ist Pflicht
Die STACKIT-Dokumentation verlangt eine Assertion auf die Audience; unterstützt wird nur der Gleichheitsoperator, und ein Token wird nur akzeptiert, wenn jede Assertion zutrifft. Der Leitfaden rät zu möglichst restriktiven Assertions.
Andere CI-Systeme
Der Leitfaden behandelt GitHub Actions und Azure DevOps und sagt, die Prinzipien könnten auch für andere CI/CD-Plattformen gelten, die OIDC unterstützen.
Stufen, Einstellungen und Gates
| Stufe | Befehl oder Einstellung | Gate und was zu behalten ist |
|---|---|---|
| Bewerten | stacktoit assess ./terraform --strict --format json | Exit 0 ist ein veröffentlichter Bericht; 7 ein strenger Fehlschlag. Ausgabeordner in beiden Fällen behalten. |
| Verifizieren | stacktoit verify RUN_DIR | Exit 0 besteht, 6 meldet Befunde. Zwei Läufe vergleichen Sie mit --same-as. |
| Eingaben prüfen | --inputs- und --decisions-Dateien in der Versionsverwaltung | Prüfungen, die an eine andere Quelle gebunden sind, können als veraltet gemeldet werden. |
| Authentifizieren | STACKIT_USE_OIDC und STACKIT_SERVICE_ACCOUNT_EMAIL | Der Key Flow bleibt über STACKIT_SERVICE_ACCOUNT_KEY_PATH möglich. |
| State | S3-Backend auf Object Storage oder PostgreSQL-Backend | use_lockfile wirkt auf STACKIT Object Storage nicht: immer nur einen Apply-Job gleichzeitig laufen lassen. |
| Plan und Apply | tofu plan -out, dann tofu apply auf die Plan-Datei | Plan speichern; vor dem Apply gibt eine Person frei. |
Der Lauf hat das Locking auf keinem Backend getestet und sagt das. Außerdem hält der State den Secret Access Key von Object Storage im Klartext; der State ist damit selbst ein Secret.
Entscheidungen Ihrer Architekten
Wer den Plan freigibt
Ein Reviewer des verantwortlichen Teams, mit der Plan-Datei am Change. Der Lauf hält die Freigabe als nicht erteilt fest, bis eine Person antwortet.
Ort und Verschlüsselung des States
Der Lauf rät, den State zu verschlüsseln und den Lesezugriff auf die Pipeline zu beschränken, und verweist auf OpenTofu State Encryption oder ein verschlüsseltes Backend.
Immer nur ein Job
Ohne funktionierende Locks serialisieren Sie Applies in der Pipeline-Konfiguration.
Berechtigungen des Service Accounts
Der Service Account braucht die Rollen der Dienste, die der Entwurf nutzt; die Anforderungsdatei nennt keine Rolle; ermitteln Sie also das Minimum je Dienst.
Strenges oder beratendes Gate
Entscheiden Sie, ob Exit 7 den Merge blockiert oder nur kennzeichnet. Aus der Praxis: beratend für eine erste Bewertung, streng für die Apply-Stufe.
Fragen zur Bereitstellung
Wendet StackToIT etwas aus der Pipeline an?
Nein. Assess liest und schreibt Dateien. Terraform oder OpenTofu wendet an, gestartet von Ihrer Pipeline oder einer Person.
Warum scheitert mein strenges Gate an einer sauberen Bewertung?
Weil der strenge Modus teilweise und ungeprüfte Ergebnisse zu Fehlern macht. Ein teilweise ausführbares Paket mit offenen Entscheidungen liefert Exit 7, obwohl Bericht und Verifikation in Ordnung sind.
Kann ich den State auf Object Storage sperren?
Nicht mit der Lock-Datei des S3-Backends: Die Provider-Dokumentation sagt, dass sie auf STACKIT Object Storage keine Wirkung hat, und verweist für Locking auf ein PostgreSQL-Backend.
Soll die Pipeline einen Service-Account-Schlüssel halten?
Bevorzugen Sie Workload Identity Federation. Den Key Flow gibt es; er braucht eine Schlüsseldatei des Service Accounts, und der Schlüssel ist ein langlebiges Secret.
Woher kommen Secrets im State?
Der gepinnte Provider schreibt einige Attribute, etwa den Secret Access Key eines Object-Storage-Zugangs, in den State. sensitive blendet sie nur in der Plan-Ausgabe aus.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.