Kritische Laufzeitfehler sicher beheben

Ein Emergency Release behebt einen kritischen Laufzeitfehler mit einem signierten OCI-Image, ohne Datenbank, Product-Release-Ziele, Konfiguration oder Storage-Vertrag zu ändern. Nutzen Sie diesen Pfad nur, wenn schukai für das exakte Image ein gültiges EmergencyRelease-Manifest mit stateChangeClass: runtime_only bereitstellt.

Sie prüfen zuerst Signatur, Digests und Datenbankkompatibilität. Danach testen Sie das Image in einem Canary. Erst eine ausdrückliche Freigabe erlaubt den Produktionswechsel. Ein fehlendes oder rotes Ergebnis stoppt den Ablauf.

Situation	Richtiger Pfad
Signiertes OCI-Image mit `runtime_only` und unveränderter Product-Release-Identität	Emergency Release auf dieser Seite
Schema-, Product-Release-, Config- oder Storage-Änderung	Normaler Update- und Recovery-Pfad unter Produktupdates ohne manuelle Nacharbeit
DEB, RPM oder Standalone-Binary	Normaler Paket-Update-Pfad
Manifest, Signatur, Evidenz oder exakter Digest fehlt	Stoppen und ein vollständiges Release-Artefakt anfordern

Voraussetzungen

Sie benötigen:

Quell- und Zielimage als unveränderliche Referenz REGISTRY/REPOSITORY@sha256:<digest>;
emergency-release.json und das detached emergency-release.sigstore.json aus demselben Release-Bundle;
den separat bezogenen öffentlichen Emergency-Release-Schlüssel;
die separat vertrauten Werkzeuge nucleus-emergency-release-contract und nucleus-emergency-browser-canary, außerdem Cosign und jq;
eine lokal installierte ausstellende CA für Registry, curl und den Canary-Browser;
eine Modus-0600-Datei mit einem ausdrücklich bereitgestellten Canary- Account;
einen isolierten Canary oder eine dafür vorgesehene Canary-Instanz.

Beziehen Sie den Verifier nicht aus dem ungeprüften Zielimage. Bewahren Sie den öffentlichen Schlüssel und das Prüfwerkzeug über Ihren freigegebenen Operator-Tooling-Kanal auf.

Agentenunterstützung ohne automatische Freigabe

Ein Agent kann den Ablauf erklären und vorhandene Gate-Ergebnisse deterministisch einordnen. Er darf weder Signaturen selbst bestätigen noch den Produktions-Pin umschalten. Starten Sie mit:

bash

nucli skills show emergency-release

Für MCP stehen zwei lokale, read-only Werkzeuge bereit:

Werkzeug	Zweck	Verändert etwas?
`nucleus_emergency_release_skill`	Liefert den vollständigen Ablauf mit Signaturprüfung, Live-Plan, Canary, externer Freigabe, Readback und Recovery.	Nein
`nucleus_emergency_release_assess`	Ordnet bereits separat geprüfte boolesche Gate-Ergebnisse ein und nennt den nächsten sicheren Übergabepunkt.	Nein

Das Assessment erwartet alle folgenden Beobachtungen. Ein boolescher Wert ist nur das Ergebnis einer separaten Prüfung und niemals selbst der Nachweis:

Eingabe	Quelle
`phase`	`pre_activation`, `post_activation` oder `rollback` entsprechend dem aktuellen Betriebsabschnitt
`exactDigestsVerified`	Vergleich der unveränderlichen Quell-, Ziel-, Manifest- und Evidenz-Digests
`signatureVerified`, `attestationVerified`	Separat vertrauenswürdiger Validator mit gepinntem Public Key und Registry-CA
`runtimeOnly`	Verifiziertes Manifest und unveränderte Product-Release-, Schema-, Config- und Storage-Verträge
`deploymentPlanReady`	Versionsgleiches Ziel-`numin`, exakter Ziel-Digest und exaktes Manifest gegen den Live-Zustand
`canaryPassed`	Digestgebundene CanaryEvidence aus Health-, frischer API-/Browser-Session und Problem-Smoke
`externalApprovalGranted`	Ausdrückliche Infrastrukturfreigabe für Umgebung, Ziel-, Manifest- und Canary-Digest
`primaryReadbackPassed`	Mindestens fünf Minuten Readback am aktivierten Primärsystem
`stateChanged`	Erneute Prüfung von Product-Release-Identität, Schema, Transition-Digest, Config und Storage
`rollbackAllowed`	Neu ausgeführter Live-Plan erlaubt weiterhin den exakten Quell-Digest

Mögliche Ergebnisse stoppen unter anderem bei veränderlicher Identität, unvollständiger Supply-Chain-Prüfung, nicht zustandsneutralem Artefakt, fehlendem Live-Plan, rotem Canary oder fehlender externer Freigabe. Erst external_activation_handoff_ready erlaubt der Infrastruktur, außerhalb des MCP-Werkzeugs ausschließlich den betroffenen Pin umzuschalten. Nach der Aktivierung verlangt primary_readback_required den Primär-Readback. Ein Rückweg ist nur bei binary_switch_eligible überhaupt ein Kandidat; andernfalls gilt Forward-Recovery oder vollständiger Restore.

Übergeben Sie dem Assessment keine Credential-Dateien, Cookies, privaten Signaturschlüssel, Manifest-Secrets oder ungefilterten Kundenlogs. Das Assessment verifiziert kein Artefakt, erteilt keine Freigabe und ersetzt keine Live-Prüfung.

Image und Manifest prüfen

Führen Sie die Prüfung aus, bevor Sie das Zielimage starten:

bash

export NUCLEUS_EMERGENCY_CONTRACT_BIN=/opt/workspace-operator/bin/nucleus-emergency-release-contract
export NUCLEUS_EMERGENCY_BROWSER_CANARY_BIN=/opt/workspace-operator/bin/nucleus-emergency-browser-canary

/opt/workspace-operator/bin/verify-emergency-release.sh \
  --image registry.example/workspace@sha256:<ziel-digest> \
  --manifest /sicher/emergency-release.json \
  --manifest-bundle /sicher/emergency-release.sigstore.json \
  --public-key /etc/workspace/trust/emergency-release.pub \
  --registry-ca /etc/ssl/certs/registry-ca.pem

Die Prüfung ist erfolgreich, wenn sie Signatur, Image-Digest, kanonisches Manifest und OCI-Attestation bestätigt. Sie schlägt fehl, wenn ein Feld unbekannt ist, ein Tag statt eines Digests verwendet wird oder die Attestation ein anderes Manifest enthält.

Datenbankvertrag vor der Aktivierung prüfen

Verwenden Sie das numin aus exakt dem Zielimage. Der Befehl liest den persistierten Stand und ändert keine Daten:

bash

/pfad/zum/ziel/numin \
  --config /pfad/zur/nucleus.config.enc \
  deployment plan \
  --artifact-digest <ziel-digest> \
  --emergency-manifest /sicher/emergency-release.json \
  --json

Fahren Sie nur fort, wenn alle folgenden Felder passen:

text

ready: true
releaseMode: runtime_only
rollbackToSource.allowed: true
rollbackToSource.mode: binary_switch

Die Runtime-Version des Hotfixes darf neuer sein. productReleaseVersion, Product-Release-Manifest-Digest, Schema-Baseline und Transition-Digest müssen mit dem Quellimage und dem persistierten Zustand übereinstimmen.

Canary ausführen

Die Credential-Datei enthält ausschließlich die Felder email und password. Legen Sie sie geschützt an:

bash

chmod 0600 /sicher/canary-credentials.json

/opt/workspace-operator/bin/run-emergency-canary.sh \
  --image registry.example/workspace@sha256:<ziel-digest> \
  --manifest /sicher/emergency-release.json \
  --manifest-bundle /sicher/emergency-release.sigstore.json \
  --public-key /etc/workspace/trust/emergency-release.pub \
  --base-url https://canary.example.com \
  --credentials-file /sicher/canary-credentials.json \
  --ca-file /etc/ssl/certs/workspace-ca.pem \
  --environment production_canary \
  --output /sicher/canary-evidence.json

Der feste Smoke-Katalog prüft Liveness, Readiness, die öffentliche Loginroute, eine neue API-Session und eine neue Browser-Session. Das Manifest kann keine beliebigen Shell-Befehle ausführen. Speichern Sie den ausgegebenen canary_evidence_digest für die Freigabe.

Produktionswechsel freigeben

Die Infrastrukturfreigabe muss mindestens diese Werte nennen:

Zielumgebung;
Zielimage-Digest;
Emergency-Manifest-Digest;
Canary-Evidence-Digest.

Automatisieren Sie Prüfung und Canary. Wechseln Sie den Produktions-Pin erst nach der ausdrücklichen Freigabe. Ändern Sie nur den betroffenen Runtime-Pin. Verschieben Sie keine stable- oder latest-Tags.

Für die mitgelieferte Docker-Compose-Installation lautet der freigegebene Wechsel:

bash

./start.sh update \
  registry.example/workspace@sha256:<ziel-digest> \
  --emergency-manifest /sicher/emergency-release.json

Der Helper erstellt weiterhin ein geprüftes Backup, führt den Ziel- DeploymentPlan aus und wartet auf Readiness.

Für die mitgelieferte Kustomize-Installation verwenden Sie nach derselben Freigabe:

bash

./update.sh \
  registry.example/workspace@sha256:<ziel-digest> \
  /sicher/backup-evidence.json \
  --emergency-manifest /sicher/emergency-release.json

Das Skript legt Manifest und Backup-Evidenz nur für den einmaligen, unprivilegierten Preflight als ConfigMaps ab. Es ändert das Deployment erst, wenn das numin aus dem exakten Zielimage den Live-Zustand freigibt.

Primärsystem fünf Minuten prüfen

Führen Sie nach dem Wechsel einen neuen Readback mit mindestens 300 Sekunden aus:

bash

/opt/workspace-operator/bin/run-emergency-canary.sh \
  --image registry.example/workspace@sha256:<ziel-digest> \
  --manifest /sicher/emergency-release.json \
  --manifest-bundle /sicher/emergency-release.sigstore.json \
  --public-key /etc/workspace/trust/emergency-release.pub \
  --base-url https://workspace.example.com \
  --credentials-file /sicher/canary-credentials.json \
  --ca-file /etc/ssl/certs/workspace-ca.pem \
  --environment primary_readback \
  --observation-seconds 300 \
  --output /sicher/primary-readback.json

Bewahren Sie das Quellimage mindestens 24 Stunden nach erfolgreichem Readback auf. Löschen Sie außerdem keine Baseline-Readiness-Evidenz oder von ihr referenzierten Images während des Supportzeitraums.

Zum Quellimage zurückwechseln

Prüfen Sie Signatur und Manifest erneut. Lassen Sie danach den aktuell aktiven Hotfix mit demselben Manifest den Datenbankstand prüfen. Die Docker- Compose-Installation kombiniert diese Prüfung mit dem exakten Wechsel:

bash

./start.sh emergency-rollback \
  registry.example/workspace@sha256:<quell-digest> \
  --emergency-manifest /sicher/emergency-release.json

Der Helper stoppt, sobald Quell-Digest, aktiver Ziel-Digest oder persistierter Zustand abweichen. Wenn der Plan keinen Binary-Wechsel mehr erlaubt, reparieren Sie mit einer kompatiblen Version vorwärts oder stellen Sie Datenbank, Storage, verschlüsselte Konfiguration und Runtime-Key gemeinsam wieder her.

Nächste Schritte

Nutzen Sie numin für den read-only DeploymentPlan.
Nutzen Sie nucli nach erfolgreicher Readiness für authentisierte Status- und Sitzungsprüfungen.
Folgen Sie Produktupdates ohne manuelle Nacharbeit, sobald ein Hotfix einen persistenten Vertrag ändert.